* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Sudeep Holla @ 2017-04-18 16:03 UTC (permalink / raw)
To: Viresh Kumar
Cc: Sudeep Holla, Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
Kevin Hilman, Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170417053303.GG28191@vireshk-i7>
On 17/04/17 06:33, Viresh Kumar wrote:
> On 13-04-17, 14:43, Sudeep Holla wrote:
>> Interesting. My understand of power domain and in particular power
>> domain performance was that it would control both. The abstract number
>> you introduce would hide clocks and regulators.
>>
>> But if the concept treats it just as yet another regulator, we do we
>> need these at all. Why don't we relate this performance to regulator
>> values and be done with it ?
>>
>> Sorry if I am missing to understand something here. I would look this as
>> replacement for both clocks and regulators, something similar to ACPI
>> CPPC. If not, it looks unnecessary to me with the information I have got
>> so far.
>
> I kind of answered that in the other email.
>
> Some background may be good here. So Qcom tried to solve all this with virtual
> regulators, but the problem was that they need to talk in terms of integer
> values (1, 2, 3..) and not voltages and so they can't use the regulator
> framework straight away. And so we are doing all this.
>
Was it posted externally ? Was there any objections for that approach ?
IMO that's better approach but if I am late to the party, I would like
to read through the discussions that happened on it(if any)
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Sudeep Holla @ 2017-04-18 16:01 UTC (permalink / raw)
To: Viresh Kumar
Cc: Sudeep Holla, Rafael Wysocki, ulf.hansson, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh+dt, lina.iyer,
rnayak, devicetree
In-Reply-To: <20170417052758.GF28191@vireshk-i7>
On 17/04/17 06:27, Viresh Kumar wrote:
> On 13-04-17, 14:42, Sudeep Holla wrote:
>> What I was referring is about power domain provider with multiple power
>> domains(simply #power-domain-cells=<1> case as explained in the
>> power-domain specification.
>
> I am not sure if we should be looking to target such a situation for now, as
> that would be like this:
>
> Device controlled by Domain A. Domain A itself is controlled by Domain B and
> Domain C.
>
No, may be I was not so clear. I am just referring a power controller
that provides say 3 different power domains and are indexed 0 - 2.
The consumer just passes the index along with the phandle for the power
domain info.
> Though we will end up converting the domain-performance-state property to an
> array if that is required in near future.
>
OK, better to document that so that we know how to extend it. We have
#power-domain-cells=<1> on Juno with SCPI.
>> Yes. To simplify what not we just have power-domain for a device and
>> change state of that domain to change the performance of that device.
>
> Consider this case to understand what I have in Mind.
>
> The power domain have its states as A, B, C, D. There can be multiple devices
> regulated by that domain and one of the devices have its power states as: A1,
> A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different
> frequency/voltages.
>
> IOW, the devices can have regulators as well and may want to fine tune within
> the domain performance-state.
>
Understood. I would incline towards reusing regulators we that's what is
changed behind the scene. Calling this operating performance point
is misleading and doesn't align well with existing specs/features.
>> Then put this in the hierarchy. Some thing similar to what we already
>> have with new domain-idle states. In that way, we can move any
>> performance control to the domain and abstract the clocks and regulators
>> from the devices as the first step and from the OSPM view if there's
>> firmware support.
>>
>> If we are looking this power-domains with performance as just some
>> *advanced regulators*, I don't like the complexity added.
>
> In the particular case I am trying to solve (Qcom), we have some sort of
> regulators which are only programmed by a M3 core. The M3 core needs integer
> numbers representing state we want the domain to be in and it will put the
> regulators (or whatever) in a particular state.
>
Understood. We have exactly same thing with SCPI but it controls both
frequency and voltage referred as operating points. In general, this OPP
terminology is used in SCPI/ACPI/SCMI specifications as both frequency
and voltage control. I am bit worried that this binding might introduce
confusions on the definitions. But it can be reworded/renamed easily if
required.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Mark Rutland @ 2017-04-18 15:43 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Herbert Xu, David S. Miller, Rob Herring, Greg Kroah-Hartman,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux kernel mailing list,
Gilad Ben-Yossef, Binoy Jayan, Ofir Drang
In-Reply-To: <CAOtvUMeB8ub-e6PXxgJWyK=TW4HseZgSN6NO=kSmVax514ufdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 18, 2017 at 06:29:22PM +0300, Gilad Ben-Yossef wrote:
> On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> >> accelerators. It is supported by a long lived series of out of tree
> >> drivers, which I am now in the process of unifying and upstreaming.
> >> This is the first drop, supporting the new CryptoCell 712 REE.
> >>
> >> The code still needs some cleanup before maturing to a proper
> >> upstream driver, which I am in the process of doing. However,
> >> as discussion of some of the capabilities of the hardware and
> >> its application to some dm-crypt and dm-verity features recently
> >> took place I though it is better to do this in the open via the
> >> staging tree.
> >>
> >> A Git repository based off of Linux 4.11-rc7 is available at
> >> https://github.com/gby/linux.git branch ccree.
> >>
> >> Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
> >> CC: Binoy Jayan <binoy.jayan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> CC: Ofir Drang <ofir.drang-5wv7dgnIgG8@public.gmane.org>
> >>
> >> Gilad Ben-Yossef (4):
> >> staging: add ccree crypto driver
> >> staging: ccree: add TODO list
> >> staging: ccree: add devicetree bindings
> >> MAINTAINERS: add Gilad BY as maintainer for ccree
> >>
> >> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
> >
> > I'm interested in looking at the DT binding, but for some reason I've
> > only recevied the cover letter so far.
> >
> > Are my mail servers being particularly slow today, or has something gone
> > wrong with the Cc list for the remaining patches?
> >
>
> Thanks a bunch for the willingness to review this.
>
> My apologies for not communicating this clearly enough - Since it is
> an pre-existing driver it is rather big.
> I did not want to inflict a 600K patch on the mailing list so opted to
> provide a git repo instead, as stated in the
> email.
Should this have been a [GIT PULL], then?
I was confused by the [PATCH 0/4].
> The patch in question is here:
> https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
>
> Do let me know if you prefer that I will send at least the smaller
> patch file via email in the normal fashion.
Sending patches is the usual way to have things reviewed. Linking to an
external site doesn't fit with the workflows of everyone.
If you wish to have patches reviewed, please send them as patches in the
usual fashion.
I will note that on the patch you linked, the compatible string is far
too vague, per common conventions. Per your description above, that
should be something like "arm,cryptocell-712-ree" (and each variant
should have its own string).
I don't have documentation to hand to attempt to review the rest.
I would appreciate if you could ensure that the DT binding was reviewed
as part of the staging TODOs. That needs to follow the usual DT review
process of sending patches to the list. Until that has occurred, it
shouldn't be in Documentation/devicetree/.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Greg Kroah-Hartman @ 2017-04-18 15:39 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Herbert Xu, David S. Miller, Rob Herring, Mark Rutland,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, gilad.benyossef-5wv7dgnIgG8,
Binoy Jayan, Ofir Drang
In-Reply-To: <1492524470-13847-1-git-send-email-gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
>
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
>
> A Git repository based off of Linux 4.11-rc7 is available at
> https://github.com/gby/linux.git branch ccree.
>
> Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
> CC: Binoy Jayan <binoy.jayan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> CC: Ofir Drang <ofir.drang-5wv7dgnIgG8@public.gmane.org>
>
> Gilad Ben-Yossef (4):
> staging: add ccree crypto driver
> staging: ccree: add TODO list
> staging: ccree: add devicetree bindings
> MAINTAINERS: add Gilad BY as maintainer for ccree
We can't do much without a real patch, sorry. Digging in random git
trees doesn't work :(
I can't take this as-is, I need patches.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Gilad Ben-Yossef @ 2017-04-18 15:29 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, Greg Kroah-Hartman,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux kernel mailing list,
Gilad Ben-Yossef, Binoy Jayan, Ofir Drang
In-Reply-To: <20170418151355.GI17866@leverpostej>
Hi Mark,
On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is available at
>> https://github.com/gby/linux.git branch ccree.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
>> CC: Binoy Jayan <binoy.jayan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> CC: Ofir Drang <ofir.drang-5wv7dgnIgG8@public.gmane.org>
>>
>> Gilad Ben-Yossef (4):
>> staging: add ccree crypto driver
>> staging: ccree: add TODO list
>> staging: ccree: add devicetree bindings
>> MAINTAINERS: add Gilad BY as maintainer for ccree
>>
>> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
>
> I'm interested in looking at the DT binding, but for some reason I've
> only recevied the cover letter so far.
>
> Are my mail servers being particularly slow today, or has something gone
> wrong with the Cc list for the remaining patches?
>
Thanks a bunch for the willingness to review this.
My apologies for not communicating this clearly enough - Since it is
an pre-existing driver it is rather big.
I did not want to inflict a 600K patch on the mailing list so opted to
provide a git repo instead, as stated in the
email.
The patch in question is here:
https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
Do let me know if you prefer that I will send at least the smaller
patch file via email in the normal fashion.
Many thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
--
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 5/8] coresight: use const for device_node structures
From: Mathieu Poirier @ 2017-04-18 15:24 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Suzuki K Poulose, Stephen Boyd, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, Mike Leach, Sudeep Holla
In-Reply-To: <1491485461-22800-6-git-send-email-leo.yan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote:
> Almost low level functions from open firmware have used const to
> qualify device_node structures, so add const for device_node
> parameters in of_coresight related functions.
>
> Reviewed-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Leo Yan <leo.yan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
I agree with these changes but the patch needs to be split up - please see
below.
> ---
> drivers/hwtracing/coresight/of_coresight.c | 6 +++---
> include/linux/coresight.h | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 78d2399..46eec0f 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -52,7 +52,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
> endpoint, of_dev_node_match);
> }
>
> -static void of_coresight_get_ports(struct device_node *node,
> +static void of_coresight_get_ports(const struct device_node *node,
> int *nr_inport, int *nr_outport)
Move this to a patch by itself as it is not related to this driver.
> {
> struct device_node *ep = NULL;
> @@ -101,7 +101,7 @@ static int of_coresight_alloc_memory(struct device *dev,
> return 0;
> }
>
> -int of_coresight_get_cpu(struct device_node *node)
> +int of_coresight_get_cpu(const struct device_node *node)
Move this to the previous patch in this set. There is not need to undo what you
just did there.
> {
> int cpu;
> bool found;
> @@ -128,7 +128,7 @@ int of_coresight_get_cpu(struct device_node *node)
> EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
>
> struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node)
> + struct device *dev, const struct device_node *node)
Same here, move this to a new patch (the same one as of_coresight_get_ports()).
> {
> int i = 0, ret = 0;
> struct coresight_platform_data *pdata;
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index bf96678..4915254 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -263,13 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
> #endif
>
> #ifdef CONFIG_OF
> -extern int of_coresight_get_cpu(struct device_node *node);
> +extern int of_coresight_get_cpu(const struct device_node *node);
> extern struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node);
> + struct device *dev, const struct device_node *node);
> #else
> -static inline int of_coresight_get_cpu(struct device_node *node) { return 0; }
> +static inline int of_coresight_get_cpu(const struct device_node *node) { return 0; }
> static inline struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node) { return NULL; }
> + struct device *dev, const struct device_node *node) { return NULL; }
> #endif
>
> #ifdef CONFIG_PID_NS
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: fix "/cpus" reference leak in of_numa_parse_cpu_nodes()
From: David Daney @ 2017-04-18 15:16 UTC (permalink / raw)
To: Tyrel Datwyler, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
david.daney-YGCgFSpz5w/QT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492475357-10784-1-git-send-email-tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 04/17/2017 05:29 PM, Tyrel Datwyler wrote:
> The call to of_find_node_by_path("/cpus") returns the cpus device_node
> with its reference count incremented. There is no matching of_node_put()
> call in of_numa_parse_cpu_nodes() which results in a leaked reference
> to the "/cpus" node.
>
> This patch adds an of_node_put() to release the reference.
Good catch:
Acked-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>
> fixes: 298535c00a2c ("of, numa: Add NUMA of binding implementation.")
> Signed-off-by: Tyrel Datwyler <tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> ---
> drivers/of/of_numa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
> index a53982a..2db1f7a 100644
> --- a/drivers/of/of_numa.c
> +++ b/drivers/of/of_numa.c
> @@ -57,6 +57,8 @@ static void __init of_numa_parse_cpu_nodes(void)
> else
> node_set(nid, numa_nodes_parsed);
> }
> +
> + of_node_put(cpus);
> }
>
> static int __init of_numa_parse_memory_nodes(void)
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Mark Rutland @ 2017-04-18 15:13 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Herbert Xu, David S. Miller, Rob Herring, Greg Kroah-Hartman,
devel, linux-crypto, devicetree, linux-kernel, gilad.benyossef,
Binoy Jayan, Ofir Drang
In-Reply-To: <1492524470-13847-1-git-send-email-gilad@benyossef.com>
Hi,
On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
>
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
>
> A Git repository based off of Linux 4.11-rc7 is available at
> https://github.com/gby/linux.git branch ccree.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> CC: Binoy Jayan <binoy.jayan@linaro.org>
> CC: Ofir Drang <ofir.drang@arm.com>
>
> Gilad Ben-Yossef (4):
> staging: add ccree crypto driver
> staging: ccree: add TODO list
> staging: ccree: add devicetree bindings
> MAINTAINERS: add Gilad BY as maintainer for ccree
>
> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
I'm interested in looking at the DT binding, but for some reason I've
only recevied the cover letter so far.
Are my mail servers being particularly slow today, or has something gone
wrong with the Cc list for the remaining patches?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v6 3/8] coresight: of_get_coresight_platform_data: Add missing of_node_put
From: Mathieu Poirier @ 2017-04-18 15:09 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Suzuki K Poulose, Stephen Boyd, linux-doc, linux-kernel,
devicetree, linux-arm-kernel, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <1491485461-22800-4-git-send-email-leo.yan@linaro.org>
On Thu, Apr 06, 2017 at 09:30:56PM +0800, Leo Yan wrote:
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> The of_get_coresight_platform_data iterates over the possible CPU nodes
> to find a given cpu phandle. However it does not drop the reference
> to the node pointer returned by the of_get_coresight_platform_data.
>
> This patch also introduces another minor fix is to use
> of_cpu_device_node_get() to replace of_get_cpu_node().
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> [Leo: minor tweaks for of_get_coresight_platform_data]
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Suzuki sent a Reviewed-by for this, it should be added here.
> ---
> drivers/hwtracing/coresight/of_coresight.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 629e031..1a77280 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -108,7 +108,8 @@ struct coresight_platform_data *of_get_coresight_platform_data(
> struct coresight_platform_data *pdata;
> struct of_endpoint endpoint, rendpoint;
> struct device *rdev;
> - struct device_node *dn;
> + bool found;
> + struct device_node *dn, *np;
> struct device_node *ep = NULL;
> struct device_node *rparent = NULL;
> struct device_node *rport = NULL;
> @@ -175,17 +176,19 @@ struct coresight_platform_data *of_get_coresight_platform_data(
> } while (ep);
> }
>
> - /* Affinity defaults to CPU0 */
> - pdata->cpu = 0;
> dn = of_parse_phandle(node, "cpu", 0);
> - for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
> - if (dn == of_get_cpu_node(cpu, NULL)) {
> - pdata->cpu = cpu;
> + for_each_possible_cpu(cpu) {
> + np = of_cpu_device_node_get(cpu);
> + found = (dn == np);
> + of_node_put(np);
> + if (found)
> break;
> - }
> }
> of_node_put(dn);
>
> + /* Affinity to CPU0 if no cpu nodes are found */
> + pdata->cpu = found ? cpu : 0;
> +
> return pdata;
> }
> EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Wadim Egorov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Jacob Chen
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Heiko Stuebner, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFLEztSQ1-WU7KAXzuB66htXiaQN4wd=XmM5XtjZcoONt77XmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> +&i2c0 {
>> + status = "okay";
>> + clock-frequency = <400000>;
>> +
>> + rk818: pmic@1c {
>> + compatible = "rockchip,rk818";
>> + reg = <0x1c>;
>> + interrupt-parent = <&gpio0>;
>> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pmic_int>;
>> + rockchip,system-power-controller;
>> + wakeup-source;
>> + #clock-cells = <1>;
>> +
> I think you miss "clock-output-names = "xin32k" here.
Yes, thanks for catching that. I will fix this later.
--
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 v2 7/7] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Enable PCIe peripheral on this board.
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7d-sdb.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index d6f2dda..65dda66 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -349,6 +349,12 @@
};
};
+&pcie {
+ pinctrl-names = "default";
+ reset-gpio = <&extended_io 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: imx7d: Add node for PCIe controller
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky-Re5JQEeQqe8AvxtiuMwx3w, Dong Aisheng,
Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170418150133.31679-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: Dong Aisheng <aisheng.dong-3arQi8VN3Tc@public.gmane.org>
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/imx7d.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index f6dee41..f46814a 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -42,6 +42,7 @@
*/
#include "imx7s.dtsi"
+#include <dt-bindings/reset/imx7-reset.h>
/ {
cpus {
@@ -127,6 +128,42 @@
fsl,num-rx-queues=<3>;
status = "disabled";
};
+
+ pcie: pcie@0x33800000 {
+ compatible = "fsl,imx7d-pcie", "snps,dw-pcie";
+ reg = <0x33800000 0x4000>,
+ <0x4ff00000 0x80000>;
+ reg-names = "dbi", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x4ff80000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x40000000 0x40000000 0 0x0ff00000>; /* non-prefetchable memory */
+ num-lanes = <1>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_PCIE_CTRL_ROOT_CLK>,
+ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>,
+ <&clks IMX7D_PCIE_PHY_ROOT_CLK>;
+ clock-names = "pcie", "pcie_bus", "pcie_phy";
+ assigned-clocks = <&clks IMX7D_PCIE_CTRL_ROOT_SRC>,
+ <&clks IMX7D_PCIE_PHY_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>,
+ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
+
+ fsl,max-link-speed = <2>;
+ power-domains = <&pgc_pcie_phy>;
+ resets = <&src IMX7_RESET_PCIEPHY>,
+ <&src IMX7_RESET_PCIE_CTRL_APPS_EN>;
+ reset-names = "pciephy", "apps";
+ status = "disabled";
+ };
};
&ca_funnel_ports {
--
2.9.3
--
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 v2 5/7] ARM: dts: imx7d-sdb: Add GPIO expander node
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, Mark Rutland, devicetree, Andrey Smirnov,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel, yurovsky
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Add node for U38, a 74LV595PW serial-in shift register that acts as a
GPIO expander on the board.
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7d-sdb.dts | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 5be01a1..d6f2dda 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -52,6 +52,27 @@
reg = <0x80000000 0x80000000>;
};
+ spi4 {
+ compatible = "spi-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi4>;
+ gpio-sck = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ gpio-mosi = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ extended_io: gpio-expander@0 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ registers-number = <1>;
+ spi-max-frequency = <100000>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -642,5 +663,13 @@
fsl,pins = <
MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x110b0
>;
+
+ pinctrl_spi4: spi4grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x59
+ MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
+ MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
+ >;
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/7] ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
List GPR block as compatible "fsl,imx6q-iomuxc-gpr" to support drivers
requesting it that way (PCIe driver is one example).
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7s.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 5ba1289..d46ee0f 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -491,7 +491,8 @@
};
gpr: iomuxc-gpr@30340000 {
- compatible = "fsl,imx7d-iomuxc-gpr", "syscon";
+ compatible = "fsl,imx7d-iomuxc-gpr",
+ "fsl,imx6q-iomuxc-gpr", "syscon";
reg = <0x30340000 0x10000>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/7] ARM: dts: imx7s: Add node for GPC
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Add node for GPC and specify as a parent interrupt controller for SoC bus.
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7s.dtsi | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 7148eac..5ba1289 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -42,6 +42,7 @@
*/
#include <dt-bindings/clock/imx7d-clock.h>
+#include <dt-bindings/power/imx7-power.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -119,7 +120,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- interrupt-parent = <&intc>;
+ interrupt-parent = <&gpc>;
ranges;
funnel@30041000 {
@@ -301,6 +302,7 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
#interrupt-cells = <3>;
interrupt-controller;
+ interrupt-parent = <&intc>;
reg = <0x31001000 0x1000>,
<0x31002000 0x2000>,
<0x31004000 0x2000>,
@@ -309,6 +311,7 @@
timer {
compatible = "arm,armv7-timer";
+ interrupt-parent = <&intc>;
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)>,
@@ -565,6 +568,27 @@
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
#reset-cells = <1>;
};
+
+ gpc: gpc@303a0000 {
+ compatible = "fsl,imx7d-gpc";
+ reg = <0x303a0000 0x10000>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&intc>;
+ #power-domain-cells = <1>;
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pgc_pcie_phy: pgc-power-domain@IMX7_POWER_DOMAIN_PCIE_PHY {
+ #power-domain-cells = <0>;
+ reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
+ power-supply = <®_1p0d>;
+ };
+ };
+ };
};
aips2: aips-bus@30400000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/7] ARM: imx: Select GPCv2 for i.MX7
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
GPCv2 IP block is a part of i.MX7 SoC. Select it to make corresponding
driver availible to support DT changes following this patch.
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/mach-imx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 936c59d..1a4ea3a 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -532,6 +532,7 @@ config SOC_IMX7D
bool "i.MX7 Dual support"
select PINCTRL_IMX7D
select ARM_GIC
+ select IMX_GPCV2
select HAVE_ARM_ARCH_TIMER
select HAVE_IMX_ANATOP
select HAVE_IMX_MMDC
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/7] ARM: dts: i.MX: Reintroduce 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Now that support for 'anatop-enable-bit' has been added to ANADIG
driver, reintroduce 'anatop-enable-bit' for all applicable LDOs.
Cc: yurovsky@gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
5 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..ec398ea 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -643,6 +643,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -657,6 +658,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -671,6 +673,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index cc9572e..3243af4 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -530,6 +530,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -544,6 +545,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -558,6 +560,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2850000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index dd4ec85..97199ee 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -586,6 +586,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -600,6 +601,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -614,6 +616,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index b9d7d2d..6da2b77 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -542,6 +542,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 5d3a43b..7148eac 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -517,6 +517,7 @@
anatop-min-bit-val = <8>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1200000>;
+ anatop-enable-bit = <0>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/7] i.MX7 PCIe related device tree changes
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, Mark Rutland, devicetree, Andrey Smirnov,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel, yurovsky
Shawn, everyone:
This is second version of the series that includes changes made to
device-tree in order to support PCIe on i.MX7 platform.
Changes since [v1]:
- All 'anatop-enable-bit' patches are squashed into one
- Added patch to enable GPCv2 driver on i.MX7
- Dropped accidentally introduced unsupported DT properties
- A number of node renaming for readability/clarity purpose
[v1] http://lkml.kernel.org/r/20170413133242.5068-1-andrew.smirnov@gmail.com
Andrey Smirnov (7):
ARM: dts: i.MX: Reintroduce 'anatop-enable-bit' where appropriate
ARM: imx: Select GPCv2 for i.MX7
ARM: dts: imx7s: Add node for GPC
ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
ARM: dts: imx7d-sdb: Add GPIO expander node
ARM: dts: imx7d: Add node for PCIe controller
ARM: dts: imx7d-sdb: Enable PCIe peripheral
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7d-sdb.dts | 35 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7d.dtsi | 37 +++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7s.dtsi | 30 ++++++++++++++++++++++++++++--
arch/arm/mach-imx/Kconfig | 1 +
8 files changed, 111 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 0/4] staging: add ccree crypto driver
From: Gilad Ben-Yossef @ 2017-04-18 14:07 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Mark Rutland,
Greg Kroah-Hartman, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b
Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, gilad.benyossef-5wv7dgnIgG8,
Binoy Jayan, Ofir Drang
Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
accelerators. It is supported by a long lived series of out of tree
drivers, which I am now in the process of unifying and upstreaming.
This is the first drop, supporting the new CryptoCell 712 REE.
The code still needs some cleanup before maturing to a proper
upstream driver, which I am in the process of doing. However,
as discussion of some of the capabilities of the hardware and
its application to some dm-crypt and dm-verity features recently
took place I though it is better to do this in the open via the
staging tree.
A Git repository based off of Linux 4.11-rc7 is available at
https://github.com/gby/linux.git branch ccree.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
CC: Binoy Jayan <binoy.jayan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Ofir Drang <ofir.drang-5wv7dgnIgG8@public.gmane.org>
Gilad Ben-Yossef (4):
staging: add ccree crypto driver
staging: ccree: add TODO list
staging: ccree: add devicetree bindings
MAINTAINERS: add Gilad BY as maintainer for ccree
.../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
MAINTAINERS | 8 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 2 +-
drivers/staging/ccree/Kconfig | 52 +
drivers/staging/ccree/Makefile | 3 +
drivers/staging/ccree/TODO | 27 +
drivers/staging/ccree/bsp.h | 21 +
drivers/staging/ccree/cc_bitops.h | 62 +
drivers/staging/ccree/cc_crypto_ctx.h | 299 +++
drivers/staging/ccree/cc_hal.h | 35 +
drivers/staging/ccree/cc_hw_queue_defs.h | 603 +++++
drivers/staging/ccree/cc_lli_defs.h | 57 +
drivers/staging/ccree/cc_pal_log.h | 188 ++
drivers/staging/ccree/cc_pal_log_plat.h | 33 +
drivers/staging/ccree/cc_pal_types.h | 97 +
drivers/staging/ccree/cc_pal_types_plat.h | 29 +
drivers/staging/ccree/cc_regs.h | 106 +
drivers/staging/ccree/dx_crys_kernel.h | 180 ++
drivers/staging/ccree/dx_env.h | 224 ++
drivers/staging/ccree/dx_host.h | 155 ++
drivers/staging/ccree/dx_reg_base_host.h | 34 +
drivers/staging/ccree/dx_reg_common.h | 26 +
drivers/staging/ccree/hash_defs.h | 78 +
drivers/staging/ccree/hw_queue_defs_plat.h | 43 +
drivers/staging/ccree/ssi_aead.c | 2832 ++++++++++++++++++++
drivers/staging/ccree/ssi_aead.h | 120 +
drivers/staging/ccree/ssi_buffer_mgr.c | 1876 +++++++++++++
drivers/staging/ccree/ssi_buffer_mgr.h | 105 +
drivers/staging/ccree/ssi_cipher.c | 1503 +++++++++++
drivers/staging/ccree/ssi_cipher.h | 89 +
drivers/staging/ccree/ssi_config.h | 61 +
drivers/staging/ccree/ssi_driver.c | 557 ++++
drivers/staging/ccree/ssi_driver.h | 228 ++
drivers/staging/ccree/ssi_fips.c | 65 +
drivers/staging/ccree/ssi_fips.h | 70 +
drivers/staging/ccree/ssi_fips_data.h | 315 +++
drivers/staging/ccree/ssi_fips_ext.c | 96 +
drivers/staging/ccree/ssi_fips_ll.c | 1681 ++++++++++++
drivers/staging/ccree/ssi_fips_local.c | 369 +++
drivers/staging/ccree/ssi_fips_local.h | 77 +
drivers/staging/ccree/ssi_hash.c | 2751 +++++++++++++++++++
drivers/staging/ccree/ssi_hash.h | 101 +
drivers/staging/ccree/ssi_ivgen.c | 301 +++
drivers/staging/ccree/ssi_ivgen.h | 72 +
drivers/staging/ccree/ssi_pm.c | 150 ++
drivers/staging/ccree/ssi_pm.h | 46 +
drivers/staging/ccree/ssi_pm_ext.c | 60 +
drivers/staging/ccree/ssi_pm_ext.h | 33 +
drivers/staging/ccree/ssi_request_mgr.c | 713 +++++
drivers/staging/ccree/ssi_request_mgr.h | 60 +
drivers/staging/ccree/ssi_sram_mgr.c | 138 +
drivers/staging/ccree/ssi_sram_mgr.h | 80 +
drivers/staging/ccree/ssi_sysfs.c | 440 +++
drivers/staging/ccree/ssi_sysfs.h | 54 +
55 files changed, 17429 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
create mode 100644 drivers/staging/ccree/Kconfig
create mode 100644 drivers/staging/ccree/Makefile
create mode 100644 drivers/staging/ccree/TODO
create mode 100644 drivers/staging/ccree/bsp.h
create mode 100644 drivers/staging/ccree/cc_bitops.h
create mode 100644 drivers/staging/ccree/cc_crypto_ctx.h
create mode 100644 drivers/staging/ccree/cc_hal.h
create mode 100644 drivers/staging/ccree/cc_hw_queue_defs.h
create mode 100644 drivers/staging/ccree/cc_lli_defs.h
create mode 100644 drivers/staging/ccree/cc_pal_log.h
create mode 100644 drivers/staging/ccree/cc_pal_log_plat.h
create mode 100644 drivers/staging/ccree/cc_pal_types.h
create mode 100644 drivers/staging/ccree/cc_pal_types_plat.h
create mode 100644 drivers/staging/ccree/cc_regs.h
create mode 100644 drivers/staging/ccree/dx_crys_kernel.h
create mode 100644 drivers/staging/ccree/dx_env.h
create mode 100644 drivers/staging/ccree/dx_host.h
create mode 100644 drivers/staging/ccree/dx_reg_base_host.h
create mode 100644 drivers/staging/ccree/dx_reg_common.h
create mode 100644 drivers/staging/ccree/hash_defs.h
create mode 100644 drivers/staging/ccree/hw_queue_defs_plat.h
create mode 100644 drivers/staging/ccree/ssi_aead.c
create mode 100644 drivers/staging/ccree/ssi_aead.h
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h
create mode 100644 drivers/staging/ccree/ssi_cipher.c
create mode 100644 drivers/staging/ccree/ssi_cipher.h
create mode 100644 drivers/staging/ccree/ssi_config.h
create mode 100644 drivers/staging/ccree/ssi_driver.c
create mode 100644 drivers/staging/ccree/ssi_driver.h
create mode 100644 drivers/staging/ccree/ssi_fips.c
create mode 100644 drivers/staging/ccree/ssi_fips.h
create mode 100644 drivers/staging/ccree/ssi_fips_data.h
create mode 100644 drivers/staging/ccree/ssi_fips_ext.c
create mode 100644 drivers/staging/ccree/ssi_fips_ll.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.h
create mode 100644 drivers/staging/ccree/ssi_hash.c
create mode 100644 drivers/staging/ccree/ssi_hash.h
create mode 100644 drivers/staging/ccree/ssi_ivgen.c
create mode 100644 drivers/staging/ccree/ssi_ivgen.h
create mode 100644 drivers/staging/ccree/ssi_pm.c
create mode 100644 drivers/staging/ccree/ssi_pm.h
create mode 100644 drivers/staging/ccree/ssi_pm_ext.c
create mode 100644 drivers/staging/ccree/ssi_pm_ext.h
create mode 100644 drivers/staging/ccree/ssi_request_mgr.c
create mode 100644 drivers/staging/ccree/ssi_request_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.c
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sysfs.c
create mode 100644 drivers/staging/ccree/ssi_sysfs.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-18 14:04 UTC (permalink / raw)
To: Viresh Kumar
Cc: Masahiro Yamada, Rob Herring, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Benoît Cousson, Tony Lindgren, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai
In-Reply-To: <20170418051526.GN28191@vireshk-i7>
On Tuesday, April 18, 2017 10:45:26 AM Viresh Kumar wrote:
> On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
> > > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> > > > >> Compiling the DT file with W=1, DTC warns like follows:
> > > > >>
> > > > >> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > > > >> unit name, but no reg property
> > > > >>
> > > > >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > > > >> "reg" property.
> > > > >>
> > > > >> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > > >> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > > >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > > >> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> > > > >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > > > >> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >
> > > > > OK, so any ACKs from the DT side? Rob?
> > > > >
> > > > > Thanks,
> > > > > Rafael
> > > >
> > > >
> > > >
> > > > I see Rob's Acked-by.
> > > >
> > > > https://lkml.org/lkml/2017/4/13/648
> > >
> > > Indeed. Thanks!
> >
> > But it doesn't apply on top of -rc7 for me, so I guess there is new 4.12-candidate
> > material in the DTS tree that conflicts with this, in which case it is better to route
> > it through the DTS tree IMO.
>
> Yes a minor conflict. I have sent the rebased version now, see if you
> want to apply it directly or want arm-soc guys to do it.
I'm going to apply the rebased one.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] fpga: region: add missing DT documentation for config complete timeout
From: Tobias Klauser @ 2017-04-18 13:40 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer
Cc: Rob Herring, Mark Rutland, linux-fpga-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Commit 42d5ec954719 ("fpga: add config complete timeout") introduced the
config complete property but didn't include the corresponding DT binding
documentation. Add it now.
Signed-off-by: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
---
Documentation/devicetree/bindings/fpga/fpga-region.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index 81bf3adba24b..6db8aeda461a 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -193,6 +193,8 @@ Optional properties:
- region-freeze-timeout-us : The maximum time in microseconds to wait for
bridges to successfully become disabled before the region has been
programmed.
+- config-complete-timeout-us : The maximum time in microseconds time for the
+ FPGA to go to operating mode after the region has been programmed.
- child nodes : devices in the FPGA after programming.
In the example below, when an overlay is applied targeting fpga-region0,
--
2.12.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 related
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-18 13:36 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492509996.2432.63.camel@pengutronix.de>
On 2017-04-18 12:06, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>> Allow specifying that a single multiplexer controller can be used to
>> control several parallel multiplexers, thus enabling sharing of the
>> multiplexer controller by different consumers.
>>
>> Add a binding for a first mux controller in the form of a GPIO based mux
>> controller.
>>
>> Acked-by: Jonathan Cameron <jic23@kernel.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 +++++++++
>> .../devicetree/bindings/mux/mux-controller.txt | 157 +++++++++++++++++++++
>> MAINTAINERS | 6 +
>> include/dt-bindings/mux/mux.h | 16 +++
>> 4 files changed, 248 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt
>> create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
>> create mode 100644 include/dt-bindings/mux/mux.h
>>
>> diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt
>> new file mode 100644
>> index 000000000000..b8f746344d80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt
>> @@ -0,0 +1,69 @@
>> +GPIO-based multiplexer controller bindings
>> +
>> +Define what GPIO pins are used to control a multiplexer. Or several
>> +multiplexers, if the same pins control more than one multiplexer.
>> +
>> +Required properties:
>> +- compatible : "gpio-mux"
>> +- mux-gpios : list of gpios used to control the multiplexer, least
>> + significant bit first.
>> +- #mux-control-cells : <0>
>> +* Standard mux-controller bindings as decribed in mux-controller.txt
>> +
>> +Optional properties:
>> +- idle-state : if present, the state the mux will have when idle. The
>> + special state MUX_IDLE_AS_IS is the default.
>> +
>> +The multiplexer state is defined as the number represented by the
>> +multiplexer GPIO pins, where the first pin is the least significant
>> +bit. An active pin is a binary 1, an inactive pin is a binary 0.
>> +
>> +Example:
>> +
>> + mux: mux-controller {
>> + compatible = "gpio-mux";
>> + #mux-control-cells = <0>;
>> +
>> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
>> + <&pioA 1 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + adc-mux {
>> + compatible = "io-channel-mux";
>> + io-channels = <&adc 0>;
>> + io-channel-names = "parent";
>> +
>> + mux-controls = <&mux>;
>> +
>> + channels = "sync-1", "in", "out", "sync-2";
>> + };
>
> Could you explain in more detail the reasoning behind this split between
> the mux controller and the actual mux?
> For SoC internal video bus muxes that are controlled by a register
> bitfield, it seems a bit strange to have to split them into two device
> tree nodes.
The background for the split is in the cover letter.
Basically, when the same set of gpio lines control several muxes, and
when these muxes are used for unrelated things, you needs some extra
complexity.
The mux controller is what controls those gpio lines, and thus the mux
state for all muxes they are connected to. The consumers refer to the
mux controller and request a certain state. So, the consumers naturally
need to interact or else they would destroy the mux state for each other.
Regarding the device tree layout, perhaps the mux consumers could be
children of the mux controller, but I think that would make the mux
controller more like a bus instead of a class. Anyway, I don't want to
go there again, because I remember it as a messy place. Maybe I could
do better now than I did way back when, but I'm not going willingly
and someone would have to force me.
The benefit of the split is that the mux consumer need no longer concern
itself with if the mux is controlled by gpio lines, an I2C based chip
like the ADG792 or if it is controlled by some mmio register. You can
thus avoid building muxing sub-sub-systems like drivers/i2c/muxes for
every subsystem needing muxing.
The drawback is that you get an extra device tree node for the mux
controller that may not make sense if it is in no way possible to
reuse your driver for HW with a different mux. Which may be the case
for your video case? But for generic stuff like ADC lines and I2C
buses, muxing options are diverse...
> Basically I'm trying to figure out whether a video mux (which has a mux
> control plus OF-graph bindings to describe its ports and connections)
> would fit into the same category as an adc-mux or i2c-mux, or whether it
> would be better to handle them as a specialized form of mux-controller.
I did read some earlier thread about your muxing requirements and I got
the impression that you also had HW which controlled the mux with
gpio lines? In that case, the mux subsystem seems like a perfect fit
with a new syscon/mmio/reg based mux driver (or whatever the name should
be, I think I'd go with syscon) pretty much as suggested in your RFC
patches. And then of course reuse the existing gpio-mux driver for the
other case.
The video-mux would fit as a mux consumer just like the iio-mux and the
i2c-mux are mux consumers, with input 0/input 1 being the port that
would be selected with the mux I guess. I don't think there should be a
bunch of video code inside the drivers/mux subdir, for the same reason
there's no iio/i2c code in there.
If I got things wrong when I skimmed whatever I came across, and if the
mmio register is the only mux control option in the stars, it becomes
less obvious... It's of course still possible to hook into the mux
subsystem, but the benefit is questionable. And you do get the extra
device tree node. You could of course also implement a mux driver
outside of drivers/mux and thus make use of the mux api, but it's tiny
and any benefit is truly small.
Cheers,
peda
^ permalink raw reply
* Re: [PATCH] of: Add vendor prefix for ROHM Semiconductor
From: Geert Uytterhoeven @ 2017-04-18 13:35 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree@vger.kernel.org, Linux-Renesas, Marek Vasut,
Rob Herring, Geert Uytterhoeven
In-Reply-To: <20170416180111.16795-1-marek.vasut+renesas@gmail.com>
On Sun, Apr 16, 2017 at 8:01 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> ROHM Semiconductor Co., Ltd. offer PMICs, touchscreen controllers etc.
> http://www.rohm.com/web/global/
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk
From: Guenter Roeck @ 2017-04-18 13:18 UTC (permalink / raw)
To: William Wu
Cc: Felipe Balbi, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
Heiko Stübner, linux-kernel,
linux-usb-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Frank Wang,
Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw, wulf
In-Reply-To: <1492492659-19266-1-git-send-email-william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Apr 17, 2017 at 10:17 PM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> This patch adds a quirk to disable USB 2.0 MAC linestate check
> during HS transmit. Refer the dwc3 databook, we can use it for
> some special platforms if the linestate not reflect the expected
> line state(J) during transmission.
>
> When use this quirk, the controller implements a fixed 40-bit
> TxEndDelay after the packet is given on UTMI and ignores the
> linestate during the transmit of a token (during token-to-token
> and token-to-data IPGAP).
>
> On some rockchip platforms (e.g. rk3399), it requires to disable
> the u2mac linestate check to decrease the SSPLIT token to SETUP
> token inter-packet delay from 566ns to 466ns, and fix the issue
> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> Changes in v2:
> - fix coding style
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
> drivers/usb/dwc3/core.c | 14 ++++++++++----
> drivers/usb/dwc3/core.h | 4 ++++
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index f658f39..6a89f0c 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -45,6 +45,8 @@ Optional properties:
> a free-running PHY clock.
> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
> from P0 to P1/P2/P3 without delay.
> + - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
> + during HS transmit.
All other disable-something quirks are named
"snps,dis-something-quirk". Maybe use the same naming convention ?
> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
> utmi_l1_suspend_n, false when asserts utmi_sleep_n
> - snps,hird-threshold: HIRD threshold
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 455d89a..03429c5 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
> }
>
> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> +
My understanding is that the register was only introduced with dwc3
revision 2.50a. Is it ok to read and write it unconditionally ?
> /*
> * Enable hardware control of sending remote wakeup in HS when
> * the device is in the L1 state.
> */
> - if (dwc->revision >= DWC3_REVISION_290A) {
> - reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> + if (dwc->revision >= DWC3_REVISION_290A)
> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> - dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> - }
> +
> + if (dwc->tx_ipgap_linecheck_dis_quirk)
> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> +
> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>
> return 0;
>
> @@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> "snps,dis-u2-freeclk-exists-quirk");
> dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
> "snps,dis-del-phy-power-chg-quirk");
> + dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
> + "snps,tx-ipgap-linecheck-dis-quirk");
>
> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
> "snps,tx_de_emphasis_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 981c77f..3c2537b 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -204,6 +204,7 @@
> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>
> /* Global User Control 1 Register */
> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>
> /* Global USB2 PHY Configuration Register */
> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
> * provide a free-running PHY clock.
> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
> * change quirk.
> + * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
> + * check during HS transmit.
> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
> * @tx_de_emphasis: Tx de-emphasis value
> * 0 - -6dB de-emphasis
> @@ -1004,6 +1007,7 @@ struct dwc3 {
> unsigned dis_rxdet_inp3_quirk:1;
> unsigned dis_u2_freeclk_exists_quirk:1;
> unsigned dis_del_phy_power_chg_quirk:1;
> + unsigned tx_ipgap_linecheck_dis_quirk:1;
>
> unsigned tx_de_emphasis_quirk:1;
> unsigned tx_de_emphasis:2;
> --
> 2.0.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
* [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-18 12:39 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, David S. Miller, Joao Pinto,
Niklas Cassel, Alexandre TORGUE, Giuseppe CAVALLARO,
Thierry Reding, Eric Engestrom
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.
At the same time, improve the description of the existing interrupts.
Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
---
Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..c3a7be6615c5 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -7,9 +7,12 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupts: Should contain the STMMAC interrupts
-- interrupt-names: Should contain the interrupt names "macirq"
- "eth_wake_irq" if this interrupt is supported in the "interrupts"
- property
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Valid interrupt names are:
+ - "macirq" (combined signal for various interrupt events)
+ - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection)
+ - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
- phy-mode: See ethernet.txt file in the same directory.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +155,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe0800000 0x8000>;
interrupt-parent = <&vic1>;
- interrupts = <24 23>;
- interrupt-names = "macirq", "eth_wake_irq";
+ interrupts = <24 23 22>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = [000000000000]; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";
--
2.11.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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox