* Re: [PATCH v3 4/9] arm: remove wrong CONFIG_PROC_SYSCTL ifdef
From: Vincent Guittot @ 2017-03-29 7:39 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LAK, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter Zijlstra, Rob Herring, Mark Rutland,
Russell King - ARM Linux, Sudeep Holla, Lorenzo Pieralisi,
Catalin Marinas, Will Deacon, Morten Rasmussen, Dietmar Eggemann,
Mark Brown,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
In-Reply-To: <20170327131825.32134-5-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On 27 March 2017 at 15:18, Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org> wrote:
> The sysfs cpu_capacity entry for each CPU has nothing to do with
> PROC_FS, nor it's in /proc/sys path.
>
> Remove such ifdef.
>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Reported-and-suggested-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> Fixes: 7e5930aaef5d ('ARM: 8622/3: add sysfs cpu_capacity attribute')
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
Acked-by: Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index 4e4af809606a..162c82aeed96 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -57,7 +57,6 @@ static void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> per_cpu(cpu_scale, cpu) = capacity;
> }
>
> -#ifdef CONFIG_PROC_SYSCTL
> static ssize_t cpu_capacity_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -114,7 +113,6 @@ static int register_cpu_capacity_sysctl(void)
> return 0;
> }
> subsys_initcall(register_cpu_capacity_sysctl);
> -#endif
>
> #ifdef CONFIG_OF
> struct cpu_efficiency {
> --
> 2.10.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/9] arm: fix return value of parse_cpu_capacity
From: Vincent Guittot @ 2017-03-29 7:37 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, linux-pm@vger.kernel.org, LAK,
devicetree@vger.kernel.org, Peter Zijlstra, Rob Herring,
Mark Rutland, Russell King - ARM Linux, Sudeep Holla,
Lorenzo Pieralisi, Catalin Marinas, Will Deacon, Morten Rasmussen,
Dietmar Eggemann, Mark Brown, gregkh@linuxfoundation.org
In-Reply-To: <20170327131825.32134-4-juri.lelli@arm.com>
On 27 March 2017 at 15:18, Juri Lelli <juri.lelli@arm.com> wrote:
> parse_cpu_capacity() has to return 0 on failure, but it currently returns
> 1 instead if raw_capacity kcalloc failed.
>
> Fix it by removing the negation of the return value.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Reported-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Fixes: 06073ee26775 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT')
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
> arch/arm/kernel/topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index f8a3ab82e77f..4e4af809606a 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -166,7 +166,7 @@ static int __init parse_cpu_capacity(struct device_node *cpu_node, int cpu)
> if (!raw_capacity) {
> pr_err("cpu_capacity: failed to allocate memory for raw capacities\n");
> cap_parsing_failed = true;
> - return !ret;
> + return ret;
Why not directly returning 0 ? whatever the value of ret, the parse of
cpu capacity has failed in this case
> }
> }
> capacity_scale = max(cpu_capacity, capacity_scale);
> --
> 2.10.0
>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Geert Uytterhoeven @ 2017-03-29 7:35 UTC (permalink / raw)
To: Linus Walleij
Cc: jacopo, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdbZS72xkHaM5P-Zw==A_V_BxeszLPmc0_Zy0-RRjvAbNA@mail.gmail.com>
Hi Linus,
On Wed, Mar 29, 2017 at 4:30 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Mar 28, 2017 at 4:38 PM, <jacopo@jmondi.org> wrote:
>>> The fact that historically all the early adopters of pinctrl in device
>>> tree
>>> have these funky custom bindings is unfortunate but just something
>>> that we need to live with.
>>
>> To avoid any confusion, please bear with me and clarify this once and for
>> all,
>> since I'm not certain I fully got you here.
>>
>> Are you suggesting:
>>
>> 1) Use "pins" property with the currently implemented ABI (which slightly
>> differs
>> from the standard documented one as explained above. Not sure it is fine
>> overriding
>> it or not)
>
> Correction: you should be using the property "pinmux", because you
> are setting group and function at the same time.
OK.
> See for example:
> include/dt-bindings/pinctrl/mt65xx.h
>
> And how that is used in:
> arch/arm/boot/dts/mt2701-pinfunc.h
> arch/arm/boot/dts/mt2701-evb.dts
>
> The docs are here:
> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
All of the above pack the information for a pin into a single 32-bit integer.
Is that what you want us to use, too?
Currently we use two integers: 1) pin index, and 2) function/flags combo.
> I'm sorry that "pinmux" is not part of the generic documentation, it'd be
> great if you would like to add it with a patch.
That would mean pinmux could be an array of single values, or tuples.
Is that OK?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller
From: Geert Uytterhoeven @ 2017-03-29 7:30 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdYjZJ7e0tJy6_jfpRT+UDFWqnu8ZX18-gaAHVZLgW-prA@mail.gmail.com>
Hi Linus,
On Fri, Mar 24, 2017 at 4:42 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>
> I assume Geert will queue this driver even if it is outside of sh-pfc?
OK for me, thanks. I was actually wondering about that ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v8 1/3] Input: max11801_ts: Add missing of_match_table
From: Dmitry Torokhov @ 2017-03-29 7:26 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-input, linux-arm-kernel, devicetree, linux-kernel,
Jagan Teki, Shawn Guo, Matteo Lisi, Michael Trimarchi
In-Reply-To: <1490209518-20790-1-git-send-email-jagan@openedev.com>
On Thu, Mar 23, 2017 at 12:35:16AM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Added missing of_match_table for max11801_ts driver with
> compatible as "maxim,max11801_ts"
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied, thank you.
> ---
> Changes for v8:
> - use the compatible as maxim,max11801 with remove suffix _ts since
> i2c node follow the same.
> Changes for v7:
> - newly added patch
>
> drivers/input/touchscreen/max11801_ts.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/max11801_ts.c b/drivers/input/touchscreen/max11801_ts.c
> index a595ae5..d3c7fc0 100644
> --- a/drivers/input/touchscreen/max11801_ts.c
> +++ b/drivers/input/touchscreen/max11801_ts.c
> @@ -224,9 +224,16 @@ static int max11801_ts_probe(struct i2c_client *client,
> };
> MODULE_DEVICE_TABLE(i2c, max11801_ts_id);
>
> +static const struct of_device_id max11801_ts_dt_ids[] = {
> + { .compatible = "maxim,max11801" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, max11801_ts_dt_ids);
> +
> static struct i2c_driver max11801_ts_driver = {
> .driver = {
> .name = "max11801_ts",
> + .of_match_table = max11801_ts_dt_ids,
> },
> .id_table = max11801_ts_id,
> .probe = max11801_ts_probe,
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v8 2/3] dt-bindings: input: touchscreen: Add max11801-ts binding
From: Dmitry Torokhov @ 2017-03-29 7:26 UTC (permalink / raw)
To: Rob Herring
Cc: Jagan Teki, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jagan Teki, Mark Rutland,
Shawn Guo, Michael Trimarchi
In-Reply-To: <20170329015755.zi77exu7tpne3g3n@rob-hp-laptop>
On Tue, Mar 28, 2017 at 08:57:55PM -0500, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 12:35:17AM +0530, Jagan Teki wrote:
> > From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >
> > Add missing documentation of max11801-ts dt-binding details.
> >
> > Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Michael Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > ---
> > Changes for v8:
> > - Use IRQ_TYPE_EDGE_FALLING for interrupt trigger type.
> > Changes for v7:
> > - add vendor prefix as maxim
> > Changes for v6:
> > - Replace the lable and name of the node
> > ts: max11801 => max11801: touchscreen@48
> > Changes for v5:
> > - Newly added patch
> >
> > .../bindings/input/touchscreen/max11801-ts.txt | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied, thank you.
--
Dmitry
--
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] ARM: dts: sun5i: Add interrupt for display backend
From: Chen-Yu Tsai @ 2017-03-29 7:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, David Airlie, Rob Herring, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <20170329071303.ft7oukmhczihy2xb@lukather>
On Wed, Mar 29, 2017 at 3:13 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, Mar 27, 2017 at 10:38:47PM +0800, Chen-Yu Tsai wrote:
>> The display backend on sun5i shares the same interrupt line as the
>> display frontend. Add it.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>
> And ideally, patches prefix shouldn't have dts here too. I've dropped
> it and applied, thanks!
Seems like this was a recent policy change? Or almost everyone was getting
it wrong in the past.
>> This won't directly apply to old releases. We may want to backport
>> them though?
>
> Yep, probably. Do you want to send it to stable?
It won't apply, due to the recent sun5i merger. We could wait until
it lands in Linus' tree, then send a backport patch to stable, to
keep the noise to a minimum.
ChenYu
^ permalink raw reply
* Re: [PATCH] input: matrix_keypad: add option to drive inactive columns
From: Dmitry Torokhov @ 2017-03-29 7:15 UTC (permalink / raw)
To: Rob Herring
Cc: David Rivshin, Mark Rutland, linux-input, devicetree,
linux-kernel
In-Reply-To: <20170329020229.dm3y57dlzjwilifm@rob-hp-laptop>
On Tue, Mar 28, 2017 at 09:02:29PM -0500, Rob Herring wrote:
> On Wed, Mar 22, 2017 at 04:16:50PM -0400, David Rivshin wrote:
> > From: David Rivshin <DRivshin@allworx.com>
> >
> > The gpio-matrix-keypad driver normally sets inactive columns as inputs
> > while scanning. This does not work for all hardware, which may require
> > the inactive columns to be actively driven in order to overcome any
> > pull-ups/downs on the columns.
> >
> > Signed-off-by: David Rivshin <drivshin@allworx.com>
> > ---
> > .../devicetree/bindings/input/gpio-matrix-keypad.txt | 2 ++
> > drivers/input/keyboard/matrix_keypad.c | 13 +++++++++----
> > include/linux/input/matrix_keypad.h | 3 +++
> > 3 files changed, 14 insertions(+), 4 deletions(-)
>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: sun5i: Add interrupt for display backend
From: Maxime Ripard @ 2017-03-29 7:13 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, linux-kernel, dri-devel, linux-sunxi,
Rob Herring, linux-arm-kernel
In-Reply-To: <20170327143847.16259-3-wens@csie.org>
[-- Attachment #1.1: Type: text/plain, Size: 574 bytes --]
On Mon, Mar 27, 2017 at 10:38:47PM +0800, Chen-Yu Tsai wrote:
> The display backend on sun5i shares the same interrupt line as the
> display frontend. Add it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
And ideally, patches prefix shouldn't have dts here too. I've dropped
it and applied, thanks!
> This won't directly apply to old releases. We may want to backport
> them though?
Yep, probably. Do you want to send it to stable?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] drm/sun4i: Add display backend interrupt to device tree binding
From: Maxime Ripard @ 2017-03-29 7:09 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: David Airlie, Rob Herring, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170327143847.16259-2-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Mon, Mar 27, 2017 at 10:38:46PM +0800, Chen-Yu Tsai wrote:
> The display backend has an interrupt line. Add it to the device tree
> binding.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
The patches prefix for the binding documentation is usually
dt-bindings:
I've changed that and applied that patch, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Quentin Schulz @ 2017-03-29 7:09 UTC (permalink / raw)
To: Liam Breck
Cc: Sebastian Reichel, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKvHMgRtEnNbokYReu2vEs9UKH6qZnncdyQD=1JMDTZeN+aYCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Liam,
On 29/03/2017 08:55, Liam Breck wrote:
> Hi Quentin,
>
> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>> Hi Liam,
>>>
>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>> Hi Rob,
>>>>
>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>> Hi Liam,
>>>>>
>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>> in patch description to direct a patch to interested parties and
>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>
>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>> properties of the battery.
>>>>>>>
>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>> handle all charge currents.
>>>>>>>
>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>> ---
>>>>>>>
>>>>>>> v4:
>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>
>>>> Sebastian is on record supporting name alignment between DT:battery
>>>> properties and enum power_supply_property.
>>>>
>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>
>>>> Note that the following could appear in DT:battery in future:
>>>>
>>>> constant-charge-current-microamp
>>>> constant-charge-current-max-microamp
>>>
>>> OK. I am actually setting max constant charge current and constant
>>> current charge with the same DT property so I might need to adapt my
>>> patches.
>>
>> I suspect you should set battery:*-current-max with DT, as -current is
>> "programmed by charger" so seems to be a stat, not a fixed
>> characteristic.
>
> Did you resolve this issue?
>
Sorry, completely missed your first mail.
Constant charge current is actually what I set in the PMIC. The maximum
constant charge current is completely PMIC-agnostic in my driver as it
is used to tell the user that (s)he shouldn't really have a constant
charge current over the maximum limit as the battery might not be able
to handle such high current.
What I suggest is to have both properties in DT. I'll set the maximum as
I do today and we can give the user the ability to set a "default"
constant charge current (below maximum constant charge current) in the
DT. Maybe we do not want to recharge your battery with the maximum value
by default?
> Rob & Sebastian want me to merge all items for
> bindings/power/supply/battery.txt. If I do that I'll also roll up
> their counterparts in power_supply_core.c and submit a patchset for
> those two files.
>
I guess that adding the two properties make sense, don't you think?
Also, could you Cc me on your next version of your patches? So I know
when to rebase and slightly rework my patches once your patch series is
merged.
Thanks,
Quentin
>> You may program your charger's -current with the battery's
>> -current-max, of course.
>>
>> Note that your charger also has a -current-max characteristic, likely
>> different than your battery. You may not need that in DT tho.
>>
>>>> constant-charge-voltage-microvolt
>>>> constant-charge-voltage-max-microvolt
>>>>
>>>> Thanks!
>>>>
>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>> battery.txt - consistency with sysfs names.
>>>>>>
>>>>>
>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>> is nothing in the code that would require the property to be named after
>>>>> a property from the enum power_supply_property.
>>>>>
>>>>> I would say that you _want_ it to be named like that because it
>>>>> underlines the relation between the DT property and the actual impacted
>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>> option and I see arguments on each side.
>>>>>
>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>> this patch.
>>>>>
>>>>> Thanks,
>>>>> Quentin
>>>>>
>>>>>> Also applies to power_supply_core.c patch.
>>>>>>
>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>> hence the -current
>>>>>>
>>>>>>
>>>>>>> added in v3
>>>>>>>
>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>> index 0278617..9594e1e 100644
>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>
>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>> from enum power_supply_property, e.g.
>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>> };
>>>>>>>
>>>>>>> charger: charger@11 {
>>>>>>> --
>>>>>>> 2.9.3
>>>>>>>
>>>>>
>>>>> --
>>>>> Quentin Schulz, Free Electrons
>>>>> Embedded Linux and Kernel engineering
>>>>> http://free-electrons.com
>>>
>>> --
>>> Quentin Schulz, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
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: [RFC PATCH 2/3] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor
From: Icenowy Zheng @ 2017-03-29 6:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: Zhang Rui, linux-pm, Rob Herring, linux-kernel, linux-iio,
devicetree, Lee Jones, Jonathan Cameron, Maxime Ripard,
linux-arm-kernel, Chen-Yu Tsai
2017年3月29日 14:54于 Quentin Schulz <quentin.schulz@free-electrons.com>写道：
>
> Hi,
>
> On 28/03/2017 19:30, Icenowy Zheng wrote:
> > This adds support for the Allwinner H3 thermal sensor.
> >
> > Allwinner H3 has a thermal sensor like the one in A33, but have its
> > registers nearly all re-arranged, sample clock moved to CCU and a pair
> > of bus clock and reset added. It's also the base of newer SoCs' thermal
> > sensors.
> >
> > An option is added to gpadc_data struct, to indicate whether this device
> > is a new-generation Allwinner thermal sensor.
> >
> > The thermal sensors on A64 and H5 is like the one on H3, but with of
> > course different formula factors.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > ---
> > drivers/iio/adc/sun4i-gpadc-iio.c | 130 ++++++++++++++++++++++++++++++++------
> > include/linux/mfd/sun4i-gpadc.h | 33 +++++++++-
> > 2 files changed, 141 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> > index 74705aa37982..7512b1cae877 100644
> > --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> > +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> > @@ -22,6 +22,7 @@
> > * shutdown for not being used.
> > */
> >
> > +#include <linux/clk.h>
> > #include <linux/completion.h>
> > #include <linux/interrupt.h>
> > #include <linux/io.h>
> > @@ -31,6 +32,7 @@
> > #include <linux/platform_device.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/regmap.h>
> > +#include <linux/reset.h>
> > #include <linux/thermal.h>
> > #include <linux/delay.h>
> >
> > @@ -56,6 +58,7 @@ struct gpadc_data {
> > unsigned int tp_adc_select;
> > unsigned int (*adc_chan_select)(unsigned int chan);
> > unsigned int adc_chan_mask;
> > + bool gen2_ths;
> > };
> >
>
> Instead of a boolean, give the TEMP_DATA register address.
>
> > static const struct gpadc_data sun4i_gpadc_data = {
> > @@ -88,7 +91,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
> > static const struct gpadc_data sun8i_a33_gpadc_data = {
> > .temp_offset = -1662,
> > .temp_scale = 162,
> > - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> > + .tp_mode_en = SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN,
> > +};
>
> Separate patch for this?
>
> > +
> > +static const struct gpadc_data sun8i_h3_gpadc_data = {
> > + /*
> > + * The original formula on the datasheet seems to be wrong.
> > + * These factors are calculated based on the formula in the BSP
> > + * kernel, which is originally Tem = 217 - (T / 8.253), in which Tem
> > + * is the temperature in Celsius degree and T is the raw value
> > + * from the sensor.
> > + */
> > + .temp_offset = -1791,
> > + .temp_scale = -121,
> > + .gen2_ths = true,
> > };
> >
> > struct sun4i_gpadc_iio {
> > @@ -103,6 +119,9 @@ struct sun4i_gpadc_iio {
> > atomic_t ignore_temp_data_irq;
> > const struct gpadc_data *data;
> > bool no_irq;
> > + struct clk *ths_bus_clk;
> > + struct clk *ths_clk;
> > + struct reset_control *reset;
> > /* prevents concurrent reads of temperature and ADC */
> > struct mutex mutex;
> > };
> > @@ -274,7 +293,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> > if (info->no_irq) {
> > pm_runtime_get_sync(indio_dev->dev.parent);
> >
> > - regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> > + if (info->data->gen2_ths)
> > + regmap_read(info->regmap, SUN8I_H3_GPADC_TEMP_DATA,
> > + val);
> > + else
> > + regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> >
>
> Instead of gen2_ths, use the TEMP_DATA register address.
>
> > pm_runtime_mark_last_busy(indio_dev->dev.parent);
> > pm_runtime_put_autosuspend(indio_dev->dev.parent);
> > @@ -386,10 +409,15 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
> > {
> > struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> >
> > - /* Disable the ADC on IP */
> > - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> > - /* Disable temperature sensor on IP */
> > - regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> > + if (info->data->gen2_ths) {
> > + /* Disable temperature sensor */
> > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2, 0);
> > + } else {
> > + /* Disable the ADC on IP */
> > + regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> > + /* Disable temperature sensor on IP */
> > + regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> > + }
> >
>
> Either use another register address or add a suspend function to struct
> gpadc_data which will be different for each version of the IP.
>
> > return 0;
> > }
> > @@ -398,19 +426,36 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
> > {
> > struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> >
> > - /* clkin = 6MHz */
> > - regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > - SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> > - SUN4I_GPADC_CTRL0_FS_DIV(7) |
> > - SUN4I_GPADC_CTRL0_T_ACQ(63));
> > - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
> > - regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> > - SUN4I_GPADC_CTRL3_FILTER_EN |
> > - SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > - /* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~0.6s */
> > - regmap_write(info->regmap, SUN4I_GPADC_TPR,
> > - SUN4I_GPADC_TPR_TEMP_ENABLE |
> > - SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> > + if (info->data->gen2_ths) {
> > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2,
> > + SUN8I_H3_GPADC_CTRL2_TEMP_SENSE_EN |
> > + SUN8I_H3_GPADC_CTRL2_T_ACQ1(31));
> > + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > + SUN4I_GPADC_CTRL0_T_ACQ(31));
> > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL3,
> > + SUN4I_GPADC_CTRL3_FILTER_EN |
> > + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > + regmap_write(info->regmap, SUN8I_H3_GPADC_INTC,
> > + SUN8I_H3_GPADC_INTC_TEMP_PERIOD(800));
> > + } else {
> > + /* clkin = 6MHz */
> > + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > + SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> > + SUN4I_GPADC_CTRL0_FS_DIV(7) |
> > + SUN4I_GPADC_CTRL0_T_ACQ(63));
> > + regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
> > + info->data->tp_mode_en);
> > + regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> > + SUN4I_GPADC_CTRL3_FILTER_EN |
> > + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > + /*
> > + * period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin;
> > + * ~0.6s
> > + */
> > + regmap_write(info->regmap, SUN4I_GPADC_TPR,
> > + SUN4I_GPADC_TPR_TEMP_ENABLE |
> > + SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> > + }
> >
>
> Same here as suspend function?
>
> > return 0;
> > }
> > @@ -494,6 +539,10 @@ static const struct of_device_id sun4i_gpadc_of_id[] = {
> > .compatible = "allwinner,sun8i-a33-ths",
> > .data = &sun8i_a33_gpadc_data,
> > },
> > + {
> > + .compatible = "allwinner,sun8i-h3-ths",
> > + .data = &sun8i_h3_gpadc_data,
> > + },
> > { /* sentinel */ }
> > };
> >
> > @@ -529,6 +578,43 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
> > return ret;
> > }
> >
> > + if (info->data->gen2_ths) {
> > + info->reset = devm_reset_control_get(&pdev->dev, NULL);
> > + if (IS_ERR(info->reset)) {
> > + ret = PTR_ERR(info->reset);
> > + return ret;
> > + }
> > +
> > + ret = reset_control_deassert(info->reset);
> > + if (ret)
> > + return ret;
> > +
> > + info->ths_bus_clk = devm_clk_get(&pdev->dev, "bus");
> > + if (IS_ERR(info->ths_bus_clk)) {
> > + ret = PTR_ERR(info->ths_bus_clk);
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(info->ths_bus_clk);
> > + if (ret)
> > + return ret;
> > +
> > + info->ths_clk = devm_clk_get(&pdev->dev, "ths");
> > + if (IS_ERR(info->ths_clk)) {
> > + ret = PTR_ERR(info->ths_clk);
> > + return ret;
> > + }
> > +
> > + /* Running at 6MHz */
> > + ret = clk_set_rate(info->ths_clk, 6000000);
> > + if (ret)
> > + return ret;
> > +
> > + ret = clk_prepare_enable(info->ths_clk);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (!IS_ENABLED(CONFIG_THERMAL_OF))
> > return 0;
> >
> > @@ -691,6 +777,12 @@ static int sun4i_gpadc_remove(struct platform_device *pdev)
> > if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
> > iio_map_array_unregister(indio_dev);
> >
> > + if (info->data->gen2_ths) {
> > + clk_disable_unprepare(info->ths_clk);
> > + clk_disable_unprepare(info->ths_bus_clk);
> > + reset_control_deassert(info->reset);
> > + }
> > +
>
> I'm not really fond of using this boolean as I don't see it being
> possibly reused for any other SoCs that has a GPADC or THS.
Because you didn't care new SoCs :-)
All SoCs after H3 (A64, H5, R40) uses the same THS architecture with H3.
>
> Here, you could make use of a list/array of clk which then can be reused
> for other SoCs just by changing the list. Add a default rate to the
> gpadc_data structure and you're go to go.
>
> > return 0;
> > }
> >
> > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > index 139872c2e0fe..f794a2988a93 100644
> > --- a/include/linux/mfd/sun4i-gpadc.h
> > +++ b/include/linux/mfd/sun4i-gpadc.h
> > @@ -38,9 +38,12 @@
> > #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> > #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
> >
> > -/* TP_CTRL1 bits for sun8i SoCs */
> > -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> > -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> > +/* TP_CTRL1 bits for sun8i A23/A33 SoCs */
> > +#define SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> > +#define SUN8I_A23_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> > +
>
> Different patch for these?
>
> Thanks,
> Quentin
> --
> Quentin Schulz, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Liam Breck @ 2017-03-29 6:55 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKvHMgRKroPFDdNMb=F=bA4bTwg9bYMAR-5Z4DKLzHJtCYz3_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Quentin,
On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> Hi Liam,
>>
>> On 16/03/2017 07:27, Liam Breck wrote:
>>> Hi Rob,
>>>
>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>> Hi Liam,
>>>>
>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>> in patch description to direct a patch to interested parties and
>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>
>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>> properties of the battery.
>>>>>>
>>>>>> The constant charge current is critical for batteries as they can't
>>>>>> handle all charge currents.
>>>>>>
>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> ---
>>>>>>
>>>>>> v4:
>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>
>>> Sebastian is on record supporting name alignment between DT:battery
>>> properties and enum power_supply_property.
>>>
>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>
>>> Note that the following could appear in DT:battery in future:
>>>
>>> constant-charge-current-microamp
>>> constant-charge-current-max-microamp
>>
>> OK. I am actually setting max constant charge current and constant
>> current charge with the same DT property so I might need to adapt my
>> patches.
>
> I suspect you should set battery:*-current-max with DT, as -current is
> "programmed by charger" so seems to be a stat, not a fixed
> characteristic.
Did you resolve this issue?
Rob & Sebastian want me to merge all items for
bindings/power/supply/battery.txt. If I do that I'll also roll up
their counterparts in power_supply_core.c and submit a patchset for
those two files.
> You may program your charger's -current with the battery's
> -current-max, of course.
>
> Note that your charger also has a -current-max characteristic, likely
> different than your battery. You may not need that in DT tho.
>
>>> constant-charge-voltage-microvolt
>>> constant-charge-voltage-max-microvolt
>>>
>>> Thanks!
>>>
>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>> battery.txt - consistency with sysfs names.
>>>>>
>>>>
>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>> is nothing in the code that would require the property to be named after
>>>> a property from the enum power_supply_property.
>>>>
>>>> I would say that you _want_ it to be named like that because it
>>>> underlines the relation between the DT property and the actual impacted
>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>> option and I see arguments on each side.
>>>>
>>>> So, just waiting for maintainer's opinion to make the final version of
>>>> this patch.
>>>>
>>>> Thanks,
>>>> Quentin
>>>>
>>>>> Also applies to power_supply_core.c patch.
>>>>>
>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>> hence the -current
>>>>>
>>>>>
>>>>>> added in v3
>>>>>>
>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>> 1 file changed, 2 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>> index 0278617..9594e1e 100644
>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>
>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>> from enum power_supply_property, e.g.
>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>> + constant-charge-microamp = <300000>;
>>>>>> };
>>>>>>
>>>>>> charger: charger@11 {
>>>>>> --
>>>>>> 2.9.3
>>>>>>
>>>>
>>>> --
>>>> Quentin Schulz, Free Electrons
>>>> Embedded Linux and Kernel engineering
>>>> http://free-electrons.com
>>
>> --
>> Quentin Schulz, Free Electrons
>> Embedded Linux and Kernel engineering
>> 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: [RFC PATCH 2/3] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor
From: Quentin Schulz @ 2017-03-29 6:54 UTC (permalink / raw)
To: Icenowy Zheng, Lee Jones, Rob Herring, Maxime Ripard,
Chen-Yu Tsai, Jonathan Cameron, Zhang Rui
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170328173013.16539-3-icenowy-h8G6r0blFSE@public.gmane.org>
Hi,
On 28/03/2017 19:30, Icenowy Zheng wrote:
> This adds support for the Allwinner H3 thermal sensor.
>
> Allwinner H3 has a thermal sensor like the one in A33, but have its
> registers nearly all re-arranged, sample clock moved to CCU and a pair
> of bus clock and reset added. It's also the base of newer SoCs' thermal
> sensors.
>
> An option is added to gpadc_data struct, to indicate whether this device
> is a new-generation Allwinner thermal sensor.
>
> The thermal sensors on A64 and H5 is like the one on H3, but with of
> course different formula factors.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 130 ++++++++++++++++++++++++++++++++------
> include/linux/mfd/sun4i-gpadc.h | 33 +++++++++-
> 2 files changed, 141 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 74705aa37982..7512b1cae877 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -22,6 +22,7 @@
> * shutdown for not being used.
> */
>
> +#include <linux/clk.h>
> #include <linux/completion.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -31,6 +32,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regmap.h>
> +#include <linux/reset.h>
> #include <linux/thermal.h>
> #include <linux/delay.h>
>
> @@ -56,6 +58,7 @@ struct gpadc_data {
> unsigned int tp_adc_select;
> unsigned int (*adc_chan_select)(unsigned int chan);
> unsigned int adc_chan_mask;
> + bool gen2_ths;
> };
>
Instead of a boolean, give the TEMP_DATA register address.
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -88,7 +91,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> + .tp_mode_en = SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN,
> +};
Separate patch for this?
> +
> +static const struct gpadc_data sun8i_h3_gpadc_data = {
> + /*
> + * The original formula on the datasheet seems to be wrong.
> + * These factors are calculated based on the formula in the BSP
> + * kernel, which is originally Tem = 217 - (T / 8.253), in which Tem
> + * is the temperature in Celsius degree and T is the raw value
> + * from the sensor.
> + */
> + .temp_offset = -1791,
> + .temp_scale = -121,
> + .gen2_ths = true,
> };
>
> struct sun4i_gpadc_iio {
> @@ -103,6 +119,9 @@ struct sun4i_gpadc_iio {
> atomic_t ignore_temp_data_irq;
> const struct gpadc_data *data;
> bool no_irq;
> + struct clk *ths_bus_clk;
> + struct clk *ths_clk;
> + struct reset_control *reset;
> /* prevents concurrent reads of temperature and ADC */
> struct mutex mutex;
> };
> @@ -274,7 +293,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> if (info->no_irq) {
> pm_runtime_get_sync(indio_dev->dev.parent);
>
> - regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> + if (info->data->gen2_ths)
> + regmap_read(info->regmap, SUN8I_H3_GPADC_TEMP_DATA,
> + val);
> + else
> + regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
>
Instead of gen2_ths, use the TEMP_DATA register address.
> pm_runtime_mark_last_busy(indio_dev->dev.parent);
> pm_runtime_put_autosuspend(indio_dev->dev.parent);
> @@ -386,10 +409,15 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> - /* Disable the ADC on IP */
> - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> - /* Disable temperature sensor on IP */
> - regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> + if (info->data->gen2_ths) {
> + /* Disable temperature sensor */
> + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2, 0);
> + } else {
> + /* Disable the ADC on IP */
> + regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> + /* Disable temperature sensor on IP */
> + regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> + }
>
Either use another register address or add a suspend function to struct
gpadc_data which will be different for each version of the IP.
> return 0;
> }
> @@ -398,19 +426,36 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> - /* clkin = 6MHz */
> - regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> - SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> - SUN4I_GPADC_CTRL0_FS_DIV(7) |
> - SUN4I_GPADC_CTRL0_T_ACQ(63));
> - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
> - regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> - SUN4I_GPADC_CTRL3_FILTER_EN |
> - SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> - /* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~0.6s */
> - regmap_write(info->regmap, SUN4I_GPADC_TPR,
> - SUN4I_GPADC_TPR_TEMP_ENABLE |
> - SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> + if (info->data->gen2_ths) {
> + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2,
> + SUN8I_H3_GPADC_CTRL2_TEMP_SENSE_EN |
> + SUN8I_H3_GPADC_CTRL2_T_ACQ1(31));
> + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> + SUN4I_GPADC_CTRL0_T_ACQ(31));
> + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL3,
> + SUN4I_GPADC_CTRL3_FILTER_EN |
> + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> + regmap_write(info->regmap, SUN8I_H3_GPADC_INTC,
> + SUN8I_H3_GPADC_INTC_TEMP_PERIOD(800));
> + } else {
> + /* clkin = 6MHz */
> + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> + SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> + SUN4I_GPADC_CTRL0_FS_DIV(7) |
> + SUN4I_GPADC_CTRL0_T_ACQ(63));
> + regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
> + info->data->tp_mode_en);
> + regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> + SUN4I_GPADC_CTRL3_FILTER_EN |
> + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> + /*
> + * period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin;
> + * ~0.6s
> + */
> + regmap_write(info->regmap, SUN4I_GPADC_TPR,
> + SUN4I_GPADC_TPR_TEMP_ENABLE |
> + SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> + }
>
Same here as suspend function?
> return 0;
> }
> @@ -494,6 +539,10 @@ static const struct of_device_id sun4i_gpadc_of_id[] = {
> .compatible = "allwinner,sun8i-a33-ths",
> .data = &sun8i_a33_gpadc_data,
> },
> + {
> + .compatible = "allwinner,sun8i-h3-ths",
> + .data = &sun8i_h3_gpadc_data,
> + },
> { /* sentinel */ }
> };
>
> @@ -529,6 +578,43 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
> return ret;
> }
>
> + if (info->data->gen2_ths) {
> + info->reset = devm_reset_control_get(&pdev->dev, NULL);
> + if (IS_ERR(info->reset)) {
> + ret = PTR_ERR(info->reset);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(info->reset);
> + if (ret)
> + return ret;
> +
> + info->ths_bus_clk = devm_clk_get(&pdev->dev, "bus");
> + if (IS_ERR(info->ths_bus_clk)) {
> + ret = PTR_ERR(info->ths_bus_clk);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(info->ths_bus_clk);
> + if (ret)
> + return ret;
> +
> + info->ths_clk = devm_clk_get(&pdev->dev, "ths");
> + if (IS_ERR(info->ths_clk)) {
> + ret = PTR_ERR(info->ths_clk);
> + return ret;
> + }
> +
> + /* Running at 6MHz */
> + ret = clk_set_rate(info->ths_clk, 6000000);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(info->ths_clk);
> + if (ret)
> + return ret;
> + }
> +
> if (!IS_ENABLED(CONFIG_THERMAL_OF))
> return 0;
>
> @@ -691,6 +777,12 @@ static int sun4i_gpadc_remove(struct platform_device *pdev)
> if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
> iio_map_array_unregister(indio_dev);
>
> + if (info->data->gen2_ths) {
> + clk_disable_unprepare(info->ths_clk);
> + clk_disable_unprepare(info->ths_bus_clk);
> + reset_control_deassert(info->reset);
> + }
> +
I'm not really fond of using this boolean as I don't see it being
possibly reused for any other SoCs that has a GPADC or THS.
Here, you could make use of a list/array of clk which then can be reused
for other SoCs just by changing the list. Add a default rate to the
gpadc_data structure and you're go to go.
> return 0;
> }
>
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 139872c2e0fe..f794a2988a93 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,9 +38,12 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> -/* TP_CTRL1 bits for sun8i SoCs */
> -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +/* TP_CTRL1 bits for sun8i A23/A33 SoCs */
> +#define SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_A23_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +
Different patch for these?
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
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 v2 2/7] rtc: Add rtc-sh
From: Geert Uytterhoeven @ 2017-03-29 6:49 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Brandt, Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20170329012441.bxnkyqui24mymuvr@rob-hp-laptop>
Hi Rob,
On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>> @@ -0,0 +1,29 @@
>> +* Real Time Clock for Renesas SH and ARM SoCs
>> +
>> +Required properties:
>> +- compatible: Should be "renesas,r7s72100-rtc" and "renesas,sh-rtc" as a
>> + fallback.
>> +- reg: physical base address and length of memory mapped region.
>> +- interrupts: 3 interrupts for alarm, period, and carry.
>> +- interrupt-names: The interrupts should be labeled as "alarm", "period", and
>> + "carry".
>> +- clocks: The functional clock source for the RTC controller must be listed
>> + first (if exists). Additionally, potential clock counting sources are to be
>> + listed.
>> +- clock-names: The functional clock must be labeled as "fck". Other clocks
>> + may be named in accordance to the SoC hardware manuals.
>> +
>> +
>> +Example:
>> +rtc: rtc@fcff1000 {
>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>> + reg = <0xfcff1000 0x2e>;
>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "alarm", "period", "carry";
>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>> + <&rtc_x3_clk>, <&extal_clk>;
>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>> + power-domains = <&cpg_clocks>;
>
> Not documented.
"power-domains" is a platform property.
All hardware components need power.
All synchronous hardware components need a clock.
Most hardware components have a reset signal.
Whether these are exposed and can be controlled depends on the platform/SoC.
So documenting them in each and every device binding looks overkill to me.
I think this is something to be addressed by devicetree-specification (which
doesn't handle clocks, power-domains, resets yet).
If you prefer, the property can be removed from the example, though.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board
From: Jiancheng Xue @ 2017-03-29 6:30 UTC (permalink / raw)
To: robh+dt, xuwei5, arnd, catalin.marinas, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, elder, peter.griffin,
afaerber, yanhaifeng, hermit.wangheming, Jiancheng Xue
In-Reply-To: <1490769009-12552-1-git-send-email-xuejiancheng@hisilicon.com>
Add basic dts files for hi3798cv200-poplar board. Poplar is the
first development board compliant with the 96Boards Enterprise
Edition TV Platform specification. The board features the
Hi3798CV200 with an integrated quad-core 64-bit ARM Cortex A53
processor and high performance Mali T720 GPU.
Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Acked-by: Peter Griffin <peter.griffin@linaro.org>
---
Changed Log:
v3:
- Refined the patch according to Andreas's suggestions.
1. Changed the license.
2. Added alias for uart2.
3. Reordered the device nodes.
v2:
- Fixed issues pointed by Rob Herring.
1. Moved the led node out of the soc node.
2. Restrained the ranges property of soc node smaller.
- Refined the patch according to Andreas's suggestions.
- Enabled gmac1 device node instead of gmac0.
- Added a compatible string "syscon" for crg nodes.
arch/arm64/boot/dts/hisilicon/Makefile | 1 +
.../boot/dts/hisilicon/hi3798cv200-poplar.dts | 163 +++++++++
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 405 +++++++++++++++++++++
3 files changed, 569 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile b/arch/arm64/boot/dts/hisilicon/Makefile
index c3a6c19..8960eca 100644
--- a/arch/arm64/boot/dts/hisilicon/Makefile
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -1,4 +1,5 @@
dtb-$(CONFIG_ARCH_HISI) += hi3660-hikey960.dtb
+dtb-$(CONFIG_ARCH_HISI) += hi3798cv200-poplar.dtb
dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
new file mode 100644
index 0000000..fe2f9f1
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -0,0 +1,163 @@
+/*
+ * DTS File for HiSilicon Poplar Development Board
+ *
+ * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "hi3798cv200.dtsi"
+
+/ {
+ model = "HiSilicon Poplar Development Board";
+ compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
+
+ aliases {
+ serial0 = &uart0;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ user-led0 {
+ label = "USER-LED0";
+ gpios = <&gpio6 3 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ user-led1 {
+ label = "USER-LED1";
+ gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ user-led2 {
+ label = "USER-LED2";
+ gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ };
+
+ user-led3 {
+ label = "USER-LED3";
+ gpios = <&gpio10 6 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ };
+};
+
+&gmac1 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-handle = <ð_phy1>;
+ phy-mode = "rgmii";
+ hisilicon,phy-reset-delays-us = <10000 10000 30000>;
+
+ eth_phy1: phy@3 {
+ reg = <3>;
+ };
+};
+
+&gpio1 {
+ status = "okay";
+ gpio-line-names = "LS-GPIO-E", "",
+ "", "",
+ "", "LS-GPIO-F",
+ "", "LS-GPIO-J";
+};
+
+&gpio2 {
+ status = "okay";
+ gpio-line-names = "LS-GPIO-H", "LS-GPIO-I",
+ "LS-GPIO-L", "LS-GPIO-G",
+ "LS-GPIO-K", "",
+ "", "";
+};
+
+&gpio3 {
+ status = "okay";
+ gpio-line-names = "", "",
+ "", "",
+ "LS-GPIO-C", "",
+ "", "LS-GPIO-B";
+};
+
+&gpio4 {
+ status = "okay";
+ gpio-line-names = "", "",
+ "", "",
+ "", "LS-GPIO-D",
+ "", "";
+};
+
+&gpio5 {
+ status = "okay";
+ gpio-line-names = "", "USER-LED-1",
+ "USER-LED-2", "",
+ "", "LS-GPIO-A",
+ "", "";
+};
+
+&gpio6 {
+ status = "okay";
+ gpio-line-names = "", "",
+ "", "USER-LED-0",
+ "", "",
+ "", "";
+};
+
+&gpio10 {
+ status = "okay";
+ gpio-line-names = "", "",
+ "", "",
+ "", "",
+ "USER-LED-3", "";
+};
+
+&i2c0 {
+ status = "okay";
+ label = "LS-I2C0";
+};
+
+&i2c2 {
+ status = "okay";
+ label = "LS-I2C1";
+};
+
+&ir {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+ label = "LS-SPI0";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+ label = "LS-UART0";
+};
+/* No optional LS-UART1 on Low Speed Expansion Connector. */
+
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
new file mode 100644
index 0000000..e94d6f6
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -0,0 +1,405 @@
+/*
+ * DTS File for HiSilicon Hi3798cv200 SoC.
+ *
+ * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include <dt-bindings/clock/histb-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/ti-syscon.h>
+
+/ {
+ compatible = "hisilicon,hi3798cv200";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ gic: interrupt-controller@f1001000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xf1001000 0x0 0x1000>, /* GICD */
+ <0x0 0xf1002000 0x0 0x100>; /* GICC */
+ #address-cells = <0>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ soc: soc@f0000000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0xf0000000 0x10000000>;
+
+ crg: clock-reset-controller@8a22000 {
+ compatible = "hisilicon,hi3798cv200-crg", "syscon", "simple-mfd";
+ reg = <0x8a22000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+
+ gmacphyrst: reset-controller {
+ compatible = "ti,syscon-reset";
+ #reset-cells = <1>;
+ ti,reset-bits =
+ <0xcc 12 0xcc 12 0 0 (ASSERT_CLEAR|DEASSERT_SET|STATUS_NONE)>, /* 0: gmac0-phy-rst */
+ <0xcc 13 0xcc 13 0 0 (ASSERT_CLEAR|DEASSERT_SET|STATUS_NONE)>; /* 1: gmac1-phy-rst */
+ };
+ };
+
+ sysctrl: system-controller@8000000 {
+ compatible = "hisilicon,hi3798cv200-sysctrl", "syscon";
+ reg = <0x8000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+ };
+
+ uart0: serial@8b00000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x8b00000 0x1000>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl HISTB_UART0_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ uart2: serial@8b02000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x8b02000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg HISTB_UART2_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ i2c0: i2c@8b10000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0x8b10000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&crg HISTB_I2C0_CLK>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@8b11000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0x8b11000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&crg HISTB_I2C1_CLK>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@8b12000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0x8b12000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&crg HISTB_I2C2_CLK>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@8b13000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0x8b13000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&crg HISTB_I2C3_CLK>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@8b14000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0x8b14000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&crg HISTB_I2C4_CLK>;
+ status = "disabled";
+ };
+
+ spi0: spi@8b1a000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x8b1a000 0x1000>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ num-cs = <1>;
+ cs-gpios = <&gpio7 1 0>;
+ clocks = <&crg HISTB_SPI0_CLK>;
+ clock-names = "apb_pclk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ emmc: mmc@9830000 {
+ compatible = "snps,dw-mshc";
+ reg = <0x9830000 0x10000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg HISTB_MMC_CIU_CLK>,
+ <&crg HISTB_MMC_BIU_CLK>;
+ clock-names = "ciu", "biu";
+ };
+
+ gpio0: gpio@8b20000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b20000 0x1000>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio1: gpio@8b21000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b21000 0x1000>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio2: gpio@8b22000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b22000 0x1000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio3: gpio@8b23000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b23000 0x1000>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio4: gpio@8b24000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b24000 0x1000>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio5: gpio@8004000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8004000 0x1000>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio6: gpio@8b26000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b26000 0x1000>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio7: gpio@8b27000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b27000 0x1000>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio8: gpio@8b28000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b28000 0x1000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio9: gpio@8b29000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b29000 0x1000>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio10: gpio@8b2a000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b2a000 0x1000>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio11: gpio@8b2b000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b2b000 0x1000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpio12: gpio@8b2c000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x8b2c000 0x1000>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&crg HISTB_APB_CLK>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gmac0: ethernet@9840000 {
+ compatible = "hisilicon,hi3798cv200-gmac", "hisilicon,hisi-gmac-v2";
+ reg = <0x9840000 0x1000>,
+ <0x984300c 0x4>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg HISTB_ETH0_MAC_CLK>,
+ <&crg HISTB_ETH0_MACIF_CLK>;
+ clock-names = "mac_core", "mac_ifc";
+ resets = <&crg 0xcc 8>,
+ <&crg 0xcc 10>,
+ <&gmacphyrst 0>;
+ reset-names = "mac_core", "mac_ifc", "phy";
+ status = "disabled";
+ };
+
+ gmac1: ethernet@9841000 {
+ compatible = "hisilicon,hi3798cv200-gmac", "hisilicon,hisi-gmac-v2";
+ reg = <0x9841000 0x1000>,
+ <0x9843010 0x4>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg HISTB_ETH1_MAC_CLK>,
+ <&crg HISTB_ETH1_MACIF_CLK>;
+ clock-names = "mac_core", "mac_ifc";
+ resets = <&crg 0xcc 9>,
+ <&crg 0xcc 11>,
+ <&gmacphyrst 1>;
+ reset-names = "mac_core", "mac_ifc", "phy";
+ status = "disabled";
+ };
+
+ ir: ir@8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0x8001000 0x1000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl HISTB_IR_CLK>;
+ status = "disabled";
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board
From: Jiancheng Xue @ 2017-03-29 6:30 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
arnd-r2nGTMty4D4, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, elder-QSEj5FYQhm4dnm+yROfE0A,
peter.griffin-QSEj5FYQhm4dnm+yROfE0A, afaerber-l3A5Bk7waGM,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
hermit.wangheming-C8/M+/jPZTeaMJb+Lgu22Q, Jiancheng Xue
In-Reply-To: <1490769009-12552-1-git-send-email-xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board.
Signed-off-by: Jiancheng Xue <xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Reviewed-by: Alex Elder <elder-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index f1c1e21..1fd3dd7 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -4,6 +4,10 @@ Hi3660 SoC
Required root node properties:
- compatible = "hisilicon,hi3660";
+Hi3798cv200 Poplar Board
+Required root node properties:
+ - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
+
Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/2] add dts files for hi3798cv200-Poplar board
From: Jiancheng Xue @ 2017-03-29 6:30 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
arnd-r2nGTMty4D4, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, elder-QSEj5FYQhm4dnm+yROfE0A,
peter.griffin-QSEj5FYQhm4dnm+yROfE0A, afaerber-l3A5Bk7waGM,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
hermit.wangheming-C8/M+/jPZTeaMJb+Lgu22Q, Jiancheng Xue
This patch set mainly adds dts files for hi3798cv200-Poplar board.
Jiancheng Xue (2):
dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and
Poplar board
arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board
.../bindings/arm/hisilicon/hisilicon.txt | 4 +
arch/arm64/boot/dts/hisilicon/Makefile | 1 +
.../boot/dts/hisilicon/hi3798cv200-poplar.dts | 163 +++++++++
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 405 +++++++++++++++++++++
4 files changed, 573 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2,1/3] meson_uart: expose CLKID_UARTx
From: Jerome Brunet @ 2017-03-29 6:21 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Helmut Klein, mturquette, sboyd, devicetree, linux-clk,
linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <CAFBinCDF29+kQpedsJPqRy6fztWrj91Qi6tCno_2S6UCkhW7XQ@mail.gmail.com>
On Tue, 2017-03-28 at 23:24 +0200, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Tue, Mar 28, 2017 at 9:14 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> > On Tue, 2017-03-28 at 20:18 +0200, Helmut Klein wrote:
> > > i know for sure that the bluetooth chip of my system is connected to
> > > uart_A. so this clock must be exposed.
> > >
> > > i don't know if the other 2 uarts are used on other hardware. so i will
> > > remove them from my patch.
> >
> > What I meant is device trees "upstream".
> > I would expect such patch as part of a series to add support for your board
> > in
> > device-tree, with its bluetooth chipset.
>
> are you sure about this?
Actually no ;) I started questioning this reply as soon as I sent it.
the moto so far as been "we expose what's needed" but there is many ways to
interpret that.
DT bindings is an ABI. Simply because we don't use part of that ABI upstream,
doesn't mean we shouldn't provide it. My previous statement was clearly wrong
about this, apologies.
> Helmut is configuring the core clock of the
> UART controller(s) here. we have the same thing for many other drivers
> as well (MMC, SAR ADC, I2C, SPI, ethernet, you name it...) - these
> clocks are not part of a device specific .dts but rather the SoC
> specific dts (for example meson-gxbb.dtsi - because these clocks are
> not board specific).
Agreed
Since Helmut tested it, this clock should be added to the dtsi.
> I guess most boards are not affected because the bootloader simply
> enables the UART0 core/gate clock and keeps it enabled when booting
> the kernel. additionally our clock gates are marked with
> CLK_IGNORE_UNUSED so if the bootloader keeps the gates enabled then
> we're not disabling it either.
>
> > I think it would better to drop this patch from the series.
> > You can either keep it for your personal work, or send it again when
> > upstreaming
> > the support for your board and/or add the support for the bluetooth chip.
>
> if we decide to pass the core/gate clock directly in SoC.dtsi then we
> should think about doing it for all three non-AO UARTs (uart_a, uart_b
> and uart_c).
> we can test uart_b on GPIODV_24 and GPIODV_25 on the Khadas VIM board
> for example (pins 22 and 23 on the header, default mode of these pins
> is i2c_sck_a and i2c_sda_a, but we can re-configure it).
> uart_c unfortunately cannot be tested on the Khadas VIM board since
> it's only routed to GPIOX_8 and GPIOX_9 which are hard-wired to the
> bluetooth module's PCM pins (BTPCM_DOUT and BTPCM_DIN).
>
> for Helmut this would mean that instead of dropping this patch (or
> dropping CLKID_UART1 and CLKID_UART2 from this patch) he would rather
> have to *add* another patch (for meson-gxbb.dtsi and meson-gxl.dtsi)
> which passes the core clocks to the corresponding UART controllers
> (similar to the CLKID_SD_EMMC_ clocks).
You are right. This could be part of another series.
I guess this patch fine as it is.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
>
> Regards,
> Martin
>
>
> [0] http://lxr.free-electrons.com/source/drivers/clk/meson/clkc.h?v=4.10#L110
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 6/8] regulator: arizona-micbias: Add regulator driver for Arizona micbiases
From: kbuild test robot @ 2017-03-29 6:18 UTC (permalink / raw)
To: Charles Keepax
Cc: kbuild-all-JC7UmRfGjtg, broonie-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lee.jones-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1490710484-25277-6-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 11182 bytes --]
Hi Charles,
[auto build test WARNING on regulator/for-next]
[also build test WARNING on v4.11-rc4 next-20170328]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Charles-Keepax/regulator-arizona-micsupp-Avoid-potential-memory-leak-reading-init_data/20170329-112224
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: i386-randconfig-x0-03291136 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/err.h:4:0,
from include/linux/clk.h:15,
from drivers//mfd/arizona-core.c:13:
drivers//mfd/arizona-core.c: In function 'arizona_dev_init':
drivers//mfd/arizona-core.c:1408:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV &&
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1409:33: error: 'struct arizona_micbias' has no member named 'bypass'
!arizona->pdata.micbias[i].bypass)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1408:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV &&
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1409:33: error: 'struct arizona_micbias' has no member named 'bypass'
!arizona->pdata.micbias[i].bypass)
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1408:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV &&
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1409:33: error: 'struct arizona_micbias' has no member named 'bypass'
!arizona->pdata.micbias[i].bypass)
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> drivers//mfd/arizona-core.c:1408:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV &&
^~
drivers//mfd/arizona-core.c:1413:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1413:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV)
^~
drivers//mfd/arizona-core.c:1413:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV)
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1413:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV)
^~
drivers//mfd/arizona-core.c:1413:33: error: 'struct arizona_micbias' has no member named 'mV'
if (!arizona->pdata.micbias[i].mV)
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
drivers//mfd/arizona-core.c:1413:3: note: in expansion of macro 'if'
if (!arizona->pdata.micbias[i].mV)
^~
drivers//mfd/arizona-core.c:1414:29: error: 'struct arizona_micbias' has no member named 'mV'
arizona->pdata.micbias[i].mV = 2800;
^
drivers//mfd/arizona-core.c:1416:35: error: 'struct arizona_micbias' has no member named 'mV'
val = (arizona->pdata.micbias[i].mV - 1500) / 100;
^
In file included from include/linux/err.h:4:0,
from include/linux/clk.h:15,
from drivers//mfd/arizona-core.c:13:
drivers//mfd/arizona-core.c:1423:32: error: 'struct arizona_micbias' has no member named 'discharge'
if (arizona->pdata.micbias[i].discharge)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1423:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].discharge)
^~
drivers//mfd/arizona-core.c:1423:32: error: 'struct arizona_micbias' has no member named 'discharge'
if (arizona->pdata.micbias[i].discharge)
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1423:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].discharge)
^~
drivers//mfd/arizona-core.c:1423:32: error: 'struct arizona_micbias' has no member named 'discharge'
if (arizona->pdata.micbias[i].discharge)
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
drivers//mfd/arizona-core.c:1423:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].discharge)
^~
drivers//mfd/arizona-core.c:1426:32: error: 'struct arizona_micbias' has no member named 'soft_start'
if (arizona->pdata.micbias[i].soft_start)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1426:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].soft_start)
^~
drivers//mfd/arizona-core.c:1426:32: error: 'struct arizona_micbias' has no member named 'soft_start'
if (arizona->pdata.micbias[i].soft_start)
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1426:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].soft_start)
^~
drivers//mfd/arizona-core.c:1426:32: error: 'struct arizona_micbias' has no member named 'soft_start'
if (arizona->pdata.micbias[i].soft_start)
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
drivers//mfd/arizona-core.c:1426:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].soft_start)
^~
drivers//mfd/arizona-core.c:1429:32: error: 'struct arizona_micbias' has no member named 'bypass'
if (arizona->pdata.micbias[i].bypass)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers//mfd/arizona-core.c:1429:3: note: in expansion of macro 'if'
if (arizona->pdata.micbias[i].bypass)
vim +/if +1408 drivers//mfd/arizona-core.c
3cc72986 Mark Brown 2012-06-19 1392 ARIZONA_CLK_32K_SRC_MASK,
3cc72986 Mark Brown 2012-06-19 1393 arizona->pdata.clk32k_src - 1);
767c6dc0 Mark Brown 2013-03-19 1394 arizona_clk32k_enable(arizona);
3cc72986 Mark Brown 2012-06-19 1395 break;
3cc72986 Mark Brown 2012-06-19 1396 case ARIZONA_32KZ_NONE:
3cc72986 Mark Brown 2012-06-19 1397 regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
3cc72986 Mark Brown 2012-06-19 1398 ARIZONA_CLK_32K_SRC_MASK, 2);
3cc72986 Mark Brown 2012-06-19 1399 break;
3cc72986 Mark Brown 2012-06-19 1400 default:
3cc72986 Mark Brown 2012-06-19 1401 dev_err(arizona->dev, "Invalid 32kHz clock source: %d\n",
3cc72986 Mark Brown 2012-06-19 1402 arizona->pdata.clk32k_src);
3cc72986 Mark Brown 2012-06-19 1403 ret = -EINVAL;
59db9691 Mark Brown 2012-07-09 1404 goto err_reset;
3cc72986 Mark Brown 2012-06-19 1405 }
3cc72986 Mark Brown 2012-06-19 1406
3d91f828 Mark Brown 2013-01-29 1407 for (i = 0; i < ARIZONA_MAX_MICBIAS; i++) {
544c7aad Mark Brown 2013-01-29 @1408 if (!arizona->pdata.micbias[i].mV &&
544c7aad Mark Brown 2013-01-29 1409 !arizona->pdata.micbias[i].bypass)
3d91f828 Mark Brown 2013-01-29 1410 continue;
3d91f828 Mark Brown 2013-01-29 1411
544c7aad Mark Brown 2013-01-29 1412 /* Apply default for bypass mode */
544c7aad Mark Brown 2013-01-29 1413 if (!arizona->pdata.micbias[i].mV)
544c7aad Mark Brown 2013-01-29 1414 arizona->pdata.micbias[i].mV = 2800;
544c7aad Mark Brown 2013-01-29 1415
3d91f828 Mark Brown 2013-01-29 1416 val = (arizona->pdata.micbias[i].mV - 1500) / 100;
:::::: The code at line 1408 was first introduced by commit
:::::: 544c7aadd7d4309ed01fcd787d393db67eb7eaea mfd: arizona: Support configuring MICBIASes into bypass mode
:::::: TO: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
:::::: CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26803 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] extcon: usb-gpio: Add level trigger support
From: Baolin Wang @ 2017-03-29 6:08 UTC (permalink / raw)
To: Rob Herring
Cc: Chanwoo Choi, MyungJoo Ham, Mark Rutland, Mark Brown,
Linaro Kernel Mailman List, LKML,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqLOHP5fVcJDf+aMWFmPSHiBnHHfcPm4xu1CZJjWo9GtdQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 24 March 2017 at 20:41, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Mar 24, 2017 at 6:56 AM, Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Hi,
>>
>> On 24 March 2017 at 19:08, Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>> Hi,
>>>
>>> On 2017년 03월 20일 16:59, Baolin Wang wrote:
>>>> Now extcon-usb-gpio only supports for GPIO egdge trigger, but VBUS/ID
>>>> gpios' detection can be triggered by the level trigger on some platforms.
>>>> Thus intoduce one property 'extcon-gpio,level-trigger' to identify this
>>>> situation.
>>>>
>>>> Signed-off-by: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>>> index dfc14f7..191504b 100644
>>>> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>>> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>>> @@ -9,6 +9,9 @@ Required properties:
>>>> Either one of id-gpio or vbus-gpio must be present. Both can be present as well.
>>>> - id-gpio: gpio for USB ID pin. See gpio binding.
>>>> - vbus-gpio: gpio for USB VBUS pin.
>>>> +- extcon-gpio,level-trigger: Boolean, set this gpio's interrupt flag to
>>>
>>> It is 'extcon-usb-gpio' instead of 'extcon-gpio'.
>>
>> Sure.
>
> "extcon-gpio" is not a vendor, so don't make it a vendor prefix.
OK.
>
>>>> +level trigger. If not specified defaults to false, gpio's interrupt flag
>>>> +defaults to edge trigger.
>>>
>>> I understand why you need the new flag.
>>> But, I'm not sure it is right way to add the new flag for interrupt flag.
>>>
>>> IMHO, I think that we need to find the more proper way to get the interrupt flag
>>> or maybe, we may need to implement the new helper api to get the interrupt
>>> flag for gpio pin when we use the gpio as the interrupt source,
>>
>> Yes, I agree with you. We already have helper functions to get
>> interrupt flag from device tree, but we can not get the irq number of
>> GPIO to configure in device tree, then I introduce one new flag to
>> indicate the trigger type. But I like to change the patch if there are
>> any good suggestion. Thanks.
>
> The extcon binding needs an overhaul in general. I'm not going to take
> extensions to a broken binding. What's needed is a USB connector
> binding like we have for HDMI and other video connectors. And for
> USB-C, those need to be combined.
I am not sure I understand your points correctly, could you elaborate
on how to modify for extcon? Thanks.
--
Baolin.wang
Best Regards
--
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 v6 0/4] Broadcom SBA RAID support
From: Anup Patel @ 2017-03-29 6:05 UTC (permalink / raw)
To: Vinod Koul
Cc: Jassi Brar, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Dan Williams, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback, dmaengine, Device Tree,
Linux ARM Kernel, Linux Kernel, linux-crypto, linux-raid
In-Reply-To: <20170321091829.GZ2843@localhost>
On Tue, Mar 21, 2017 at 2:48 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Tue, Mar 21, 2017 at 02:17:21PM +0530, Anup Patel wrote:
>> On Tue, Mar 21, 2017 at 2:00 PM, Vinod Koul <vinod.koul@intel.com> wrote:
>> > On Mon, Mar 06, 2017 at 03:13:24PM +0530, Anup Patel wrote:
>> >> The Broadcom SBA RAID is a stream-based device which provides
>> >> RAID5/6 offload.
>> >>
>> >> It requires a SoC specific ring manager (such as Broadcom FlexRM
>> >> ring manager) to provide ring-based programming interface. Due to
>> >> this, the Broadcom SBA RAID driver (mailbox client) implements
>> >> DMA device having one DMA channel using a set of mailbox channels
>> >> provided by Broadcom SoC specific ring manager driver (mailbox
>> >> controller).
>> >>
>> >> The Broadcom SBA RAID hardware requires PQ disk position instead
>> >> of PQ disk coefficient. To address this, we have added raid_gflog
>> >> table which will help driver to convert PQ disk coefficient to PQ
>> >> disk position.
>> >>
>> >> This patchset is based on Linux-4.11-rc1 and depends on patchset
>> >> "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
>> >
>> > Okay I applied and was about to push when I noticed this :(
>> >
>> > So what is the status of this..?
>>
>> PATCH2 is Acked but PATCH1 is under-review. Currently, its
>> v6 of that patchset.
>>
>> The only dependency on that patchset is the changes in
>> brcm-message.h which are required by this BCM-SBA-RAID
>> driver.
>>
>> @Jassi,
>> Can you please have a look at PATCH v6?
>
> And I would need an immutable branch/tag once merged. I am going to keep
> this series pending till then.
The Broadcom FlexRM patchset is pickedup by Jassi and
can be found in mailbox-for-next branch of
git://git.linaro.org/landing-teams/working/fujitsu/integration
Both patchset (Broadcom FlexRM patchset and this one) are
also available in sba-raid-v7 branch of
https://github.com/Broadcom/arm64-linux.git
Regards,
Anup
^ permalink raw reply
* Re: [PATCH v7 0/3] Broadcom FlexRM ring manager support
From: Anup Patel @ 2017-03-29 5:52 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, Devicetree List, Linux Kernel Mailing List,
linux-arm-kernel@lists.infradead.org, BCM Kernel Feedback
In-Reply-To: <CABb+yY3n2OuvBKfsWj5m5RvdBEZ5_aWpVNUJ9V8oikyJjchZAw@mail.gmail.com>
On Wed, Mar 29, 2017 at 11:05 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> On Wed, Mar 29, 2017 at 11:00 AM, Anup Patel <anup.patel@broadcom.com> wrote:
>> The Broadcom FlexRM ring manager provides producer-consumer style
>> ring interface for offload engines on Broadcom iProc SoCs. We can
>> have one or more instances of Broadcom FlexRM ring manager in a SoC.
>>
>> This patchset adds a mailbox driver for Broadcom FlexRM ring manager
>> which can be used by offload engine drivers as mailbox clients.
>>
>> The Broadcom FlexRM mailbox driver is feature complete for RAID and
>> Crypto offload engines. We will have incremental patches in-future
>> for ring-level statistics using debugfs and minor optimizations.
>>
>> This patchset is based on Linux-4.11-rc4 and it is also available
>> at flexrm-v7 branch of https://github.com/Broadcom/arm64-linux.git
>>
>> Changes since v6:
>> - Rebased patches for Linux-4.11-rc4
>> - Added a patch to remove depends on COMPILE_TEST for kconfig
>> option BCM_FLEXRM_MBOX
>>
> You only needed to send the fix to compilation failure reports, not
> the whole series.
My bad for the noise.
> I believe only the patch-3 is new in the series and I need not even
> look at patch-1,2 ?
Yes, only patch-3 is required to fix compilation failure.
Regards,
Anup
^ permalink raw reply
* Re: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza via iommu @ 2017-03-29 5:46 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Linux IOMMU,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAMSpPPfJKKRkuDKxUgVBdg7vp7Ux5=PiHSxnMLc7-LMcCSatzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>> For PCI masters not represented in DT, we pass the OF node of their
>> associated host bridge to of_dma_configure(), such that they can inherit
>> the appropriate DMA configuration from whatever is described there.
>> Unfortunately, whilst this has worked for the "dma-coherent" property,
>> it turns out to miss the case where the host bridge node has a non-empty
>> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>>
>> It transpires, though, that the de-facto interface since the prototype
>> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
>> re-use") is very clear-cut: either the master_np argument is redundant
>> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
>> parent bus. Let's ratify that behaviour, then teach the whole
>> of_dma_configure() pipeline to cope with both cases properly.
>>
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> ---
>>
>> This is what I'd consider the better fix - rather than adding yet more
>> special cases - which will also make it simple to handle multiple
>> "dma-ranges" entries with minimal further disruption. The callers now
>> left passing dev->of_node as 'parent' are harmless, but look a bit silly
>> and clearly want cleaning up - I'd be partial to renaming the existing
>> function and having a single-argument wrapper for the 'normal' case, e.g.:
>>
>> static inline int of_dma_configure(struct device_node *dev)
>> {
>> return of_dma_configure_parent(dev, NULL);
>> }
>>
>> Thoughts?
>>
>> Robin.
>>
>> drivers/iommu/of_iommu.c | 7 ++++---
>> drivers/of/address.c | 37 +++++++++++++++++++++++++------------
>> drivers/of/device.c | 12 +++++++-----
>> include/linux/of_address.h | 7 ++++---
>> include/linux/of_device.h | 4 ++--
>> include/linux/of_iommu.h | 4 ++--
>> 6 files changed, 44 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 2683e9fc0dcf..35aff07bb5eb 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -138,21 +138,22 @@ static const struct iommu_ops
>> }
>>
>> const struct iommu_ops *of_iommu_configure(struct device *dev,
>> - struct device_node *master_np)
>> + struct device_node *parent)
>> {
>> struct of_phandle_args iommu_spec;
>> - struct device_node *np;
>> + struct device_node *np, *master_np;
>> const struct iommu_ops *ops = NULL;
>> int idx = 0;
>>
>> if (dev_is_pci(dev))
>> - return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>> + return of_pci_iommu_configure(to_pci_dev(dev), parent);
>>
>> /*
>> * We don't currently walk up the tree looking for a parent IOMMU.
>> * See the `Notes:' section of
>> * Documentation/devicetree/bindings/iommu/iommu.txt
>> */
>> + master_np = dev->of_node ? dev->of_node : parent;
>> while (!of_parse_phandle_with_args(master_np, "iommus",
>> "#iommu-cells", idx,
>> &iommu_spec)) {
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903fe9d2..833bc17f5e55 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -808,6 +808,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
>> /**
>> * of_dma_get_range - Get DMA range info
>> * @np: device node to get DMA range info
>> + * @parent: node of device's parent bus, if @np is NULL
>> * @dma_addr: pointer to store initial DMA address of DMA range
>> * @paddr: pointer to store initial CPU address of DMA range
>> * @size: pointer to store size of DMA range
>> @@ -822,36 +823,48 @@ EXPORT_SYMBOL(of_io_request_and_map);
>> * It returns -ENODEV if "dma-ranges" property was not found
>> * for this device in DT.
>> */
>> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
>> +int of_dma_get_range(struct device_node *np, struct device_node *parent,
>> + u64 *dma_addr, u64 *paddr, u64 *size)
>> {
>> - struct device_node *node = of_node_get(np);
>> + struct device_node *node;
>> const __be32 *ranges = NULL;
>> int len, naddr, nsize, pna;
>> int ret = 0;
>> u64 dmaaddr;
>>
>> - if (!node)
>> - return -EINVAL;
>> -
>> - while (1) {
>> + if (np) {
>> + node = of_node_get(np);
>> naddr = of_n_addr_cells(node);
>> nsize = of_n_size_cells(node);
>> node = of_get_next_parent(node);
>> - if (!node)
>> - break;
>> + } else if (parent) {
>> + node = of_node_get(parent);
>> + np = parent;
>> + if (of_property_read_u32(node, "#address-cells", &naddr))
>> + naddr = of_n_addr_cells(node);
>> + if (of_property_read_u32(node, "#size-cells", &nsize))
>> + nsize = of_n_size_cells(node);
>> + } else {
>> + return -EINVAL;
>> + }
>>
>> + while (node) {
>> ranges = of_get_property(node, "dma-ranges", &len);
>>
>> - /* Ignore empty ranges, they imply no translation required */
>> - if (ranges && len > 0)
>> - break;
>> -
>> /*
>> * At least empty ranges has to be defined for parent node if
>> * DMA is supported
>> */
>> if (!ranges)
>> break;
>> +
>> + /* Ignore empty ranges, they imply no translation required */
>> + if (len > 0)
>> + break;
>> +
>> + naddr = of_n_addr_cells(node);
>> + nsize = of_n_size_cells(node);
>> + node = of_get_next_parent(node);
>> }
>>
>> if (!ranges) {
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index 9bb8518b28f2..57ec5324ed6c 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -73,7 +73,8 @@ int of_device_add(struct platform_device *ofdev)
>> /**
>> * of_dma_configure - Setup DMA configuration
>> * @dev: Device to apply DMA configuration
>> - * @np: Pointer to OF node having DMA configuration
>> + * @parent: OF node of device's parent bus, if @dev is not
>> + * represented in DT (i.e. @dev->of_node is NULL)
>> *
>> * Try to get devices's DMA configuration from DT and update it
>> * accordingly.
>> @@ -82,13 +83,14 @@ int of_device_add(struct platform_device *ofdev)
>> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
>> * to fix up DMA configuration.
>> */
>> -void of_dma_configure(struct device *dev, struct device_node *np)
>> +void of_dma_configure(struct device *dev, struct device_node *parent)
>> {
>> u64 dma_addr, paddr, size;
>> int ret;
>> bool coherent;
>> unsigned long offset;
>> const struct iommu_ops *iommu;
>> + struct device_node *np = dev->of_node;
>>
>> /*
>> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
>> @@ -104,7 +106,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> if (!dev->dma_mask)
>> dev->dma_mask = &dev->coherent_dma_mask;
>>
>> - ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> + ret = of_dma_get_range(np, parent, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> size = dev->coherent_dma_mask + 1;
>> @@ -132,11 +134,11 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
>> *dev->dma_mask = dev->coherent_dma_mask;
>>
>> - coherent = of_dma_is_coherent(np);
>> + coherent = of_dma_is_coherent(np ? np : parent);
>> dev_dbg(dev, "device is%sdma coherent\n",
>> coherent ? " " : " not ");
>>
>> - iommu = of_iommu_configure(dev, np);
>> + iommu = of_iommu_configure(dev, parent);
>> dev_dbg(dev, "device is%sbehind an iommu\n",
>> iommu ? " " : " not ");
>>
>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> index 37864734ca50..f1a507f3ae57 100644
>> --- a/include/linux/of_address.h
>> +++ b/include/linux/of_address.h
>> @@ -52,8 +52,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>> extern struct of_pci_range *of_pci_range_parser_one(
>> struct of_pci_range_parser *parser,
>> struct of_pci_range *range);
>> -extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
>> - u64 *paddr, u64 *size);
>> +extern int of_dma_get_range(struct device_node *np, struct device_node *parent,
>> + u64 *dma_addr, u64 *paddr, u64 *size);
>> extern bool of_dma_is_coherent(struct device_node *np);
>> #else /* CONFIG_OF_ADDRESS */
>> static inline void __iomem *of_io_request_and_map(struct device_node *device,
>> @@ -95,7 +95,8 @@ static inline struct of_pci_range *of_pci_range_parser_one(
>> return NULL;
>> }
>>
>> -static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
>> +static inline int of_dma_get_range(struct device_node *np,
>> + struct device_node *parent, u64 *dma_addr,
>> u64 *paddr, u64 *size)
>> {
>> return -ENODEV;
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index c12dace043f3..bcd2b6fbeef3 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
>> return of_node_get(cpu_dev->of_node);
>> }
>>
>> -void of_dma_configure(struct device *dev, struct device_node *np);
>> +void of_dma_configure(struct device *dev, struct device_node *parent);
>> #else /* CONFIG_OF */
>>
>> static inline int of_driver_match_device(struct device *dev,
>> @@ -103,7 +103,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
>> {
>> return NULL;
>> }
>> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
>> +static inline void of_dma_configure(struct device *dev, struct device_node *parent)
>> {}
>> #endif /* CONFIG_OF */
>>
>> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
>> index 13394ac83c66..c02b62e8e6ed 100644
>> --- a/include/linux/of_iommu.h
>> +++ b/include/linux/of_iommu.h
>> @@ -12,7 +12,7 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
>> size_t *size);
>>
>> extern const struct iommu_ops *of_iommu_configure(struct device *dev,
>> - struct device_node *master_np);
>> + struct device_node *parent);
>>
>> #else
>>
>> @@ -24,7 +24,7 @@ static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
>> }
>>
>> static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>> - struct device_node *master_np)
>> + struct device_node *parent)
>> {
>> return NULL;
>> }
>> --
>> 2.11.0.dirty
>>
>
> pci and memory mapped device world is different. of course if you talk
> from iommu perspective, all the master are same for IOMMU
>
> but the original intention of the patch is to try to solve 2 problems.
> please refer to https://lkml.org/lkml/2017/3/29/10
>
> 1) expose generic API for pci world clients to configure their
> dma-ranges. right now there is none.
> 2) same API can be used by IOMMU to derive dma_mask.
>
> while the current patch posted to handle dma-ranges for both memory
> mapped and pci devices, which I think is overdoing.
>
> besides we have different configuration of dma-ranges based on iommu
> is enabled or not enabled.
> #define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
> 0x80000000 0x00 0x80000000 \
> 0x43000000 0x08 0x00000000 0x08
> 0x00000000 0x08 0x00000000 \
> 0x43000000 0x80 0x00000000 0x80
> 0x00000000 0x40 0x00000000>;
> Not sure if this patch will consider above dma-ranges.
>
> my suggestion is to leave existing of_dma_get_range as is, and have
> new function for pci world as discussed in
> please refer to https://lkml.org/lkml/2017/3/29/10
>
> Regards,
> Oza.
also I see that, in case of multiple ranges of_dma_get_range doesnt handle that.
and also it is not meant to handle.
so with this patch will return wrong size and hence wrong dma_mask.
having said, I think it is better to separate pci world dma-ranges
function on of_pci.c
for which my discussion with Rob already, (same thread)
https://lkml.org/lkml/2017/3/29/10
Waiting for Rob's viewpoint on this.
Regards,
Oza.
^ permalink raw reply
* Re: [PATCH v7 0/3] Broadcom FlexRM ring manager support
From: Jassi Brar @ 2017-03-29 5:35 UTC (permalink / raw)
To: Anup Patel
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, Devicetree List, Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
BCM Kernel Feedback
In-Reply-To: <1490765455-8556-1-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Mar 29, 2017 at 11:00 AM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> The Broadcom FlexRM ring manager provides producer-consumer style
> ring interface for offload engines on Broadcom iProc SoCs. We can
> have one or more instances of Broadcom FlexRM ring manager in a SoC.
>
> This patchset adds a mailbox driver for Broadcom FlexRM ring manager
> which can be used by offload engine drivers as mailbox clients.
>
> The Broadcom FlexRM mailbox driver is feature complete for RAID and
> Crypto offload engines. We will have incremental patches in-future
> for ring-level statistics using debugfs and minor optimizations.
>
> This patchset is based on Linux-4.11-rc4 and it is also available
> at flexrm-v7 branch of https://github.com/Broadcom/arm64-linux.git
>
> Changes since v6:
> - Rebased patches for Linux-4.11-rc4
> - Added a patch to remove depends on COMPILE_TEST for kconfig
> option BCM_FLEXRM_MBOX
>
You only needed to send the fix to compilation failure reports, not
the whole series.
I believe only the patch-3 is new in the series and I need not even
look at patch-1,2 ?
--
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
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