* Re: [PATCH V7 04/12] clk: sprd: add mux clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-5-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch adds clock multiplexor support for Spreadtrum platforms,
> the mux clocks also can be found in sprd composite clocks, so
> provides two helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 05/12] clk: sprd: add divider clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-6-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This is a feature that can also be found in sprd composite clocks,
> provide a bunch of helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 06/12] clk: sprd: add composite clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-7-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch introduced composite driver for Spreadtrum's SoCs. The
> functions of this composite clock simply consist of divider and
> mux clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 07/12] clk: sprd: add adjustable pll support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-8-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduced a common adjustable pll clock driver for Spreadtrum SoCs.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 08/12] dt-bindings: Add Spreadtrum clock binding documentation
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Brown, Xiaolong Zhang, Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-9-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On 12/07, Chunyan Zhang wrote:
> Introduce a new binding with its documentation for Spreadtrum clock
> sub-framework.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 V7 09/12] clk: sprd: Add dt-bindings include file for SC9860
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-10-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This file defines all SC9860 clock indexes, it should be included in the
> device tree in which there's device using the clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 10/12] clk: sprd: add clocks support for SC9860
From: Stephen Boyd @ 2017-12-21 23:03 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-11-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch added the list of clocks for Spreadtrum's SC9860 SoC,
> together with clock initialization code.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 11/12] arm64: dts: add syscon for whale2 platform
From: Stephen Boyd @ 2017-12-21 23:03 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Brown, Xiaolong Zhang, Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-12-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On 12/07, Chunyan Zhang wrote:
> Some clocks on SC9860 are in the same address area with syscon
> devices, the proper syscon node will be quoted under the
> definitions of those clocks in DT.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> ---
These last two can go via arm-soc?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/5] dt-bindings: at24: consistently document the compatible property
From: Peter Rosin @ 2017-12-21 23:07 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Bartosz Golaszewski, Andy Shevchenko, Rob Herring, Mark Rutland,
David Lechner, Divagar Mohandass, Linux I2C, devicetree,
Linux Kernel
In-Reply-To: <CABxcv=kZk+Yrt9uj9uV7UVC+Tca7NCECfyZXmKkqHdopm5EZTg@mail.gmail.com>
On 2017-12-21 21:27, Javier Martinez Canillas wrote:
> Hello Peter,
>
> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda@axentia.se> wrote:
>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>>> Current description of the compatible property for at24 is quite vague.
>>>
>>> Specify an exact list of accepted compatibles and document the - now
>>> deprecated - strings which were previously used in device tree files.
>>
>> Why is it suddenly deprecated to correctly specify what hardware you
>> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
>
> Sorry but I disagree.
>
> When you specify a compatible string, you are not specifying a
> particular hardware but a device programming model.
That's not what it says in https://elinux.org/Device_Tree_Usage
in the "Understanding the compatible Property" section. I quote:
compatible is a list of strings. The first string in the
list specifies the exact device that the node represents
in the form "<manufacturer>,<model>". The following strings
represent other devices that the device is compatible with.
Pretty clearly talks about devices and not programming models. But
maybe I shouldn't trust that reference? What should I be reading
instead?
> It's very common to use a compatible string that doesn't match exactly
> the specific hardware used. That's why it's called _compatible_ BTW.
That's not how I read the above.
> For example when a DTS define a UART node with an ns16550 compatible,
> they don't really mean that have a UART IC manufactured by National
> Semiconductor.
That just tells me that most people are a little bit lazy and ready
to cut a corner or two when they can get away with it. Or that there
is some form of misunderstanding at work...
>> Sure, it happens to be compatible with "atmel,24c32", but that is
>> supposed to be written with a fallback as
>>
>> "nxp,24c32", "atmel,24c32"
>
> This isn't a requirement really, systems integrators are free to use
> more than one <manufacturer,model> tuple in the compatible string if
> they want the DTB to be future proof, just in case there's a need for
> a more specific driver or if the programming model happened to not be
> the same at the end. This is usually done for the boards compatible
> string as an example, even when there isn't a struct machine_desc for
> the specific board compatible and only for the SoC family.
>
> So it's OK if you want to define the compatible as "nxp,24c32",
> "atmel,24c32", but that's a general OF concept and not something
> related to the at24 eeprom driver so I'm not sure if it should be
> mentioned in the at24 DT binding doc.
One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example
below) is not a valid compatible, the tooling will be correct to
complain about it. Currently, it is just a checkpatch deficiency that
it complains like this:
$ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
#249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
+ compatible = "nxp,24c02", "atmel,24c02";
>> if I understand correctly. So, why is that deprecated in this case?
>>
>> What if (a few years down the line) it is discovered that some weird
>> quirk is needed that is only appropriate for nxp chips?
>>
>> nxp is of course just an example, pick any manufacturer of eeproms
>> (supposedly) compatible with the atmel interface.
>>
>
> That's indeed a possibility and the reason why most DT nodes have a
> more specific <manufacturer,model> before the generic one matched by
> drivers. I really doubt that in the future it will be found that a
> more specific compatible string is needed for one manufacturer in this
> case, specially since the driver didn't even care about the
> manufacturers until recently.
I'm not talking about the driver. But if what you say is true, that
change would have broken a number of existing DTBs. Is that really the
case?
> So I think that makes no sense for a driver to support all possible
> manufacturers as possible compatible strings if all the devices have
> the same exact programming model.
That's what the fallback is for. With that in place the driver can
start to care when there is a need but until then it can work just
as it always has. Without knowing the specific device, the driver has
less chance to adapt when the unexpected is discovered. But again,
I'm not really discussing driver details, I'm complaining about the
proposed changes to the bindings. I simply don't see how they make
sense.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
From: Rob Herring @ 2017-12-21 23:19 UTC (permalink / raw)
To: jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ
Cc: Mark Rutland, Thierry Reding, David Airlie, Russell King,
Shawn Guo, Sascha Hauer, Fabio Estevam, Andreas Färber,
Kevin Hilman, Maxime Ripard, Alexandre Belloni, SZ Lin,
Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220134710.64479-5-jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 20, 2017 at 02:47:04PM +0100, jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org wrote:
> From: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
>
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
>
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
>
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
>
> Signed-off-by: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
> ---
> Changes in v2:
> - Fixed typo (reg_prallel.. --> reg_parallel)
> - Removed trailing new-line
> - Fix uppercase addresses as Rob H. noted
> - Fix warning about lcd@di0 -> rename to disp0
> - Renamed some nodes regarding Rob H.
>
> Documentation/devicetree/bindings/arm/emtrion.txt | 13 +
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-emcon-avari.dts | 233 ++++++
> arch/arm/boot/dts/imx6dl-emcon.dtsi | 37 +
> arch/arm/boot/dts/imx6q-emcon-avari.dts | 233 ++++++
> arch/arm/boot/dts/imx6q-emcon.dtsi | 37 +
> arch/arm/boot/dts/imx6qdl-emcon.dtsi | 848 ++++++++++++++++++++++
> 7 files changed, 1403 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
> create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
> create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
> create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
> create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
[...]
> + captouch: touchscreen@38 {
> + reg = <0x38>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_irq_touch2 &pinctrl_emcon_gpio4>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> + compatible = "edt,edt-ft5406";
Put compatible as the first property.
> + wake-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> + wakeup-source;
> + };
> +};
[...]
> +&rgb_panel {
> + compatible = "edt,etm0700g0bdh6";
> + status = "okay";
Having compatible here is a bit strange and fragile. It's assuming 2
different panels have the same common properties.
> diff --git a/arch/arm/boot/dts/imx6q-emcon.dtsi b/arch/arm/boot/dts/imx6q-emcon.dtsi
> new file mode 100644
> index 000000000000..64fc0cd74c05
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-emcon.dtsi
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
You don't need this if...
> + *
> + * SPDX-License-Identifier: GPL-2.0
You have this.
Also, the rules around this are getting a bit stricter saying the SPDX
tag should be the first line of the file using a C++ style comment.
> + *
> + */
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Dual/Quad";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q";
Need a space ^
> diff --git a/arch/arm/boot/dts/imx6qdl-emcon.dtsi b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> new file mode 100644
> index 000000000000..f87d8ed6a1b1
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> @@ -0,0 +1,848 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +
> + model = "emtrion SoM emCON-MX6";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q", "fsl,imx6dl";
Need a space ^
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] bindings: regulator: added support for suspend states
From: Rob Herring @ 2017-12-21 23:26 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
In-Reply-To: <1513837506-26543-2-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Dec 21, 2017 at 02:25:02PM +0800, Chunyan Zhang wrote:
> Documented a few new added properties which are used for supporting
> regulator suspend states.
Your commit message should answer why you need this. What problem do you
have that this solves?
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/regulator/regulator.txt | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> index 378f6dc..618a322 100644
> --- a/Documentation/devicetree/bindings/regulator/regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -42,8 +42,15 @@ Optional properties:
> - regulator-state-[mem/disk] node has following common properties:
> - regulator-on-in-suspend: regulator should be on in suspend state.
> - regulator-off-in-suspend: regulator should be off in suspend state.
> - - regulator-suspend-microvolt: regulator should be set to this voltage
> - in suspend.
> + - regulator-suspend-min-microvolt: minimum voltage may be set in
> + suspend state.
> + - regulator-suspend-max-microvolt: maximum voltage may be set in
> + suspend state.
> + - regulator-suspend-microvolt: the default voltage which regulator
> + should be set in suspend, this can be adjusted among
> + <regulator-suspend-min-microvolt, regulator-suspend-max-microvolt>
Perhaps this should stay a single property with: <target> <min> <max>
Though why would you ever not try to set to the minimum voltage within
the range of <min> to <max>?
> + - regulator-changeable-in-suspend: whether the default voltage and
> + the regulator on/off in suspend can be changed in runtime.
> - regulator-mode: operating mode in the given suspend state.
> The set of possible operating modes depends on the capabilities of
> every hardware so the valid modes are documented on each regulator
> --
> 2.7.4
>
--
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/5] dt-bindings: at24: consistently document the compatible property
From: Javier Martinez Canillas @ 2017-12-21 23:38 UTC (permalink / raw)
To: Peter Rosin
Cc: Bartosz Golaszewski, Andy Shevchenko, Rob Herring, Mark Rutland,
David Lechner, Divagar Mohandass, Linux I2C, devicetree,
Linux Kernel
In-Reply-To: <a0cbee79-29dd-686c-5069-d95e1710bfc1@axentia.se>
Hello Peter,
On Fri, Dec 22, 2017 at 12:07 AM, Peter Rosin <peda@axentia.se> wrote:
> On 2017-12-21 21:27, Javier Martinez Canillas wrote:
>> Hello Peter,
>>
>> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda@axentia.se> wrote:
>>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>>>> Current description of the compatible property for at24 is quite vague.
>>>>
>>>> Specify an exact list of accepted compatibles and document the - now
>>>> deprecated - strings which were previously used in device tree files.
>>>
>>> Why is it suddenly deprecated to correctly specify what hardware you
>>> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
>>
>> Sorry but I disagree.
>>
>> When you specify a compatible string, you are not specifying a
>> particular hardware but a device programming model.
>
> That's not what it says in https://elinux.org/Device_Tree_Usage
I think the most up-to-date DT reference is at:
https://www.devicetree.org/
> in the "Understanding the compatible Property" section. I quote:
>
> compatible is a list of strings. The first string in the
> list specifies the exact device that the node represents
> in the form "<manufacturer>,<model>". The following strings
> represent other devices that the device is compatible with.
>
> Pretty clearly talks about devices and not programming models. But
> maybe I shouldn't trust that reference? What should I be reading
> instead?
>
For example the latest spec draft
(https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
says:
"The compatible property value consists of one or more strings that
define the specific programming model for the device. This list of
strings should be used by a client program for device driver
selection. The property value consists of a concatenated list of null
terminated strings, from most specific to most general. They allow a
device to express its compatibility with a family of similar devices,
potentially allowing a single device driver to match against several
devices."
The recommended format is "manufacturer,model", where manufacturer is
a string describing the name of the manufacturer (such as a stock
ticker symbol), and model specifies the model number."
Example:
compatible = "fsl,mpc8641", "ns16550";
In this example, an operating system would first try to locate a
device driver that supported fsl,mpc8641. If a driver was not found,
it would then try to locate a driver that supported the more general
ns16550 device type."
>> It's very common to use a compatible string that doesn't match exactly
>> the specific hardware used. That's why it's called _compatible_ BTW.
>
> That's not how I read the above.
>
That's not how I read it nor my experience with DT, but of course I
may be wrong on this.
>> For example when a DTS define a UART node with an ns16550 compatible,
>> they don't really mean that have a UART IC manufactured by National
>> Semiconductor.
>
> That just tells me that most people are a little bit lazy and ready
> to cut a corner or two when they can get away with it. Or that there
> is some form of misunderstanding at work...
>
For example, I usually see that different SoC families from the same
vendor use the same compatible string for integrated peripherals just
because are the same from a programming model point of view.
TI am33xx SoCs use a lot of omap3 compatible strings on their nodes
and its similar on Exynos SoCs which are the two ARM SoCs I'm most
familiar with. Following your logic that's wrong and instead a new
compatible string should be added for the GPIO or pinctrl drivers even
when are the same because refer to different devices.
>>> Sure, it happens to be compatible with "atmel,24c32", but that is
>>> supposed to be written with a fallback as
>>>
>>> "nxp,24c32", "atmel,24c32"
>>
>> This isn't a requirement really, systems integrators are free to use
>> more than one <manufacturer,model> tuple in the compatible string if
>> they want the DTB to be future proof, just in case there's a need for
>> a more specific driver or if the programming model happened to not be
>> the same at the end. This is usually done for the boards compatible
>> string as an example, even when there isn't a struct machine_desc for
>> the specific board compatible and only for the SoC family.
>>
>> So it's OK if you want to define the compatible as "nxp,24c32",
>> "atmel,24c32", but that's a general OF concept and not something
>> related to the at24 eeprom driver so I'm not sure if it should be
>> mentioned in the at24 DT binding doc.
>
> One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example
> below) is not a valid compatible, the tooling will be correct to
> complain about it. Currently, it is just a checkpatch deficiency that
> it complains like this:
>
> $ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
> WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
> #249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
> + compatible = "nxp,24c02", "atmel,24c02";
>
But isn't that a bug in checkpatch? as long as there's a valid
<manufacturer,model> tuple in the compatible string, it shouldn't
complain.
>>> if I understand correctly. So, why is that deprecated in this case?
>>>
>>> What if (a few years down the line) it is discovered that some weird
>>> quirk is needed that is only appropriate for nxp chips?
>>>
>>> nxp is of course just an example, pick any manufacturer of eeproms
>>> (supposedly) compatible with the atmel interface.
>>>
>>
>> That's indeed a possibility and the reason why most DT nodes have a
>> more specific <manufacturer,model> before the generic one matched by
>> drivers. I really doubt that in the future it will be found that a
>> more specific compatible string is needed for one manufacturer in this
>> case, specially since the driver didn't even care about the
>> manufacturers until recently.
>
> I'm not talking about the driver. But if what you say is true, that
> change would have broken a number of existing DTBs. Is that really the
> case?
>
Sorry, I didn't get which change you meant.
>> So I think that makes no sense for a driver to support all possible
>> manufacturers as possible compatible strings if all the devices have
>> the same exact programming model.
>
> That's what the fallback is for. With that in place the driver can
> start to care when there is a need but until then it can work just
> as it always has. Without knowing the specific device, the driver has
> less chance to adapt when the unexpected is discovered. But again,
> I'm not really discussing driver details, I'm complaining about the
> proposed changes to the bindings. I simply don't see how they make
> sense.
>
My point is that saying in a DT binding that you could have a more
specific <manufacturer,model> followed by a generic one is redundant.
That's already something one can do to make the DT future proof and
latter if is found that the more specific pair is needed, then
compatible can be added to the OF device ID table making the driver to
match that an the <manufacturer,model> added to the DT binding making
it formal.
That's my understanding at least, but I could be completely wrong too
since I'm not a DT expert.
> Cheers,
> Peter
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH v2 3/3] clk: actions: Add clock driver for Actions S900 SoC
From: Stephen Boyd @ 2017-12-21 23:56 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, afaerber-l3A5Bk7waGM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
liuwei-/sSyCTpAT0ql5r2w9Jh5Rg, mp-cs-/sSyCTpAT0ql5r2w9Jh5Rg,
96boards-Ty1hIZOCd2XuufBYgWm87A,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
amit.kucheria-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
manivannanece23-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1509997552-29718-4-git-send-email-manivannan.sadhasivam-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/07, Manivannan Sadhasivam wrote:
> diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
> new file mode 100644
> index 0000000..0de7a03
> --- /dev/null
> +++ b/drivers/clk/actions/Kconfig
> @@ -0,0 +1,6 @@
> +config CLK_OWL_S900
> + bool "Clock Driver for Actions S900 SoC"
Can it be a module too? Otherwise drop module.h and anything that
does to the driver.
> + depends on ARCH_ACTIONS || COMPILE_TEST
Can you try compiling this with COMPILE_TEST=y and
ARCH_ACTIONS=n? It may be that drivers/clk/Makefile needs to be
obj-y and then the owl-clk, owl-pll, owl-factor files need to be
compiled only when CONFIG_CLK_OWL_S900 is y. If there becomes
more than one actions driver, then the clk, pll, factor files
will need to be compiled with some new CLK_ACTIONS kconfig symbol
or something.
> + default ARCH_ACTIONS
> + help
> + Build the clock driver for Actions S900 SoC.
> diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
> new file mode 100644
> index 0000000..83bef30
> --- /dev/null
> +++ b/drivers/clk/actions/Makefile
> @@ -0,0 +1,2 @@
> +obj-y += owl-clk.o owl-pll.o owl-factor.o
> +obj-$(CONFIG_CLK_OWL_S900) += owl-s900.o
> diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
> new file mode 100644
> index 0000000..51e297f
> --- /dev/null
> +++ b/drivers/clk/actions/owl-s900.c
> @@ -0,0 +1,585 @@
> +/*
> + * Copyright (c) 2014 Actions Semi Inc.
> + * Author: David Liu <liuwei-/sSyCTpAT0ql5r2w9Jh5Rg@public.gmane.org>
> + *
> + * Copyright (c) 2017 Linaro Ltd.
> + * Author: Manivannan Sadhasivam <manivannan.sadhasivam-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
Can you move to the SPDX tags please?
> + COMP_DIV_CLK(CLK_UART3, "uart3", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART3CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 19, 0),
> + C_DIVIDER(CMU_UART3CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART4, "uart4", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART4CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 20, 0),
> + C_DIVIDER(CMU_UART4CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART5, "uart5", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART5CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 21, 0),
> + C_DIVIDER(CMU_UART5CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART6, "uart6", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART6CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 18, 0),
> + C_DIVIDER(CMU_UART6CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_FACTOR_CLK(CLK_VCE, "vce", 0,
> + C_MUX(vce_clk_mux_p, CMU_VCECLK, 4, 2, 0),
> + C_GATE(CMU_DEVCLKEN0, 26, 0),
> + C_FACTOR(CMU_VCECLK, 0, 3, bisp_factor_table, 0)),
> +
> + COMP_FACTOR_CLK(CLK_VDE, "vde", 0,
> + C_MUX(hde_clk_mux_p, CMU_VDECLK, 4, 2, 0),
> + C_GATE(CMU_DEVCLKEN0, 25, 0),
> + C_FACTOR(CMU_VDECLK, 0, 3, bisp_factor_table, 0)),
> +};
> +
> +static int s900_clk_probe(struct platform_device *pdev)
> +{
> + struct owl_clk_provider *ctx;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *res;
> + void __iomem *base;
> + int i;
> +
> + ctx = kzalloc(sizeof(struct owl_clk_provider) +
> + sizeof(*ctx->clk_data.hws) * CLK_NR_CLKS, GFP_KERNEL);
It would be nice to avoid this. If the structs can all be
configured properly, it should be possible to have an array of
clk_hw pointers that are registered directly with
clk_hw_register(), and then index directly into that array to
return clk_hw pointers for the clk_hw provider function.
> + if (!ctx)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + for (i = 0; i < CLK_NR_CLKS; ++i)
> + ctx->clk_data.hws[i] = ERR_PTR(-ENOENT);
> +
> + ctx->reg_base = base;
> + ctx->clk_data.num = CLK_NR_CLKS;
Hopefully CLK_NR_CLKS isn't coming from the DT header file.
> + spin_lock_init(&ctx->lock);
> +
> + /* register pll clocks */
> + owl_clk_register_pll(ctx, s900_pll_clks,
> + ARRAY_SIZE(s900_pll_clks));
> +
> + /* register divider clocks */
> + owl_clk_register_divider(ctx, s900_div_clks,
> + ARRAY_SIZE(s900_div_clks));
> +
> + /* register factor divider clocks */
> + owl_clk_register_factor(ctx, s900_factor_clks,
> + ARRAY_SIZE(s900_factor_clks));
> +
> + /* register mux clocks */
> + owl_clk_register_mux(ctx, s900_mux_clks,
> + ARRAY_SIZE(s900_mux_clks));
> +
> + /* register gate clocks */
> + owl_clk_register_gate(ctx, s900_gate_clks,
> + ARRAY_SIZE(s900_gate_clks));
> +
> + /* register composite clocks */
> + owl_clk_register_composite(ctx, s900_composite_clks,
> + ARRAY_SIZE(s900_composite_clks));
> +
> + return of_clk_add_hw_provider(np, of_clk_hw_onecell_get,
> + &ctx->clk_data);
> +
> +}
> +
> +static const struct of_device_id s900_clk_of_match[] = {
> + { .compatible = "actions,s900-cmu", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, s900_clk_of_match);
This isn't necessary? It's not a module?
> +
> +static struct platform_driver s900_clk_driver = {
> + .probe = s900_clk_probe,
> + .driver = {
> + .name = "s900-cmu",
> + .of_match_table = s900_clk_of_match,
You need to supress_bind_attrs here or implement the remove
function for this driver that would unregister all the clks and
provider.
> + },
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King - ARM Linux @ 2017-12-22 0:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, Andrew Lunn, Florian Fainelli,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Stefan Agner, Rob Herring, Sascha Hauer, Shawn Guo, Linux ARM
In-Reply-To: <CACRpkdarS+tPv5CG4bmFcPvc+=SJJcC1pbO7WSbsS5+yCuxh_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 21, 2017 at 11:53:47PM +0100, Linus Walleij wrote:
> On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>
> > What we have here is _really_ a shared interrupt between four
> > separate devices, and we need a way to sanely describe resources
> > shared between several device instances to pinmux. Unfortunately,
> > it seems pinmux is designed around one device having exclusive use
> > of a resource, which makes it hard to describe shared interrupts in
> > DT.
> >
> > Given that DT should be a description of the hardware, and should be
> > independent of the OS implementation, I'd say this is a pinmux bug,
> > because pinmux gets in the way of describing the hardware correctly.
> > ;)
>
> Hm that would be annoying. But when I look at it I think it would
> actually work. Did you try just assigning the same pin control
> state to all the PHY's and see what happens?
>
> Just set
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_mv88e1545>;
>
> on all of them?
It was tried, DT was happy, but the kernel on boot complained because
pinctrl objected, which caused the drivers to fail to bind:
libphy: mdio: probed
vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio@4!switch@0!mdio:00; cannot claim for !mdio-mux!mdio@4!switch@0!mdio:01
vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio@4!switch@0!mdio:01) status -22
vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
Marvell 88E1545 !mdio-mux!mdio@4!switch@0!mdio:01: Error applying setting, reverse things back
Marvell 88E1545: probe of !mdio-mux!mdio@4!switch@0!mdio:01 failed with error -22
vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio@4!switch@0!mdio:00; cannot claim for !mdio-mux!mdio@4!switch@0!mdio:02
vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio@4!switch@0!mdio:02) status -22
vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
Marvell 88E1545 !mdio-mux!mdio@4!switch@0!mdio:02: Error applying setting, reverse things back
Marvell 88E1545: probe of !mdio-mux!mdio@4!switch@0!mdio:02 failed with error -22
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
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 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Florian Fainelli @ 2017-12-22 0:20 UTC (permalink / raw)
To: Russell King - ARM Linux, Linus Walleij
Cc: Mark Rutland, Andrew Lunn,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Stefan Agner, Rob Herring, Sascha Hauer, Shawn Guo, Linux ARM
In-Reply-To: <20171222001407.GL10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 12/21/2017 04:14 PM, Russell King - ARM Linux wrote:
> On Thu, Dec 21, 2017 at 11:53:47PM +0100, Linus Walleij wrote:
>> On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
>> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>>
>>> What we have here is _really_ a shared interrupt between four
>>> separate devices, and we need a way to sanely describe resources
>>> shared between several device instances to pinmux. Unfortunately,
>>> it seems pinmux is designed around one device having exclusive use
>>> of a resource, which makes it hard to describe shared interrupts in
>>> DT.
>>>
>>> Given that DT should be a description of the hardware, and should be
>>> independent of the OS implementation, I'd say this is a pinmux bug,
>>> because pinmux gets in the way of describing the hardware correctly.
>>> ;)
>>
>> Hm that would be annoying. But when I look at it I think it would
>> actually work. Did you try just assigning the same pin control
>> state to all the PHY's and see what happens?
>>
>> Just set
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_mv88e1545>;
>>
>> on all of them?
>
> It was tried, DT was happy, but the kernel on boot complained because
> pinctrl objected, which caused the drivers to fail to bind:
>
> libphy: mdio: probed
> vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio@4!switch@0!mdio:00; cannot claim for !mdio-mux!mdio@4!switch@0!mdio:01
> vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio@4!switch@0!mdio:01) status -22
> vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
> Marvell 88E1545 !mdio-mux!mdio@4!switch@0!mdio:01: Error applying setting, reverse things back
> Marvell 88E1545: probe of !mdio-mux!mdio@4!switch@0!mdio:01 failed with error -22
> vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio@4!switch@0!mdio:00; cannot claim for !mdio-mux!mdio@4!switch@0!mdio:02
> vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio@4!switch@0!mdio:02) status -22
> vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
> Marvell 88E1545 !mdio-mux!mdio@4!switch@0!mdio:02: Error applying setting, reverse things back
> Marvell 88E1545: probe of !mdio-mux!mdio@4!switch@0!mdio:02 failed with error -22
>
You could also see it another way, because this is a quad PHY in a
single package, you could theoretically have a representation that
exposes a node container for the 4 PHYs, and that container node
requests the pinmux/pinctrl. Of course, this would not work with the
MDIO code which would not go one level down, and would expect the PHYs
to be at the same level as the container node...
Oh well.
--
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 v2 01/11] clk: qcom: add read-only divider operations
From: Stephen Boyd @ 2017-12-22 0:23 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-2-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> Some of the divider settings are preconfigured and should not
> be changed by the clock framework during frequency change. This
> patch adds the read-only divider operation for QCOM dividers
> which is equivalent to generic divider operations in
> 'commit 79c6ab509558 ("clk: divider: add CLK_DIVIDER_READ_ONLY flag")'.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 02/11] clk: qcom: add parent map for regmap mux
From: Stephen Boyd @ 2017-12-22 0:23 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-3-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> Currently the driver assumes the register configuration value
> is identical to its index in the parent map. This patch adds
> the parent map field in regmap mux clock node which contains
> the mapping of parent index with actual register configuration
> value. If regmap node contains this parent map then the
> configuration value will be taken from this
> parent map instead of simply writing the index value.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 03/11] clk: qcom: ipq8074: fix missing GPLL0 divider width
From: Stephen Boyd @ 2017-12-22 0:23 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-4-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> GPLL0 uses 4 bits post divider which should be specified
> in clock driver structure.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 05/11] clk: qcom: ipq8074: add remaining PLL’s
From: Stephen Boyd @ 2017-12-22 0:23 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-6-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> - GPLL2, GPLL4 and GPLL6 are general PLL clocks and parent
> for all core peripherals.
> - UBI PLL is mainly used by NSS (Network Switching System).
> IPQ8074 has 2 instances of NSS UBI cores and UBI PLL will
> be used to control the core frequency.
> - NSS Crypto PLL is mainly used by NSS Crypto Engine which
> supports the multiple cryptographic algorithm used in
> Ethernet.
> - IPQ8074 frequency plan does not require change in PLL post
> dividers so marked the same as read-only.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 06/11] clk: qcom: ipq8074: add PCIE, USB and SDCC clocks
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-7-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> - It has 2 instances of PCIE which uses AXI, AHB, AUX, SYS NOC
> AXI and PIPE clocks.
> - It has 2 instances of USB 3.0 which uses AUX, SLEEP, PIPE,
> SYS NOC, mock UTMI and master clocks.
> - It has 2 instances of SDCC which uses APSS and AHB clock.
> SDCC1 requires ICE core clock also.
> - All the PIPE clocks are external clocks which will be
> registered in clock framework by PHY drivers. The enabling
> and disabling of PIPE RCG clocks are dependent upon PHY
> initialization sequence so BRANCH_HALT_DELAY flag is required for
> these clocks.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 07/11] clk: qcom: ipq8074: add NSS clocks
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-8-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> IPQ8074 has NSS (Network Switching System) which has 2 UBI cores
> and hardware crypto engine. Some clocks are separate for each UBI
> core and remaining NSS clocks are common. The BIAS_PLL (300 Mhz)
> and BIAS_PLL_NSS_NOC (416.5 Mhz) are external fixed clocks and
> will be registered from dtsi or NSS driver.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 08/11] clk: qcom: ipq8074: add NSS ethernet port clocks
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513175142-3702-9-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 12/13, Abhishek Sahu wrote:
> IPQ8074 has 6 ethernet ports which supports all ethernet speeds
> from 10Mpbs to 10 Gpbs and each speed requires different clock
> rates. Each port has separate TX and RX clocks. These clocks
> use separate external UNIPHY PLL’s which will be registered with
> separate NSS driver. The clock frequency is 125 Mhz for UNIPHY0
> and 312.5 Mhz for UNIPHY1 and UNIPHY2.
>
> Signed-off-by: Abhishek Sahu <absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 09/11] clk: qcom: ipq8074: add GP and Crypto clocks
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-10-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> - It has 3 general purpose clock controller which supplies
> the clock in GPIO pins.
> - It has Crypto Engine which has AXI, AHB and Core clocks.
> Other non APSS processors can also use Crypto Engine so
> these clocks are marked as VOTED clocks.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 11/11] clk: qcom: ipq8074: add misc resets for PCIE and NSS
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-12-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> PCIE and NSS has MISC reset register in which single register has
> multiple reset bit. The patch adds these resets with its
> corresponding reset bits.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 04/11] dt-bindings: clock: qcom: add remaining clocks for IPQ8074
From: Stephen Boyd @ 2017-12-22 0:24 UTC (permalink / raw)
To: Abhishek Sahu
Cc: Michael Turquette, Rob Herring, Andy Gross, David Brown,
Mark Rutland, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree
In-Reply-To: <1513175142-3702-5-git-send-email-absahu@codeaurora.org>
On 12/13, Abhishek Sahu wrote:
> This patch adds the DT bindings for following IPQ8074 clocks
>
> - General PLL’s, NSS UBI PLL and NSS Crypto PLL.
> - 2 instances of PCIE, USB, SDCC.
> - 2 NSS UBI core and common NSS clocks. NSS is network switching
> system which accelerates the ethernet traffic. IPQ8074
> NSS has two UBI cores. Some clocks are separate for each UBI core
> and remaining NSS clocks are common.
> - NSS ethernet port clocks. IPQ8074 has 6 ethernet ports and
> each port uses different TX and RX clocks.
> - Crypto engine clocks.
> - General purpose clocks which comes over GPIO.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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