Re: [PATCH 02/10] mm/numa: automatically generate node migration order
On Thu, Apr 15, 2021 at 8:35 AM Dave Hansen wrote: > > This can help enable more flexible demotion policies to be > > configured, such as to allow a cgroup to allocate from all fast tier > > nodes, but only demote to a local slow tier node. Such a policy can > > reduce memory stranding at the fast tier (compared to if memory > > hardwall is used) and still allow demotion from all fast tier nodes > > without incurring the expensive random accesses to the demoted pages > > if they were demoted to remote slow tier nodes. > > Could you explain this stranding effect in a bit more detail? I'm not > quite following. By memory stranding, I mean that memory on a machine (or a NUMA node) cannot be utilized even under extremely high work loads. Memory stranding happens usually due to mismatches between job/machine shapes as well as resource fragmentation resulted from bin-packing scheduling. It is an important problem for cloud resource efficiency. If NUMA hardwalling is used, we effectively split a single machine into multiple smaller machines based on NUMA nodes. This changes the machine shapes and also makes memory more fragmented, which can lead to more memory being stranded. Here is a simple example: Suppose that each machine has 2 NUMA nodes, each with 4 cores and 5GB RAM, and all the jobs have the shape of 2 CPUs and 3GB memory. Without NUMA memory hardwalling, we can pack 3 jobs onto each machine, which leaves 1GB memory and 2 cores in stranding. However, with NUMA memory hardwalling enabled, we can then only pack 2 jobs onto each machine (one job on each NUMA node), which increases the resource stranding to 4GB memory and 4 cores.
Re: [PATCH 02/10] mm/numa: automatically generate node migration order
On Wed, Apr 14, 2021 at 1:08 AM Oscar Salvador wrote: > > Hi Wei Xu, > > I have some questions about it > > Fast class/memory are pictured as those nodes with CPUs, while Slow > class/memory > are PMEM, right? > Then, what stands for medium class/memory? That is Dave's example. I think David's guess makes sense (HBM - fast, DRAM - medium, PMEM - slow). It may also be possible that we have DDR5 as fast, CXL-DDR4 as medium, and CXL-PMEM as slow. But the most likely use cases for now should be just two tiers: DRAM vs PMEM or other types of slower memory devices. > In Dave's example, list is created in a way that stays local to the socket, > and we go from the fast one to the slow one. > In yours, lists are created taking the fastest nodes from all sockets and > we work our way down, which means have cross-socket nodes in the list. > How much of a penalty is that? Cross-socket demotion is certainly more expensive. But because it is sequential access and can also be optimized with non-temporal stores, it may not be much slower than demotion to a local node in the next tier. The actual penalty will depend on the devices. > And while I get your point, I am not sure if that is what we pretend here. > This patchset aims to place cold pages that are about to be reclaim in slower > nodes to give them a second chance, while your design seems more to have kind > of different memory clases and be able to place applications in one of those > tiers > depending on its demands or sysadmin-demand. > > Could you expand some more? Sure. What I have described has the same goal as Dave's patchset, i,e, to demote cold pages to the slower nodes when they are about to be reclaimed. The only difference is that in my suggestion the demotion target of a fast tier node is expanded from a single node to a set of nodes from the slow tier and one node in such a set can be marked as the preferred/local demotion target. This can help enable more flexible demotion policies to be configured, such as to allow a cgroup to allocate from all fast tier nodes, but only demote to a local slow tier node. Such a policy can reduce memory stranding at the fast tier (compared to if memory hardwall is used) and still allow demotion from all fast tier nodes without incurring the expensive random accesses to the demoted pages if they were demoted to remote slow tier nodes. I understand that Dave started this patchset with a simplified demotion path definition, which I agree. Meanwhile, I think this more generalized definition of demotion path is useful and can also be important for some use cases.
Re: [PATCH 10/10] mm/migrate: new zone_reclaim_mode to enable reclaim migration
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote: > This proposes extending the existing "zone_reclaim_mode" (now > now really node_reclaim_mode) as a method to enable it. Nit: now now -> now > We are open to any alternative that allows end users to enable > this mechanism or disable it it workload harm is detected (just > like traditional autonuma). Nit: it it -> it if > diff -puN mm/vmscan.c~RECLAIM_MIGRATE mm/vmscan.c > --- a/mm/vmscan.c~RECLAIM_MIGRATE 2021-03-31 15:17:40.339000190 -0700 > +++ b/mm/vmscan.c 2021-03-31 15:17:40.357000190 -0700 > @@ -1074,6 +1074,9 @@ static bool migrate_demote_page_ok(struc > VM_BUG_ON_PAGE(PageHuge(page), page); > VM_BUG_ON_PAGE(PageLRU(page), page); > > + if (!(node_reclaim_mode & RECLAIM_MIGRATE)) > + return false; > + As I commented on an earlier patch in this series, the RECLAIM_MIGRATE check needs to be added to other new callers of next_demotion_node() as well to avoid unnecessarily splitting THP pages when neither swap nor RECLAIM_MIGRATE is enabled. It can be too late to check RECLAIM_MIGRATE only in migrate_demote_page_ok().
Re: [PATCH 06/10] mm/vmscan: add page demotion counter
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote: > > > From: Yang Shi > > Account the number of demoted pages into reclaim_state->nr_demoted. > > Add pgdemote_kswapd and pgdemote_direct VM counters showed in > /proc/vmstat. > > [ daveh: >- __count_vm_events() a bit, and made them look at the THP > size directly rather than getting data from migrate_pages() > ] > > Signed-off-by: Yang Shi > Signed-off-by: Dave Hansen > Reviewed-by: Yang Shi > Cc: Wei Xu > Cc: David Rientjes > Cc: Huang Ying > Cc: Dan Williams > Cc: David Hildenbrand > Cc: osalvador These counters can be more useful if they are per-node. Reviewed-by: Wei Xu
Re: [PATCH 05/10] mm/migrate: demote pages during reclaim
> +static unsigned int demote_page_list(struct list_head *demote_pages, > +struct pglist_data *pgdat, > +struct scan_control *sc) sc is not needed and can be removed from demote_page_list(). Reviewed-by: Wei Xu
Re: [PATCH 02/10] mm/numa: automatically generate node migration order
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote:
> +/*
> + * node_demotion[] example:
> + *
> + * Consider a system with two sockets. Each socket has
> + * three classes of memory attached: fast, medium and slow.
> + * Each memory class is placed in its own NUMA node. The
> + * CPUs are placed in the node with the "fast" memory. The
> + * 6 NUMA nodes (0-5) might be split among the sockets like
> + * this:
> + *
> + * Socket A: 0, 1, 2
> + * Socket B: 3, 4, 5
> + *
> + * When Node 0 fills up, its memory should be migrated to
> + * Node 1. When Node 1 fills up, it should be migrated to
> + * Node 2. The migration path start on the nodes with the
> + * processors (since allocations default to this node) and
> + * fast memory, progress through medium and end with the
> + * slow memory:
> + *
> + * 0 -> 1 -> 2 -> stop
> + * 3 -> 4 -> 5 -> stop
> + *
> + * This is represented in the node_demotion[] like this:
> + *
> + * { 1, // Node 0 migrates to 1
> + *2, // Node 1 migrates to 2
> + * -1, // Node 2 does not migrate
> + *4, // Node 3 migrates to 4
> + *5, // Node 4 migrates to 5
> + * -1} // Node 5 does not migrate
> + */
In this example, if we want to support multiple nodes as the demotion
target of a source node, we can group these nodes into three tiers
(classes):
fast class:
0 -> {1, 4} // 1 is the preferred
3 -> {4, 1} // 4 is the preferred
medium class:
1 -> {2, 5} // 2 is the preferred
4 -> {5, 2} // 5 is the preferred
slow class:
2 -> stop
5 -> stop
This can guarantee there are no cycles, either. Does it sound sensible?
> +again:
> + this_pass = next_pass;
> + next_pass = NODE_MASK_NONE;
> + /*
> +* To avoid cycles in the migration "graph", ensure
> +* that migration sources are not future targets by
> +* setting them in 'used_targets'. Do this only
> +* once per pass so that multiple source nodes can
> +* share a target node.
> +*
> +* 'used_targets' will become unavailable in future
> +* passes. This limits some opportunities for
> +* multiple source nodes to share a destination.
> +*/
> + nodes_or(used_targets, used_targets, this_pass);
> + for_each_node_mask(node, this_pass) {
> + int target_node = establish_migrate_target(node,
> _targets);
> +
> + if (target_node == NUMA_NO_NODE)
> + continue;
> +
> + /* Visit targets from this pass in the next pass: */
> + node_set(target_node, next_pass);
> + }
> + /* Is another pass necessary? */
> + if (!nodes_empty(next_pass))
> + goto again;
This goto seems like exactly a "do {} while" loop. Any particular reason not to
use "do {} while" here?
Re: [PATCH 04/10] mm/migrate: make migrate_pages() return nr_succeeded
On Fri, Apr 9, 2021 at 8:50 AM Dave Hansen wrote: > I also considered passing NULL to mean "I don't care about > nr_succeeded". I mostly avoided it to reduce churn. But, looking at it > here, it does seem cleaner. > > Any objections to moving over to Oscar's suggestion? I like this approach (making *nr_succeeded an optional argument). No objection here.
Re: [PATCH 04/10] mm/migrate: make migrate_pages() return nr_succeeded
I agree that it is a good further improvement to make nr_succeeded an optional
output argument of migrate_pages() given that most callers don't need it. IMHO,
the most important thing in this matter is to ensure that nr_succeeded only
returns (when its return value is needed) the successfully migrated
pages in this
round and doesn't accumulate. This is addressed by both proposals.
On Thu, Apr 8, 2021 at 10:06 PM Oscar Salvador wrote:
>
> On Thu, Apr 08, 2021 at 01:40:33PM -0700, Yang Shi wrote:
> > Thanks a lot for the example code. You didn't miss anything. At first
> > glance, I thought your suggestion seemed neater. Actually I
> > misunderstood what Dave said about "That could really have caused some
> > interesting problems." with multiple calls to migrate_pages(). I was
> > thinking about:
> >
> > unsigned long foo()
> > {
> > unsigned long *ret_succeeded;
> >
> > migrate_pages(..., ret_succeeded);
> >
> > migrate_pages(..., ret_succeeded);
> >
> > return *ret_succeeded;
> > }
>
> But that would not be a problem as well. I mean I am not sure what is
> foo() supposed to do.
> I assume is supposed to return the *total* number of pages that were
> migrated?
>
> Then could do something like:
>
> unsigned long foo()
> {
> unsigned long ret_succeeded;
> unsigned long total_succeeded = 0;
>
> migrate_pages(..., _succeeded);
> total_succeeded += ret_succeeded;
>
> migrate_pages(..., _succeeded);
> total_succeeded += ret_succeeded;
>
> return *total_succeeded;
> }
>
> But AFAICS, you would have to do that with Wei Xu's version and with
> mine, no difference there.
>
> IIUC, Dave's concern was that nr_succeeded was only set to 0 at the beginning
> of the function, and never reset back, which means, we would carry the
> sum of previous nr_succeeded instead of the nr_succeeded in that round.
> That would be misleading for e.g: reclaim in case we were to call
> migrate_pages() several times, as instead of a delta value, nr_succeeded
> would accumulate.
>
> But that won't happen neither with Wei Xu's version nor with mine.
>
> --
> Oscar Salvador
> SUSE L3
Re: [PATCH 01/10] mm/numa: node demotion data structure and lookup
It makes sense to start with a simple node tiering model like this
change, which looks good to me.
I do want to mention a likely usage scenario that motivates the need
for a list of nodes as the demotion target of a source node.
Access to a cross-socket DRAM node is still fast enough. So to minimize
memory stranding, job processes can be allowed to fall back to
allocate pages from a remote DRAM node.
But cross-socket access to PMEM nodes (the slower tier) can be slow,
especially for random writes. It is then desirable not to demote the
pages of a process to a remote PMEM node, even when the pages are on
a remote DRAM node, which has the remote PMEM node as its demotion
target. At the same time, it is also desirable to still be able to
demote such pages when they become cold so that the more precious
DRAM occupied by these pages can be used for more active data.
To support such use cases, we need to be able to specify a list of
demotion target nodes for the remote DRAM node, which should include
the PMEM node closer to the process. Certainly, we will also need an
ability to limit the demotion target nodes of a process (or a cgroup)
to ensure that only local PMEM nodes are eligible as the actual
demotion target.
Note that demoting a page to a remote PMEM node is more acceptable
than a process accesses the same remote PMEM node because demotion
is one-time, sequential access, and can also use non-temporal stores
to reduce the access overheads and bypass caches.
Reviewed-by: Wei Xu
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> Prepare for the kernel to auto-migrate pages to other memory nodes
> with a user defined node migration table. This allows creating single
> migration target for each NUMA node to enable the kernel to do NUMA
> page migrations instead of simply reclaiming colder pages. A node
> with no target is a "terminal node", so reclaim acts normally there.
> The migration target does not fundamentally _need_ to be a single node,
> but this implementation starts there to limit complexity.
>
> If you consider the migration path as a graph, cycles (loops) in the
> graph are disallowed. This avoids wasting resources by constantly
> migrating (A->B, B->A, A->B ...). The expectation is that cycles will
> never be allowed.
>
> Signed-off-by: Dave Hansen
> Reviewed-by: Yang Shi
> Cc: Wei Xu
> Cc: David Rientjes
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: osalvador
>
> --
>
> changes since 20200122:
> * Make node_demotion[] __read_mostly
>
> changes in July 2020:
> - Remove loop from next_demotion_node() and get_online_mems().
>This means that the node returned by next_demotion_node()
>might now be offline, but the worst case is that the
>allocation fails. That's fine since it is transient.
> ---
>
> b/mm/migrate.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff -puN mm/migrate.c~0006-node-Define-and-export-memory-migration-path
> mm/migrate.c
> --- a/mm/migrate.c~0006-node-Define-and-export-memory-migration-path
> 2021-03-31 15:17:10.734000264 -0700
> +++ b/mm/migrate.c 2021-03-31 15:17:10.742000264 -0700
> @@ -1163,6 +1163,23 @@ out:
> return rc;
> }
>
> +static int node_demotion[MAX_NUMNODES] __read_mostly =
> + {[0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE};
> +
> +/**
> + * next_demotion_node() - Get the next node in the demotion path
> + * @node: The starting node to lookup the next node
> + *
> + * @returns: node id for next memory node in the demotion path hierarchy
> + * from @node; NUMA_NO_NODE if @node is terminal. This does not keep
> + * @node online or guarantee that it *continues* to be the next demotion
> + * target.
> + */
> +int next_demotion_node(int node)
> +{
> + return node_demotion[node];
> +}
> +
> /*
> * Obtain the lock on page, remove all ptes and migrate the page
> * to the newly allocated page in newpage.
> _
Re: [PATCH 07/10] mm/vmscan: add helper for querying ability to age anonymous pages
> +/*
> + * Anonymous LRU management is a waste if there is
> + * ultimately no way to reclaim the memory.
> + */
> +bool anon_should_be_aged(struct lruvec *lruvec)
> +{
> + struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> +
> + /* Aging the anon LRU is valuable if swap is present: */
> + if (total_swap_pages > 0)
> + return true;
> +
> + /* Also valuable if anon pages can be demoted: */
> + if (next_demotion_node(pgdat->node_id) >= 0)
> + return true;
> +
> + /* No way to reclaim anon pages. Should not age anon LRUs: */
> + return false;
> +}
anon_should_be_aged() doesn't really need "lruvec". It essentially
answers whether the pages of the given node can be swapped or demoted.
So it would be clearer and less confusing if anon_should_be_aged()
takes "pgdat" instead of "lruvec" as the argument. The call to
mem_cgroup_lruvec(NULL, pgdat) in age_active_anon() can then be removed
as well.
Re: [PATCH] ARM: hisi: use the correct HiSilicon copyright
Hi Hao Fang, On 2021/3/30 14:51, Hao Fang wrote: > s/Hisilicon/HiSilicon/ > It should use capital S, according to > https://www.hisilicon.com/en/terms-of-use. > > Signed-off-by: Hao Fang Thanks! Applied to the hisilicon arm32 SoC tree. Best Regards, Wei > --- > arch/arm/mach-hisi/hisilicon.c | 4 ++-- > arch/arm/mach-hisi/hotplug.c | 2 +- > arch/arm/mach-hisi/platmcpm.c | 2 +- > arch/arm/mach-hisi/platsmp.c | 2 +- > 4 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c > index 07ea28b..b8d14b3 100644 > --- a/arch/arm/mach-hisi/hisilicon.c > +++ b/arch/arm/mach-hisi/hisilicon.c > @@ -1,8 +1,8 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > - * (Hisilicon's SoC based) flattened device tree enabled machine > + * (HiSilicon's SoC based) flattened device tree enabled machine > * > - * Copyright (c) 2012-2013 Hisilicon Ltd. > + * Copyright (c) 2012-2013 HiSilicon Ltd. > * Copyright (c) 2012-2013 Linaro Ltd. > * > * Author: Haojian Zhuang > diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c > index 5c5f255..c517941 100644 > --- a/arch/arm/mach-hisi/hotplug.c > +++ b/arch/arm/mach-hisi/hotplug.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > * Copyright (c) 2013 Linaro Ltd. > - * Copyright (c) 2013 Hisilicon Limited. > + * Copyright (c) 2013 HiSilicon Limited. > */ > > #include > diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c > index f155e32..96a4840 100644 > --- a/arch/arm/mach-hisi/platmcpm.c > +++ b/arch/arm/mach-hisi/platmcpm.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > * Copyright (c) 2013-2014 Linaro Ltd. > - * Copyright (c) 2013-2014 Hisilicon Limited. > + * Copyright (c) 2013-2014 HiSilicon Limited. > */ > #include > #include > diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c > index da7a09c..a56cc64 100644 > --- a/arch/arm/mach-hisi/platsmp.c > +++ b/arch/arm/mach-hisi/platsmp.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > * Copyright (c) 2013 Linaro Ltd. > - * Copyright (c) 2013 Hisilicon Limited. > + * Copyright (c) 2013 HiSilicon Limited. > * Based on arch/arm/mach-vexpress/platsmp.c, Copyright (C) 2002 ARM Ltd. > */ > #include >
Re: [PATCH 08/10] mm/vmscan: Consider anonymous pages without swap
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote:
>
>
> From: Keith Busch
>
> Reclaim anonymous pages if a migration path is available now that
> demotion provides a non-swap recourse for reclaiming anon pages.
>
> Note that this check is subtly different from the
> anon_should_be_aged() checks. This mechanism checks whether a
> specific page in a specific context *can* actually be reclaimed, given
> current swap space and cgroup limits
>
> anon_should_be_aged() is a much simpler and more preliminary check
> which just says whether there is a possibility of future reclaim.
>
> #Signed-off-by: Keith Busch
> Cc: Keith Busch
> Signed-off-by: Dave Hansen
> Reviewed-by: Yang Shi
> Cc: Wei Xu
> Cc: David Rientjes
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: osalvador
>
> --
>
> Changes from Dave 10/2020:
> * remove 'total_swap_pages' modification
>
> Changes from Dave 06/2020:
> * rename reclaim_anon_pages()->can_reclaim_anon_pages()
>
> Note: Keith's Intel SoB is commented out because he is no
> longer at Intel and his @intel.com mail will bounce.
> ---
>
> b/mm/vmscan.c | 35 ---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff -puN mm/vmscan.c~0009-mm-vmscan-Consider-anonymous-pages-without-swap
> mm/vmscan.c
> --- a/mm/vmscan.c~0009-mm-vmscan-Consider-anonymous-pages-without-swap
> 2021-03-31 15:17:19.388000242 -0700
> +++ b/mm/vmscan.c 2021-03-31 15:17:19.407000242 -0700
> @@ -287,6 +287,34 @@ static bool writeback_throttling_sane(st
> }
> #endif
>
> +static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg,
> + int node_id)
> +{
> + if (memcg == NULL) {
> + /*
> +* For non-memcg reclaim, is there
> +* space in any swap device?
> +*/
> + if (get_nr_swap_pages() > 0)
> + return true;
> + } else {
> + /* Is the memcg below its swap limit? */
> + if (mem_cgroup_get_nr_swap_pages(memcg) > 0)
> + return true;
> + }
> +
> + /*
> +* The page can not be swapped.
> +*
> +* Can it be reclaimed from this node via demotion?
> +*/
> + if (next_demotion_node(node_id) >= 0)
> + return true;
When neither swap space nor RECLAIM_MIGRATE is enabled, but
next_demotion_node() is configured, inactive pages cannot be swapped out
nor demoted. However, this check can still cause these pages to be sent
to shrink_page_list() (e.g., when can_reclaim_anon_pages() is called by
get_scan_count()) and make the THP pages being unnecessarily split there.
One fix would be to guard this next_demotion_node() check with the
RECLAIM_MIGRATE node_reclaim_mode check. This RECLAIM_MIGRATE
check needs to be applied to other calls to next_demotion_node() in
vmscan.c as well.
> +
> + /* No way to reclaim anon pages */
> + return false;
> +}
> +
> /*
> * This misses isolated pages which are not accounted for to save counters.
> * As the data only determines if reclaim or compaction continues, it is
> @@ -298,7 +326,7 @@ unsigned long zone_reclaimable_pages(str
>
> nr = zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_FILE) +
> zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_FILE);
> - if (get_nr_swap_pages() > 0)
> + if (can_reclaim_anon_pages(NULL, zone_to_nid(zone)))
> nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
> zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
>
> @@ -2323,6 +2351,7 @@ enum scan_balance {
> static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>unsigned long *nr)
> {
> + struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> struct mem_cgroup *memcg = lruvec_memcg(lruvec);
> unsigned long anon_cost, file_cost, total_cost;
> int swappiness = mem_cgroup_swappiness(memcg);
> @@ -2333,7 +2362,7 @@ static void get_scan_count(struct lruvec
> enum lru_list lru;
>
> /* If we have no swap space, do not bother scanning anon pages. */
> - if (!sc->may_swap || mem_cgroup_get_nr_swap_pages(memcg) <= 0) {
> + if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id)) {
Demotion of anon pages still depends on sc->may_swap. Any thoughts on
decoupling
demotion from swapping more completely?
> scan_balance = SCAN_FILE;
> goto out;
> }
> @@ -2708,7 +2737,7 @@ static inlin
Re: [PATCH 09/10] mm/vmscan: never demote for memcg reclaim
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> Global reclaim aims to reduce the amount of memory used on
> a given node or set of nodes. Migrating pages to another
> node serves this purpose.
>
> memcg reclaim is different. Its goal is to reduce the
> total memory consumption of the entire memcg, across all
> nodes. Migration does not assist memcg reclaim because
> it just moves page contents between nodes rather than
> actually reducing memory consumption.
>
> Signed-off-by: Dave Hansen
> Suggested-by: Yang Shi
> Reviewed-by: Yang Shi
> Cc: Wei Xu
> Cc: David Rientjes
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: osalvador
> ---
>
> b/mm/vmscan.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff -puN mm/vmscan.c~never-demote-for-memcg-reclaim mm/vmscan.c
> --- a/mm/vmscan.c~never-demote-for-memcg-reclaim2021-03-31
> 15:17:20.476000239 -0700
> +++ b/mm/vmscan.c 2021-03-31 15:17:20.487000239 -0700
> @@ -288,7 +288,8 @@ static bool writeback_throttling_sane(st
> #endif
>
> static inline bool can_reclaim_anon_pages(struct mem_cgroup *memcg,
> - int node_id)
> + int node_id,
> + struct scan_control *sc)
I don't see "sc" gets used in can_reclaim_anon_pages(). Remove it?
> {
> if (memcg == NULL) {
> /*
> @@ -326,7 +327,7 @@ unsigned long zone_reclaimable_pages(str
>
> nr = zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_FILE) +
> zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_FILE);
> - if (can_reclaim_anon_pages(NULL, zone_to_nid(zone)))
> + if (can_reclaim_anon_pages(NULL, zone_to_nid(zone), NULL))
> nr += zone_page_state_snapshot(zone, NR_ZONE_INACTIVE_ANON) +
> zone_page_state_snapshot(zone, NR_ZONE_ACTIVE_ANON);
>
> @@ -1064,7 +1065,8 @@ static enum page_references page_check_r
> return PAGEREF_RECLAIM;
> }
>
> -static bool migrate_demote_page_ok(struct page *page)
> +static bool migrate_demote_page_ok(struct page *page,
> + struct scan_control *sc)
> {
> int next_nid = next_demotion_node(page_to_nid(page));
>
> @@ -1072,6 +1074,10 @@ static bool migrate_demote_page_ok(struc
> VM_BUG_ON_PAGE(PageHuge(page), page);
> VM_BUG_ON_PAGE(PageLRU(page), page);
>
> + /* It is pointless to do demotion in memcg reclaim */
> + if (cgroup_reclaim(sc))
> + return false;
> +
> if (next_nid == NUMA_NO_NODE)
> return false;
> if (PageTransHuge(page) && !thp_migration_supported())
> @@ -1328,7 +1334,7 @@ retry:
> * Before reclaiming the page, try to relocate
> * its contents to another node.
> */
> - if (do_demote_pass && migrate_demote_page_ok(page)) {
> + if (do_demote_pass && migrate_demote_page_ok(page, sc)) {
> list_add(>lru, _pages);
> unlock_page(page);
> continue;
> @@ -2362,7 +2368,7 @@ static void get_scan_count(struct lruvec
> enum lru_list lru;
>
> /* If we have no swap space, do not bother scanning anon pages. */
> - if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id)) {
> + if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id,
> sc)) {
> scan_balance = SCAN_FILE;
> goto out;
> }
> @@ -2737,7 +2743,7 @@ static inline bool should_continue_recla
> */
> pages_for_compaction = compact_gap(sc->order);
> inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
> - if (can_reclaim_anon_pages(NULL, pgdat->node_id))
> + if (can_reclaim_anon_pages(NULL, pgdat->node_id, sc))
> inactive_lru_pages += node_page_state(pgdat,
> NR_INACTIVE_ANON);
>
> return inactive_lru_pages > pages_for_compaction;
> _
Re: [PATCH 04/10] mm/migrate: make migrate_pages() return nr_succeeded
A small suggestion: Given that migrate_pages() requires that
*nr_succeeded should be initialized to 0 when it is called due to its
use of *nr_succeeded in count_vm_events() and trace_mm_migrate_pages(),
it would be less error-prone if migrate_pages() initializes
*nr_succeeded itself.
On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen wrote:
>
>
> From: Yang Shi
>
> The migrate_pages() returns the number of pages that were not migrated,
> or an error code. When returning an error code, there is no way to know
> how many pages were migrated or not migrated.
>
> In the following patch, migrate_pages() is used to demote pages to PMEM
> node, we need account how many pages are reclaimed (demoted) since page
> reclaim behavior depends on this. Add *nr_succeeded parameter to make
> migrate_pages() return how many pages are demoted successfully for all
> cases.
>
> Signed-off-by: Yang Shi
> Signed-off-by: Dave Hansen
> Reviewed-by: Yang Shi
> Cc: Wei Xu
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: osalvador
>
> --
>
> Note: Yang Shi originally wrote the patch, thus the SoB. There was
> also a Reviewed-by provided since there were some modifications made
> to this after the original work.
>
> Changes since 20210302:
> * Fix definition of CONFIG_MIGRATION=n stub migrate_pages(). Its
>parameters were wrong, but oddly enough did not generate any
>compile errors.
>
> Changes since 20200122:
> * Fix migrate_pages() to manipulate nr_succeeded *value*
>rather than the pointer.
> ---
>
> b/include/linux/migrate.h |5 +++--
> b/mm/compaction.c |3 ++-
> b/mm/gup.c|3 ++-
> b/mm/memory-failure.c |4 +++-
> b/mm/memory_hotplug.c |4 +++-
> b/mm/mempolicy.c |8 ++--
> b/mm/migrate.c| 19 +++
> b/mm/page_alloc.c |9 ++---
> 8 files changed, 36 insertions(+), 19 deletions(-)
>
> diff -puN include/linux/migrate.h~migrate_pages-add-success-return
> include/linux/migrate.h
> --- a/include/linux/migrate.h~migrate_pages-add-success-return 2021-03-31
> 15:17:14.144000255 -0700
> +++ b/include/linux/migrate.h 2021-03-31 15:17:14.182000255 -0700
> @@ -40,7 +40,8 @@ extern int migrate_page(struct address_s
> struct page *newpage, struct page *page,
> enum migrate_mode mode);
> extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t
> free,
> - unsigned long private, enum migrate_mode mode, int reason);
> + unsigned long private, enum migrate_mode mode, int reason,
> + unsigned int *nr_succeeded);
> extern struct page *alloc_migration_target(struct page *page, unsigned long
> private);
> extern int isolate_movable_page(struct page *page, isolate_mode_t mode);
> extern void putback_movable_page(struct page *page);
> @@ -58,7 +59,7 @@ extern int migrate_page_move_mapping(str
> static inline void putback_movable_pages(struct list_head *l) {}
> static inline int migrate_pages(struct list_head *l, new_page_t new,
> free_page_t free, unsigned long private, enum migrate_mode
> mode,
> - int reason)
> + int reason, unsigned int *nr_succeeded)
> { return -ENOSYS; }
> static inline struct page *alloc_migration_target(struct page *page,
> unsigned long private)
> diff -puN mm/compaction.c~migrate_pages-add-success-return mm/compaction.c
> --- a/mm/compaction.c~migrate_pages-add-success-return 2021-03-31
> 15:17:14.146000255 -0700
> +++ b/mm/compaction.c 2021-03-31 15:17:14.186000255 -0700
> @@ -2247,6 +2247,7 @@ compact_zone(struct compact_control *cc,
> unsigned long last_migrated_pfn;
> const bool sync = cc->mode != MIGRATE_ASYNC;
> bool update_cached;
> + unsigned int nr_succeeded = 0;
>
> /*
> * These counters track activities during zone compaction. Initialize
> @@ -2364,7 +2365,7 @@ compact_zone(struct compact_control *cc,
>
> err = migrate_pages(>migratepages, compaction_alloc,
> compaction_free, (unsigned long)cc, cc->mode,
> - MR_COMPACTION);
> + MR_COMPACTION, _succeeded);
>
> trace_mm_compaction_migratepages(cc->nr_migratepages, err,
> >migratepages);
> diff -puN mm/gup.c~migrate_pages-add-success-return mm/gup.c
> --- a/mm/gup.c~migrate_pages-add-success-return 2021-03-31 15:17:14.15255
> -0700
> +++ b/mm/gup.c 2021-03-31 15:17:14.19255 -0
Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon
Hi Arnd,
On 2021/1/29 9:02, Wei Xu wrote:
> Hi Arnd,
>
> On 2021/1/28 22:08, Arnd Bergmann wrote:
>> On Wed, Jan 27, 2021 at 1:42 AM Wei Xu wrote:
>>> On 2021/1/27 6:23, Arnd Bergmann wrote:
>>>> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei wrote:
>>>>>
>>>>> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
>>>>> stated in "vendor-prefixes.yaml".
>>>>>
>>>>> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
>>>>> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670
>>>>> SoC")
>>>>> Signed-off-by: Zhen Lei
>>>>> Cc: Chen Feng
>>>>> Cc: Manivannan Sadhasivam
>>>>
>>>> I see this change in the pull request I got, but I'm a bit worried about
>>>> the
>>>> incompatible binding change. Wouldn't the correct path forward be to
>>>> list both the correct and the incorrect properties, both in the dts file
>>>> and in the driver that interprets the properties?
>>>
>>> Thanks for the comment!
>>> The reset driver will look for "hisilicon" firstly and fall back to "hisi".
>>> And the DTS is shipped with the driver together.
>>> So I think there is no compatible issue here.
>>> Please let me know if missed anything. Thanks!
>>
>> There are three things that can go wrong here, and this is only addressing
>> one of them:
>
> Thanks for the detailed explanation!
>
>>
>> 1. Updating the kernel on a machine with a dtb provided by the firmware
>> is a problem if the new driver can not handle the old properties. This
>> is correctly handled by the driver's fallback as soon as both trees
>> are merged.
>
> Agreed and the driver has been merged into the v5.11-rc1.
Sorry, I made a mistake. It has been merged into linux-next *not* the v5.11-rc1.
>
>>
>> 2. Updating the dtb while running an older kernel is now broken since
>> the driver can no longer read the property. This is less critical, but
>> it does seem easy enough to work around here by leaving both
>> properties in place.
>
> Yes, it is.
> But if leaving both in place, the dtbs_check will report following warning
> again:
> 'hisi,rst-syscon' does not match any of the regexes
>
> That is why leizhen changed the dtb.
> Do you think it is OK to assume no one will use the new dtb with an older
> kernel?
>
>>
>> 3. Bisecting through the git history across an incompatible change
>> means you can run into broken commits. We try hard to avoid that
>> if we are aware of a problem in advance. In this case it could be
>> avoided by only merging the incompatible DT change in a following
>> merge window after the driver change, or (better) by making it
>> a backward-compatible change the same way as addressing 2.
>
> Yes, agreed.
> And The DT change pull request is sent after the driver has been merged into
> v5.11-rc1.
I can drop this patch and revert what I have changed in Mauro's following patch:
"arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst"
Then resend the pull request. And pick up this patch after the next merge
window.
Do you think is it OK?
Thanks!
Best Regards,
Wei
>
> Really appreciate the detail you went to!
>
> Best Regards,
> Wei
>
>>
>> Arnd
>> .
>>
Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon
Hi Arnd,
On 2021/1/28 22:08, Arnd Bergmann wrote:
> On Wed, Jan 27, 2021 at 1:42 AM Wei Xu wrote:
>> On 2021/1/27 6:23, Arnd Bergmann wrote:
>>> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei wrote:
>>>>
>>>> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
>>>> stated in "vendor-prefixes.yaml".
>>>>
>>>> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
>>>> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670 SoC")
>>>> Signed-off-by: Zhen Lei
>>>> Cc: Chen Feng
>>>> Cc: Manivannan Sadhasivam
>>>
>>> I see this change in the pull request I got, but I'm a bit worried about the
>>> incompatible binding change. Wouldn't the correct path forward be to
>>> list both the correct and the incorrect properties, both in the dts file
>>> and in the driver that interprets the properties?
>>
>> Thanks for the comment!
>> The reset driver will look for "hisilicon" firstly and fall back to "hisi".
>> And the DTS is shipped with the driver together.
>> So I think there is no compatible issue here.
>> Please let me know if missed anything. Thanks!
>
> There are three things that can go wrong here, and this is only addressing
> one of them:
Thanks for the detailed explanation!
>
> 1. Updating the kernel on a machine with a dtb provided by the firmware
> is a problem if the new driver can not handle the old properties. This
> is correctly handled by the driver's fallback as soon as both trees
> are merged.
Agreed and the driver has been merged into the v5.11-rc1.
>
> 2. Updating the dtb while running an older kernel is now broken since
> the driver can no longer read the property. This is less critical, but
> it does seem easy enough to work around here by leaving both
> properties in place.
Yes, it is.
But if leaving both in place, the dtbs_check will report following warning
again:
'hisi,rst-syscon' does not match any of the regexes
That is why leizhen changed the dtb.
Do you think it is OK to assume no one will use the new dtb with an older
kernel?
>
> 3. Bisecting through the git history across an incompatible change
> means you can run into broken commits. We try hard to avoid that
> if we are aware of a problem in advance. In this case it could be
> avoided by only merging the incompatible DT change in a following
> merge window after the driver change, or (better) by making it
> a backward-compatible change the same way as addressing 2.
Yes, agreed.
And The DT change pull request is sent after the driver has been merged into
v5.11-rc1.
Really appreciate the detail you went to!
Best Regards,
Wei
>
> Arnd
> .
>
Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon
Hi Arnd,
On 2021/1/27 6:23, Arnd Bergmann wrote:
> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei wrote:
>>
>> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
>> stated in "vendor-prefixes.yaml".
>>
>> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
>> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670 SoC")
>> Signed-off-by: Zhen Lei
>> Cc: Chen Feng
>> Cc: Manivannan Sadhasivam
>
> I see this change in the pull request I got, but I'm a bit worried about the
> incompatible binding change. Wouldn't the correct path forward be to
> list both the correct and the incorrect properties, both in the dts file
> and in the driver that interprets the properties?
Thanks for the comment!
The reset driver will look for "hisilicon" firstly and fall back to "hisi".
And the DTS is shipped with the driver together.
So I think there is no compatible issue here.
Please let me know if missed anything. Thanks!
Best Regards,
Wei
>
> The binding file in this case would need to list the old name as deprecated,
> though I'm not sure how that would work without causing a warning about
> the unknown vendor prefix.
>
> Arnd
> .
>
Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon
Hi Zhen Lei,
On 2020/12/8 20:46, Zhen Lei wrote:
> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
> stated in "vendor-prefixes.yaml".
>
> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670 SoC")
> Signed-off-by: Zhen Lei
> Cc: Chen Feng
> Cc: Manivannan Sadhasivam
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 49c19c6879f95ce..bfb1375426d2b58 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -345,7 +345,7 @@
> crg_rst: crg_rst_controller {
> compatible = "hisilicon,hi3660-reset";
> #reset-cells = <2>;
> - hisi,rst-syscon = <_ctrl>;
> + hisilicon,rst-syscon = <_ctrl>;
> };
>
>
> @@ -376,7 +376,7 @@
>
> iomcu_rst: reset {
> compatible = "hisilicon,hi3660-reset";
> - hisi,rst-syscon = <>;
> + hisilicon,rst-syscon = <>;
> #reset-cells = <2>;
> };
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index 85b0dfb35d6d396..5c5a5dc964ea848 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -155,7 +155,7 @@
> compatible = "hisilicon,hi3670-reset",
>"hisilicon,hi3660-reset";
> #reset-cells = <2>;
> - hisi,rst-syscon = <_ctrl>;
> + hisilicon,rst-syscon = <_ctrl>;
> };
>
> pctrl: pctrl@e8a09000 {
>
Re: [PATCH v2 0/3] Added some missing DT settings for Hikey 970
Hi Mauro, On 2021/1/15 19:53, Mauro Carvalho Chehab wrote: > The Hikey 970 device tree has a few missing pieces that are required > in order for it to be able to support USB and DRM drivers upstream. > > Besides PM, USB and DRM specific bits, the hardware's binding > for I2C buses and pinctrl are missing. > > Those DT bindings come from the official Linaro Hikey 970 tree: > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > Changed in order to apply cleanly upstream. > > PS.: The changes from this series were submitted initially on this > patch series: > Move Hikey 970 USB support out of staging and add DT > > https://lore.kernel.org/lkml/cover.1605530560.git.mchehab+hua...@kernel.org/ > > I'm opting to split such series into separate patch series, in order to > make easier for review and upstream merge, as the original series > was mixing patches for different subsystems. > > Mauro Carvalho Chehab (3): > arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst > arm64: dts: hikey970-pinctrl.dtsi: add missing pinctrl settings > arm64: dts: hisilicon: hi3670.dtsi: add I2C settings > > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 77 +++ > .../boot/dts/hisilicon/hikey970-pinctrl.dtsi | 548 +- > 2 files changed, 614 insertions(+), 11 deletions(-) > Thanks! Series applied to the hisilicon arm64 dt tree with minor changes to align with the dtschema. Best Regards, Wei
Re: [v2] Old platforms: bring out your dead
Hi Arnd, On 2021/1/15 20:04, Arnd Bergmann wrote: > On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown) > wrote: >> On 2021/1/15 17:26, Arnd Bergmann wrote: >>> On Fri, Jan 15, 2021 at 8:08 AM Wei Xu wrote: >>>> On 2021/1/14 0:14, Arnd Bergmann wrote: >>>>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann wrote: >>>>> * mmp -- added in 2009, DT support is active, but board files might go >>>>> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left >>>>> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016 >>>> >>>> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64). >>>> Could you also help to drop the support of the hip04(arm32) which I think >>>> nobody use as well? >>> >>> Thank you for your reply! I actually meant to write hip04 instead of hip05, >>> so I was only asking about the two 32-bit targets. I would expect that >>> hip05 still has a few users, but wouldn't mind removing that as well if you >>> are sure there are none. >>> >>> Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509 >>> support, can you clarify how much reuse of IP blocks there is between >>> hip04 and those? In particular, hip04 has custom code for (at least) >>> platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those >>> were only the ones I see on a quick grep. >>> >>> If we remove hip04, should we remove all these drivers right away, >>> or keep some of them around? >> >> I think the drivers should be kept. > > Ok, will do. > >> Currently, at least hip04_eth.c and irq-hip04.c are used. These drivers >> were originally written for Hip04, but the drivers used by other boards >> maybe similar to them. Therefore, these drivers are extended without >> adding new drivers. > > Right, so the other chips just use compatible="hisilicon,hip04-intc" > etc. in their device trees? Is there a public copy of the dts files > somewhere that I can use for cross-referencing? Sorry if I'm > messing up the timeline for your upstreaming plans. > > It might actually be easier to leave hip01 and hip04 in the > tree for the moment until you have upstreamed the other SoC > support, and then we clean up by removing the unused bits > afterwards. I'll leave it to you both to tell me which way is easier > for you. I have aligned with Leizhen and as you suggested it is better to keep them for the moment. Thanks! Best Regards, Wei > > Arnd > . >
Re: [v2] Old platforms: bring out your dead
Hi Arnd, On 2021/1/14 0:14, Arnd Bergmann wrote: > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann wrote: > > Just to catch up on the replies I received on my initial email, here > is the updated status of all the Arm platforms I listed earlier, thanks > for everyone that contributed information on these platforms! > > These platforms were listed as likely unused and are now going to > be kept around, as we wait for work on them to resume: > > * axxia -- added in 2014, no notable changes after 2015 > (Alexander Sverdlin has patches and volunteered as a maintainer) > * bcm/kona -- added in 2013, no notable changes after 2014 > (Found activity in PostmarketOS, waiting for usptreaming) > * digicolor -- added in 2014, no notable changes after 2015 > (Baruch still uses it, no changes needed) > * dove -- added in 2009, obsoleted by mach-mvebu in 2015 > (Russell still has patches for cubox, we might remove the other >boards that are converted to DT though) > * nspire -- added in 2013, no notable changes after 2015 > (Fabian and Daniel confirmed this is alive and well, more >hardware support is planned) > * spear -- added in 2010, no notable changes since 2015 > (My mistake in reading the changelog, should have been > on the second list. The platform is still active, and Mattias > Wallin plans to send more hardware support and cleanup > patches) > > These platforms are confirmed to be dead upstream, and are going to > be removed: > > * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013 > * picoxcell -- added in 2011, already queued for removal > * prima2 -- added in 20111, no notable changes since 2015 > * tango -- added in 2015, sporadic changes until 2017, but abandoned > * u300 -- added in 2009, no notable changes since 2013 > * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes > > No reply yet, still planning for removal. Oleksij and Tony, please > confirm this is ok or let us know if we should keep them: > > * asm9260 -- added in 2014, no notable changes after 2015 > * vt8500 -- added in 2010, no notable changes since 2014 > > These were on the original list of platforms that are likely still > maintained and used despite their age, and I received a > confirmation that this is true (some of them off-list) > > * clps711x -- prehistoric, converted to multiplatform+DT in 2016 > * ep93xx -- added in 2006, LinusW still working on it, any users left? > * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have > one > * gemini -- added in 2009, LinusW still working on it > * highbank -- added in 2011, no changes after 2015, but Andre still uses it > * iop32x -- added in 2006, no notable changes other than my cleanup, still > used > * ixp4xx -- prehistoric, but LinusW and I are still working on it > * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL > * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users > * orion5x -- DT support still active, board files support to get reviewed > for removal and conversion to DT individually > * oxnas -- added in 2016, but already old then, few changes later > * pxa -- prehistoric, but a few boards may still have users > * rpc -- prehistoric, but I think Russell still uses his machine > * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it > > For these I received no reply yet. Again, these will stay for the moment > unless I get a reply, but if anyone has more information, please reply > here to document the status (adding a few more people to Cc): > > * mmp -- added in 2009, DT support is active, but board files might go > * cns3xxx -- added in 2010, last fixed in 2019, probably no users left > * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016 I think it is OK to drop the support of the hip01(arm32) and hip05(arm64). Could you also help to drop the support of the hip04(arm32) which I think nobody use as well? Thanks! Best Regards, Wei
Re: [PATCH 4/8] arm64: dts: hisilicon: Use generic "ngpios" rather than "snps,nr-gpios"
Hi Jisheng,
On 2020/11/9 17:05, Jisheng Zhang wrote:
> This is to remove similar errors as below:
>
> OF: /.../gpio-port@0: could not find phandle
>
> Commit 7569486d79ae ("gpio: dwapb: Add ngpios DT-property support")
> explained the reason of above errors well and added the generic
> "ngpios" property, let's use it.
>
> Signed-off-by: Jisheng Zhang
> ---
> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> index bc49955360db..fbe83eb9f77b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> @@ -335,7 +335,7 @@ porta: gpio-controller@0 {
> compatible = "snps,dw-apb-gpio-port";
> gpio-controller;
> #gpio-cells = <2>;
> - snps,nr-gpios = <32>;
> + ngpios = <32>;
> reg = <0>;
> interrupt-controller;
> #interrupt-cells = <2>;
> @@ -354,7 +354,7 @@ portb: gpio-controller@0 {
> compatible = "snps,dw-apb-gpio-port";
> gpio-controller;
> #gpio-cells = <2>;
> - snps,nr-gpios = <32>;
> + ngpios = <32>;
> reg = <0>;
> interrupt-controller;
> #interrupt-cells = <2>;
>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
Re: [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
Hi Serge,
On 2020/11/11 17:15, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> nodes are correctly named.
>
> Signed-off-by: Serge Semin
> Acked-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/hisi-x5hd2.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> index 3ee7967c202d..693b85b2cc7d 100644
> --- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> +++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> @@ -452,14 +452,14 @@ gmac1: ethernet@1841000 {
> status = "disabled";
> };
>
> - usb0: ehci@189 {
> + usb0: usb@189 {
> compatible = "generic-ehci";
> reg = <0x189 0x1000>;
> interrupts = <0 66 4>;
> clocks = < HIX5HD2_USB_CLK>;
> };
>
> - usb1: ohci@188 {
> + usb1: usb@188 {
> compatible = "generic-ohci";
> reg = <0x188 0x1000>;
> interrupts = <0 67 4>;
>
Thanks!
But a similar patch has been sent out earlier:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201012061225.1597-4-thunder.leiz...@huawei.com/
Best Regards,
Wei
Re: [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
Hi Serge,
On 2020/11/11 17:15, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> nodes are correctly named.
>
> Signed-off-by: Serge Semin
> Acked-by: Krzysztof Kozlowski
> ---
> arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> index 12bc1d3ed424..a4acecb75c89 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> @@ -585,7 +585,7 @@ pcie: pcie@986 {
> status = "disabled";
> };
>
> - ohci: ohci@988 {
> + ohci: usb@988 {
> compatible = "generic-ohci";
> reg = <0x988 0x1>;
> interrupts = ;
> @@ -600,7 +600,7 @@ ohci: ohci@988 {
> status = "disabled";
> };
>
> - ehci: ehci@989 {
> + ehci: usb@989 {
> compatible = "generic-ehci";
> reg = <0x989 0x1>;
> interrupts = ;
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index 50ceaa959bdc..1226440d54ad 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -373,7 +373,7 @@ refclk: refclk {
> #clock-cells = <0>;
> };
>
> - usb_ohci: ohci@a703 {
> + usb_ohci: usb@a703 {
> compatible = "generic-ohci";
> reg = <0x0 0xa703 0x0 0x1>;
> interrupt-parent = <_usb>;
> @@ -382,7 +382,7 @@ usb_ohci: ohci@a703 {
> status = "disabled";
> };
>
> - usb_ehci: ehci@a702 {
> + usb_ehci: usb@a702 {
> compatible = "generic-ehci";
> reg = <0x0 0xa702 0x0 0x1>;
> interrupt-parent = <_usb>;
> diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> index 4773a533fce5..93f99a5255ac 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> @@ -1253,7 +1253,7 @@ uart0: uart@602b {
> status = "disabled";
> };
>
> - usb_ohci: ohci@a703 {
> + usb_ohci: usb@a703 {
> compatible = "generic-ohci";
> reg = <0x0 0xa703 0x0 0x1>;
> interrupt-parent = <_usb>;
> @@ -1262,7 +1262,7 @@ usb_ohci: ohci@a703 {
> status = "disabled";
> };
>
> - usb_ehci: ehci@a702 {
> + usb_ehci: usb@a702 {
> compatible = "generic-ehci";
> reg = <0x0 0xa702 0x0 0x1>;
> interrupt-parent = <_usb>;
>
Thanks!
But a similar patch has been sent out earlier:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201012131739.1655-8-thunder.leiz...@huawei.com/
Best Regards,
Wei
Re: [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
Hi Serge,
On 2020/11/11 17:15, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named.
>
> Signed-off-by: Serge Semin
> Acked-by: Krzysztof Kozlowski
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index d25aac5e0bf8..aea3800029b5 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -1166,7 +1166,7 @@ usb_phy: usb-phy {
> };
> };
>
> - dwc3: dwc3@ff10 {
> + dwc3: usb@ff10 {
> compatible = "snps,dwc3";
> reg = <0x0 0xff10 0x0 0x10>;
>
>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
Re: [PATCH 00/11] clean up some Hisilicon-related errors detected by DT schema on arm64
Hi Zhen, On 2020/10/12 21:17, Zhen Lei wrote: > These patches are based on the latest linux-next. Because some txt files have > not converted to DT schema, so a lot of errors can not be fixed now. This > time, > only some obvious errors are cleared. > > Zhen Lei (11): > arm64: dts: hisilicon: normalize the node name of the ITS devices > arm64: dts: hisilicon: separate each group of data in the property > "reg" > arm64: dts: hisilicon: write the values of property-units into a > uint32 array > arm64: dts: hisilicon: remove unused property pinctrl-names > arm64: dts: hisilicon: place clock-names "biu" before "ciu" > arm64: dts: hisilicon: normalize the node name of the SMMU devices > arm64: dts: hisilicon: normalize the node name of the usb devices > arm64: dts: hisilicon: normalize the node name of the UART devices > arm64: dts: hisilicon: list all clocks required by spi-pl022.yaml > arm64: dts: hisilicon: list all clocks required by pl011.yaml > arm64: dts: hisilicon: list all clocks required by > snps-dw-apb-uart.yaml > > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 11 +- > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 5 +- > arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 27 ++-- > arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 4 +- > arch/arm64/boot/dts/hisilicon/hip05.dtsi | 20 +-- > arch/arm64/boot/dts/hisilicon/hip06.dtsi | 14 +- > arch/arm64/boot/dts/hisilicon/hip07.dtsi | 178 > - > 7 files changed, 129 insertions(+), 130 deletions(-) > Thanks! Series applied to the hisilicon arm64 dt tree. Best Regards, Wei
Re: [PATCH v2 00/10] clean up all Hisilicon-related errors detected by DT schema on arm32
Hi Zhen, On 2020/10/12 14:12, Zhen Lei wrote: > v1 --> v2: > Too deep in arm32. I forgot arm64. Add property "#reset-cells" into > sysctrl.yaml (Patch 9). > > > v1: > These patches are based on the latest linux-next. > > Zhen Lei (10): > ARM: dts: hisilicon: fix errors detected by snps-dw-apb-uart.yaml > ARM: dts: hisilicon: fix errors detected by pl011.yaml > ARM: dts: hisilicon: fix errors detected by usb yaml > ARM: dts: hisilicon: fix errors detected by simple-bus.yaml > ARM: dts: hisilicon: fix errors detected by root-node.yaml > ARM: dts: hisilicon: fix errors detected by synopsys-dw-mshc.yaml > ARM: dts: hisilicon: fix errors detected by spi-pl022.yaml > ARM: dts: hisilicon: fix errors detected by syscon.yaml Thanks! Fixed some typos in the commit and applied all the dts changes to the hisilicon arm32 dt tree. Best Regards, Wei > dt-bindings: arm: hisilicon: add missing properties into sysctrl.yaml > dt-bindings: arm: hisilicon: add missing properties into cpuctrl.yaml > > .../bindings/arm/hisilicon/controller/cpuctrl.yaml | 27 +- > .../bindings/arm/hisilicon/controller/sysctrl.yaml | 28 +-- > arch/arm/boot/dts/hi3519-demb.dts | 2 +- > arch/arm/boot/dts/hi3519.dtsi | 32 - > arch/arm/boot/dts/hi3620-hi4511.dts| 24 ++--- > arch/arm/boot/dts/hi3620.dtsi | 32 - > arch/arm/boot/dts/hip01-ca9x2.dts | 2 +- > arch/arm/boot/dts/hip01.dtsi | 26 +++--- > arch/arm/boot/dts/hip04-d01.dts| 2 +- > arch/arm/boot/dts/hip04.dtsi | 6 ++-- > arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 2 +- > arch/arm/boot/dts/hisi-x5hd2.dtsi | 42 > +++--- > 12 files changed, 136 insertions(+), 89 deletions(-) >
Re: [PATCH v5 09/17] ARM: dts: hisilicon: fix ststem controller compatible node
Hi Zhen Lei,
On 2020/9/29 22:14, Zhen Lei wrote:
> The DT binding for Hisilicon system controllers requires to have a
> "syscon" compatible string.
>
> Signed-off-by: Zhen Lei
Thanks!
Applied to the hisilicon arm32 dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/hi3620.dtsi | 2 +-
> arch/arm/boot/dts/hip04.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
> index 355175b25fd6220..f683440ee5694b4 100644
> --- a/arch/arm/boot/dts/hi3620.dtsi
> +++ b/arch/arm/boot/dts/hi3620.dtsi
> @@ -89,7 +89,7 @@
> };
>
> sysctrl: system-controller@802000 {
> - compatible = "hisilicon,sysctrl";
> + compatible = "hisilicon,sysctrl", "syscon";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0x802000 0x1000>;
> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
> index f5871b1d1ec452c..555bc6b6720fc94 100644
> --- a/arch/arm/boot/dts/hip04.dtsi
> +++ b/arch/arm/boot/dts/hip04.dtsi
> @@ -213,7 +213,7 @@
> };
>
> sysctrl: sysctrl {
> - compatible = "hisilicon,sysctrl";
> + compatible = "hisilicon,sysctrl", "syscon";
> reg = <0x3e0 0x0010>;
> };
>
>
Re: [PATCH v5 08/17] ARM: dts: add SD5203 dts
Hi Zhen Lei,
On 2020/9/29 22:14, Zhen Lei wrote:
> From: Kefeng Wang
>
> Add sd5203.dts for Hisilicon SD5203 SoC platform.
>
> Signed-off-by: Kefeng Wang
> Signed-off-by: Zhen Lei
Thanks!
Applied to the hisilicon arm32 dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/sd5203.dts | 96
>
> 2 files changed, 98 insertions(+)
> create mode 100644 arch/arm/boot/dts/sd5203.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4572db3fa5ae302..1d1262df5c55907 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -357,6 +357,8 @@ dtb-$(CONFIG_ARCH_MPS2) += \
> mps2-an399.dtb
> dtb-$(CONFIG_ARCH_MOXART) += \
> moxart-uc7112lx.dtb
> +dtb-$(CONFIG_ARCH_SD5203) += \
> + sd5203.dtb
> dtb-$(CONFIG_SOC_IMX1) += \
> imx1-ads.dtb \
> imx1-apf9328.dtb
> diff --git a/arch/arm/boot/dts/sd5203.dts b/arch/arm/boot/dts/sd5203.dts
> new file mode 100644
> index 000..3cc9a23910be62e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sd5203.dts
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2020 Hisilicon Limited.
> + *
> + * DTS file for Hisilicon SD5203 Board
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "Hisilicon SD5203";
> + compatible = "H836ASDJ", "hisilicon,sd5203";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs="console=ttyS0,9600
> earlycon=uart8250,mmio32,0x1600d000";
> + };
> +
> + aliases {
> + serial0 =
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0 {
> + device_type = "cpu";
> + compatible = "arm,arm926ej-s";
> + reg = <0x0>;
> + };
> + };
> +
> + memory@3000 {
> + device_type = "memory";
> + reg = <0x3000 0x800>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges;
> +
> + vic: interrupt-controller@1013 {
> + compatible = "snps,dw-apb-ictl";
> + reg = <0x1013 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + refclk125mhz: refclk125mhz {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12500>;
> + };
> +
> + timer0: timer@16002000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x16002000 0x1000>;
> + interrupts = <4>;
> + clocks = <>;
> + clock-names = "apb_pclk";
> + };
> +
> + timer1: timer@16003000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x16003000 0x1000>;
> + interrupts = <5>;
> + clocks = <>;
> + clock-names = "apb_pclk";
> + };
> +
> + uart0: serial@1600d000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x1600d000 0x1000>;
> + bus_id = "uart0";
> + clocks = <>;
> + clock-names = "baudclk", "apb_pclk";
> + reg-shift = <2>;
> + interrupts = <17>;
> + };
> +
> + uart1: serial@1600c000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x1600c000 0x1000>;
> + clocks = <>;
> + clock-names = "baudclk", "apb_pclk";
> + reg-shift = <2>;
> + interrupts = <16>;
> + status = "disabled";
> + };
> + };
> +};
>
Re: [PATCH v5 07/17] ARM: debug: add UART early console support for SD5203
Hi Zhen Lei, On 2020/9/29 22:14, Zhen Lei wrote: > From: Kefeng Wang > > Add support of early console for SD5203. > > Signed-off-by: Kefeng Wang > Signed-off-by: Zhen Lei Thanks! Applied to the hisilicon arm32 SoC tree. Best Regards, Wei > --- > arch/arm/Kconfig.debug | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index 8a66a4e3549..d27a7764c3bfb46 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1086,6 +1086,14 @@ choice > on SA-11x0 UART ports. The kernel will check for the first > enabled UART in a sequence 3-1-2. > > + config DEBUG_SD5203_UART > + bool "Hisilicon SD5203 Debug UART" > + depends on ARCH_SD5203 > + select DEBUG_UART_8250 > + help > + Say Y here if you want kernel low-level debugging support > + on SD5203 UART. > + > config DEBUG_SOCFPGA_UART0 > depends on ARCH_SOCFPGA > bool "Use SOCFPGA UART0 for low-level debug" > @@ -1639,6 +1647,7 @@ config DEBUG_UART_PHYS > default 0x11006000 if DEBUG_MT6589_UART0 > default 0x11009000 if DEBUG_MT8135_UART3 > default 0x1600 if DEBUG_INTEGRATOR > + default 0x1600d000 if DEBUG_SD5203_UART > default 0x18000300 if DEBUG_BCM_5301X > default 0x18000400 if DEBUG_BCM_HR2 > default 0x1801 if DEBUG_SIRFATLAS7_UART0 > @@ -1841,7 +1850,7 @@ config DEBUG_UART_VIRT > default 0xfec6 if DEBUG_SIRFPRIMA2_UART1 > default 0xfec9 if DEBUG_RK32_UART2 > default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1 > - default 0xfed0d000 if DEBUG_DAVINCI_DA8XX_UART2 > + default 0xfed0d000 if DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_SD5203_UART > default 0xfed6 if DEBUG_RK29_UART0 > default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2 > default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3 >
Re: [PATCH v5 06/17] ARM: hisi: add support for SD5203 SoC
Hi Zhen Lei, On 2020/9/29 22:14, Zhen Lei wrote: > From: Kefeng Wang > > Enable support for the Hisilicon SD5203 SoC. The core is ARM926EJ-S. > > Signed-off-by: Kefeng Wang > Signed-off-by: Zhen Lei Thanks! Applied to the hisilicon arm32 SoC tree. Best Regards, Wei > --- > arch/arm/mach-hisi/Kconfig | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig > index 3b010fe7c0e9b48..2e980f834a6aa1b 100644 > --- a/arch/arm/mach-hisi/Kconfig > +++ b/arch/arm/mach-hisi/Kconfig > @@ -1,9 +1,9 @@ > # SPDX-License-Identifier: GPL-2.0-only > config ARCH_HISI > bool "Hisilicon SoC Support" > - depends on ARCH_MULTI_V7 > + depends on ARCH_MULTI_V7 || ARCH_MULTI_V5 > select ARM_AMBA > - select ARM_GIC > + select ARM_GIC if ARCH_MULTI_V7 > select ARM_TIMER_SP804 > select POWER_RESET > select POWER_RESET_HISI > @@ -15,6 +15,7 @@ menu "Hisilicon platform type" > > config ARCH_HI3xxx > bool "Hisilicon Hi36xx family" > + depends on ARCH_MULTI_V7 > select CACHE_L2X0 > select HAVE_ARM_SCU if SMP > select HAVE_ARM_TWD if SMP > @@ -25,6 +26,7 @@ config ARCH_HI3xxx > > config ARCH_HIP01 > bool "Hisilicon HIP01 family" > + depends on ARCH_MULTI_V7 > select HAVE_ARM_SCU if SMP > select HAVE_ARM_TWD if SMP > select ARM_GLOBAL_TIMER > @@ -33,6 +35,7 @@ config ARCH_HIP01 > > config ARCH_HIP04 > bool "Hisilicon HiP04 Cortex A15 family" > + depends on ARCH_MULTI_V7 > select ARM_ERRATA_798181 if SMP > select HAVE_ARM_ARCH_TIMER > select MCPM if SMP > @@ -43,6 +46,7 @@ config ARCH_HIP04 > > config ARCH_HIX5HD2 > bool "Hisilicon X5HD2 family" > + depends on ARCH_MULTI_V7 > select CACHE_L2X0 > select HAVE_ARM_SCU if SMP > select HAVE_ARM_TWD if SMP > @@ -50,6 +54,14 @@ config ARCH_HIX5HD2 > select PINCTRL_SINGLE > help > Support for Hisilicon HIX5HD2 SoC family > + > +config ARCH_SD5203 > + bool "Hisilicon SD5203 family" > + depends on ARCH_MULTI_V5 > + select DW_APB_ICTL > + help > + Support for Hisilicon SD5203 SoC family > + > endmenu > > endif >
Re: [PATCH v3 02/21] dt-bindings: arm: hisilicon: split the dt-bindings of each controller into a separate file
Hi Zhen Lei,
On 2020/9/27 14:21, Zhen Lei wrote:
> Split the devicetree bindings of each Hisilicon controller from
> hisilicon.txt into a separate file, the file name is the compatible name
> attach the .txt file name extension.
>
> All Hi6220 dedicated controllers are grouped into subdirectory "hi3620".
> All HiPxx dedicated controllers are grouped into subdirectory "hipxx"
Some of the IPs are maybe shared among the different SoCs.
I think it is better not to group by SoCs.
Otherwise looks fine to me.
Thanks!
Best Regards,
Wei
>
> Signed-off-by: Zhen Lei
> ---
> .../controller/hi3620/hisilicon,hi6220-aoctrl.txt | 18 ++
> .../hi3620/hisilicon,hi6220-mediactrl.txt | 18 ++
> .../controller/hi3620/hisilicon,hi6220-pmctrl.txt | 18 ++
> .../hi3620/hisilicon,hi6220-sramctrl.txt | 16 ++
> .../controller/hi3620/hisilicon,hi6220-sysctrl.txt | 19 ++
> .../controller/hipxx/hisilicon,hip01-sysctrl.txt | 19 ++
> .../hipxx/hisilicon,hip04-bootwrapper.txt | 9 +
> .../controller/hipxx/hisilicon,hip04-fabric.txt| 5 +
> .../arm/hisilicon/controller/hisilicon,cpuctrl.txt | 8 +
> .../hisilicon/controller/hisilicon,dsa-subctrl.txt | 15 ++
> .../controller/hisilicon,hi3798cv200-perictrl.txt | 21 ++
> .../controller/hisilicon,pcie-sas-subctrl.txt | 15 ++
> .../arm/hisilicon/controller/hisilicon,pctrl.txt | 13 +
> .../controller/hisilicon,peri-subctrl.txt | 16 ++
> .../arm/hisilicon/controller/hisilicon,sysctrl.txt | 25 ++
> .../bindings/arm/hisilicon/hisilicon.txt | 264
> +
> 16 files changed, 236 insertions(+), 263 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-aoctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-mediactrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-pmctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-sramctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-sysctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hipxx/hisilicon,hip01-sysctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hipxx/hisilicon,hip04-bootwrapper.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hipxx/hisilicon,hip04-fabric.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,cpuctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,dsa-subctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,pcie-sas-subctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,pctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,peri-subctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>
> diff --git
> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-aoctrl.txt
>
> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-aoctrl.txt
> new file mode 100644
> index 000..8f70ac0ebbdf252
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-aoctrl.txt
> @@ -0,0 +1,18 @@
> +Hisilicon Hi6220 Power Always ON domain controller
> +
> +Required properties:
> +- compatible : "hisilicon,hi6220-aoctrl"
> +- reg : Register address and size
> +- #clock-cells: should be set to 1, many clock registers are defined
> + under this controller and this property must be present.
> +
> +Hisilicon designs this system controller to control the power always
> +on domain for mobile platform.
> +
> +Example:
> + /*for Hi6220*/
> + ao_ctrl: ao_ctrl@f780 {
> + compatible = "hisilicon,hi6220-aoctrl", "syscon";
> + reg = <0x0 0xf780 0x0 0x2000>;
> + #clock-cells = <1>;
> + };
> \ No newline at end of file
> diff --git
> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-mediactrl.txt
>
> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-mediactrl.txt
> new file mode 100644
> index 000..95bf5f5c7abed7c
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3620/hisilicon,hi6220-mediactrl.txt
> @@ -0,0 +1,18 @@
> +Hisilicon Hi6220 Media domain controller
> +
> +Required properties:
> +-
Re: [PATCH v3 03/21] dt-bindings: arm: hisilicon: convert Hisilicon board/soc bindings to json-schema
Hi Zhen Lei, Thanks! On 2020/9/27 14:21, Zhen Lei wrote: > Convert Hisilicon SoC bindings to DT schema format using json-schema. > > Signed-off-by: Zhen Lei > --- > .../bindings/arm/hisilicon/hisilicon.txt | 57 > .../bindings/arm/hisilicon/hisilicon.yaml | 77 > ++ > 2 files changed, 77 insertions(+), 57 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt > create mode 100644 > Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml > > diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt > b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt > deleted file mode 100644 > index f7e52476f5f2f3c..000 > --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt > +++ /dev/null > @@ -1,57 +0,0 @@ > -Hisilicon Platforms Device Tree Bindings > - > -Hi3660 SoC > -Required root node properties: > - - compatible = "hisilicon,hi3660"; > - > -HiKey960 Board > -Required root node properties: > - - compatible = "hisilicon,hi3660-hikey960", "hisilicon,hi3660"; > - > -Hi3670 SoC > -Required root node properties: > - - compatible = "hisilicon,hi3670"; > - > -HiKey970 Board > -Required root node properties: > - - compatible = "hisilicon,hi3670-hikey970", "hisilicon,hi3670"; > - > -Hi3798cv200 SoC > -Required root node properties: > - - compatible = "hisilicon,hi3798cv200"; > - > -Hi3798cv200 Poplar Board > -Required root node properties: > - - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200"; > - > -Hi4511 Board > -Required root node properties: > - - compatible = "hisilicon,hi3620-hi4511"; > - > -Hi6220 SoC > -Required root node properties: > - - compatible = "hisilicon,hi6220"; > - > -HiKey Board > -Required root node properties: > - - compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220"; > - > -HiP01 ca9x2 Board > -Required root node properties: > - - compatible = "hisilicon,hip01-ca9x2"; > - > -HiP04 D01 Board > -Required root node properties: > - - compatible = "hisilicon,hip04-d01"; > - > -HiP05 D02 Board > -Required root node properties: > - - compatible = "hisilicon,hip05-d02"; > - > -HiP06 D03 Board > -Required root node properties: > - - compatible = "hisilicon,hip06-d03"; > - > -HiP07 D05 Board > -Required root node properties: > - - compatible = "hisilicon,hip07-d05"; > \ No newline at end of file > diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml > b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml > new file mode 100644 > index 00000000000..362decf3b85c6fb > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml > @@ -0,0 +1,77 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/hisilicon/hisilicon.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hisilicon Platforms Device Tree Bindings > + > +maintainers: > + - Wei Xu > + > +properties: > + $nodename: > +const: '/' > + > + compatible: > +oneOf: > + - description: Hi3660 SoC > +items: > + - const: hisilicon,hi3660 > + > + - description: HiKey960 Board > +items: > + - const: hisilicon,hi3660-hikey960 > + - const: hisilicon,hi3660 How about to use the boards with SoC to reduce some duplication like following? - description: Boards with the Hisilicon hi3660 SoC items: - enum: - hisilicon,hi3660-hikey960 - const: hisilicon,hi3660 And in this case, there is no need to remove the "hisilicon,hip01" as the first patch. Best Regards, Wei > + > + - description: Hi3670 SoC > +items: > + - const: hisilicon,hi3670 > + > + - description: HiKey970 Board > +items: > + - const: hisilicon,hi3670-hikey970 > + - const: hisilicon,hi3670 > + > + - description: Hi3798cv200 SoC > +items: > + - const: hisilicon,hi3798cv200 > + > + - description: Hi3798cv200 Poplar Board > +items: > + - const: hisilicon,hi3798cv200-poplar > + - const: hisilicon,hi3798cv200 > + > + - description: Hi4511
Re: [PATCH v3 4/6] arm64: dts: hisilicon: Fix SP805 clocks
Hi Andre,
On 2020/9/7 20:18, Andre Przywara wrote:
> The SP805 DT binding requires two clocks to be specified, but
> Hisilicon platform DTs currently only specify one clock.
>
> In practice, Linux would pick a clock named "apb_pclk" for the bus
> clock, and the Linux and U-Boot SP805 driver would use the first clock
> to derive the actual watchdog counter frequency.
>
> Since currently both are the very same clock, we can just double the
> clock reference, and add the correct clock-names, to match the binding.
>
> Signed-off-by: Andre Przywara
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 5 +++--
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index d25aac5e0bf8..994140fbc916 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -1089,16 +1089,18 @@
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xe8a06000 0x0 0x1000>;
> interrupts = ;
> - clocks = <_ctrl HI3660_OSC32K>;
> - clock-names = "apb_pclk";
> + clocks = <_ctrl HI3660_OSC32K>,
> + <_ctrl HI3660_OSC32K>;
> + clock-names = "wdog_clk", "apb_pclk";
> };
>
> watchdog1: watchdog@e8a07000 {
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xe8a07000 0x0 0x1000>;
> interrupts = ;
> - clocks = <_ctrl HI3660_OSC32K>;
> - clock-names = "apb_pclk";
> + clocks = <_ctrl HI3660_OSC32K>,
> + <_ctrl HI3660_OSC32K>;
> + clock-names = "wdog_clk", "apb_pclk";
> };
>
> tsensor: tsensor@fff3 {
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 3d189d9f0d24..6578f8191d71 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -843,8 +843,9 @@
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xf8005000 0x0 0x1000>;
> interrupts = ;
> - clocks = <_ctrl HI6220_WDT0_PCLK>;
> - clock-names = "apb_pclk";
> + clocks = <_ctrl HI6220_WDT0_PCLK>,
> + <_ctrl HI6220_WDT0_PCLK>;
> + clock-names = "wdog_clk", "apb_pclk";
> };
>
> tsensor: tsensor@0,f7030700 {
>
Re: [PATCH v3 1/6] ARM: dts: hisilicon: Fix SP804 users
Hi Andre,
On 2020/9/7 20:18, Andre Przywara wrote:
> The SP804 binding only specifies one or three clocks, but does not allow
> just two clocks.
> The HiSi 3620 .dtsi specified two clocks for the two timers, plus gave
> one "apb_pclk" clock-name to appease the primecell bus driver.
>
> Extend the clocks by duplicating the first clock to the end of the clock
> list, and add two dummy clock-names to make the primecell driver happy.
>
> I don't know what the real APB clock for the IP is, but with the current
> DT the first timer clock was used for that, so this change keeps the
> current status.
>
> Signed-off-by: Andre Przywara
Thanks!
Applied to the hisilicon arm32 dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/hi3620.dtsi | 30 --
> arch/arm/boot/dts/hip04.dtsi | 4 ++--
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
> index f0af1bf2b4d8..355175b25fd6 100644
> --- a/arch/arm/boot/dts/hi3620.dtsi
> +++ b/arch/arm/boot/dts/hi3620.dtsi
> @@ -111,8 +111,10 @@
> reg = <0x80 0x1000>;
> /* timer00 & timer01 */
> interrupts = <0 0 4>, <0 1 4>;
> - clocks = < HI3620_TIMER0_MUX>, <
> HI3620_TIMER1_MUX>;
> - clock-names = "apb_pclk";
> + clocks = < HI3620_TIMER0_MUX>,
> + < HI3620_TIMER1_MUX>,
> + < HI3620_TIMER0_MUX>;
> + clock-names = "timer0clk", "timer1clk", "apb_pclk";
> status = "disabled";
> };
>
> @@ -121,8 +123,10 @@
> reg = <0x801000 0x1000>;
> /* timer10 & timer11 */
> interrupts = <0 2 4>, <0 3 4>;
> - clocks = < HI3620_TIMER2_MUX>, <
> HI3620_TIMER3_MUX>;
> - clock-names = "apb_pclk";
> + clocks = < HI3620_TIMER2_MUX>,
> + < HI3620_TIMER3_MUX>,
> + < HI3620_TIMER2_MUX>;
> + clock-names = "timer0clk", "timer1clk", "apb_pclk";
> status = "disabled";
> };
>
> @@ -131,8 +135,10 @@
> reg = <0xa01000 0x1000>;
> /* timer20 & timer21 */
> interrupts = <0 4 4>, <0 5 4>;
> - clocks = < HI3620_TIMER4_MUX>, <
> HI3620_TIMER5_MUX>;
> - clock-names = "apb_pclk";
> + clocks = < HI3620_TIMER4_MUX>,
> + < HI3620_TIMER5_MUX>,
> + < HI3620_TIMER4_MUX>;
> + clock-names = "timer0lck", "timer1clk", "apb_pclk";
> status = "disabled";
> };
>
> @@ -141,8 +147,10 @@
> reg = <0xa02000 0x1000>;
> /* timer30 & timer31 */
> interrupts = <0 6 4>, <0 7 4>;
> - clocks = < HI3620_TIMER6_MUX>, <
> HI3620_TIMER7_MUX>;
> - clock-names = "apb_pclk";
> + clocks = < HI3620_TIMER6_MUX>,
> + < HI3620_TIMER7_MUX>,
> + < HI3620_TIMER6_MUX>;
> + clock-names = "timer0clk", "timer1clk", "apb_pclk";
> status = "disabled";
> };
>
> @@ -151,8 +159,10 @@
> reg = <0xa03000 0x1000>;
> /* timer40 & timer41 */
> interrupts = <0 96 4>, <0 97 4>;
> - clocks = < HI3620_TIMER8_MUX>, <
> HI3620_TIMER9_MUX>;
> - clock-names = "apb_pclk";
> + clocks = < HI3620_TIMER8_MUX>,
> + < HI3620_TIMER9_MUX>,
> + < HI3620_TIMER8_MUX>;
> + clock-names = "timer0clk", "timer1clk", "apb_pclk";
> status = "disabled";
> };
>
> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
> index 4263a9339c2e..f5871b1d1ec4 100644
> --- a/arch/arm/boot/dts/hip04.dtsi
> +++ b/arch/arm/boot/dts/hip04.dtsi
> @@ -226,8 +226,8 @@
> compatible = "arm,sp804", "arm,primecell";
> reg = <0x300 0x1000>;
> interrupts = <0 224 4>;
> - clocks = <_50m>, <_50m>;
> - clock-names = "apb_pclk";
> + clocks = <_50m>, <_50m>, <_50m>;
> + clock-names = "timer0clk", "timer1clk", "apb_pclk";
> };
>
> arm-pmu {
>
Re: [PATCH v3 6/6] ARM: dts: hisilicon: Fix SP805 clocks
On 2020/9/7 20:18, Andre Przywara wrote: > The SP805 DT binding requires two clocks to be specified, but > Hisilicon platform DTs currently only specify one clock. > > In practice, Linux would pick a clock named "apb_pclk" for the bus > clock, and the Linux and U-Boot SP805 driver would use the first clock > to derive the actual watchdog counter frequency. > > Since currently both are the very same clock, we can just double the > clock reference, and add the correct clock-names, to match the binding. > > Signed-off-by: Andre Przywara Thanks! Applied to the hisilicon arm32 dt tree. Best Regards, Wei > --- > arch/arm/boot/dts/hisi-x5hd2.dtsi | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi > b/arch/arm/boot/dts/hisi-x5hd2.dtsi > index 3ee7967c202d..e2dbf1d8a67b 100644 > --- a/arch/arm/boot/dts/hisi-x5hd2.dtsi > +++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi > @@ -370,8 +370,9 @@ > arm,primecell-periphid = <0x00141805>; > reg = <0xa2c000 0x1000>; > interrupts = <0 29 4>; > - clocks = < HIX5HD2_WDG0_RST>; > - clock-names = "apb_pclk"; > + clocks = < HIX5HD2_WDG0_RST>, > + < HIX5HD2_WDG0_RST>; > + clock-names = "wdog_clk", "apb_pclk"; > }; > }; > >
[PATCH] misc: hisi_hikey_usb: fix the uninitialized ret
The uninitialized ret in hisi_hikey_usb_parse_kirin970 is useless.
Simply remove it and return 0 on success to fix the issue reported
by Coverity Scan.
Fixes: d210a0023590 ("misc: hisi_hikey_usb: add support for Hikey 970")
Signed-off-by: Wei Xu
---
drivers/misc/hisi_hikey_usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/hisi_hikey_usb.c b/drivers/misc/hisi_hikey_usb.c
index 2ddd4072788d..5759e7209023 100644
--- a/drivers/misc/hisi_hikey_usb.c
+++ b/drivers/misc/hisi_hikey_usb.c
@@ -151,7 +151,6 @@ static int hisi_hikey_usb_parse_kirin970(struct
platform_device *pdev,
struct hisi_hikey_usb *hisi_hikey_usb)
{
struct regulator *regulator;
- int ret;
regulator = devm_regulator_get(>dev, "hub-vdd");
if (IS_ERR(regulator)) {
@@ -172,7 +171,7 @@ static int hisi_hikey_usb_parse_kirin970(struct
platform_device *pdev,
if (IS_ERR(hisi_hikey_usb->reset))
return PTR_ERR(hisi_hikey_usb->reset);
- return ret;
+ return 0;
}
static int hisi_hikey_usb_probe(struct platform_device *pdev)
--
2.8.1
Re: [PATCH 3/3] ARM: dts: add SD5203 dts
Hi Zhen,
On 2020/9/3 20:27, Zhen Lei wrote:
> From: Kefeng Wang
>
> Add sd5203.dts for Hisilicon SD5203 SoC platform.
>
> Signed-off-by: Kefeng Wang
> Signed-off-by: Zhen Lei
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/sd5203.dts | 90
> 2 files changed, 92 insertions(+)
> create mode 100644 arch/arm/boot/dts/sd5203.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4572db3fa5ae..1d1262df5c55 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -357,6 +357,8 @@ dtb-$(CONFIG_ARCH_MPS2) += \
> mps2-an399.dtb
> dtb-$(CONFIG_ARCH_MOXART) += \
> moxart-uc7112lx.dtb
> +dtb-$(CONFIG_ARCH_SD5203) += \
> + sd5203.dtb
> dtb-$(CONFIG_SOC_IMX1) += \
> imx1-ads.dtb \
> imx1-apf9328.dtb
> diff --git a/arch/arm/boot/dts/sd5203.dts b/arch/arm/boot/dts/sd5203.dts
> new file mode 100644
> index ..99da46072f72
> --- /dev/null
> +++ b/arch/arm/boot/dts/sd5203.dts
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2020 Hisilicon Limited.
> + *
> + * DTS file for Hisilicon SD5203 Board
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "Hisilicon SD5203";
> + compatible = "hisilicon,sd5203";
Can you please add the binding document as well?
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs="console=ttyS0,9600
> earlycon=uart8250,mmio32,0x1600d000";
> + };
> +
> + aliases {
> + serial0 =
> + };
> +
> + cpu {
> + compatible = "arm,arm926ej-s";
> + device_type = "cpu";
> + };
> +
> + memory@3000 {
> + device_type = "memory";
> + reg = <0x3000 0x800>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges;
> +
> + vic: interrupt-controller@1013 {
> + compatible = "hisilicon,sd5203-vic";
Ditto.
Thanks!
Best Regards,
Wei
> + reg = <0x1013 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + refclk125mhz: refclk125mhz {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12500>;
> + };
> +
> + timer0: timer@16002000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x16002000 0x1000>;
> + interrupts = <4>;
> + clocks = <>;
> + clock-names = "apb_pclk";
> + };
> +
> + timer1: timer@16003000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x16003000 0x1000>;
> + interrupts = <5>;
> + clocks = <>;
> + clock-names = "apb_pclk";
> + };
> +
> + uart0: serial@1600D000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x1600D000 0x1000>;
> + bus_id = "uart0";
> + clocks = <>;
> + clock-names = "apb_pclk";
> + reg-shift = <2>;
> + interrupts = <17>;
> + };
> +
> + uart1: serial@1600C000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x1600C000 0x1000>;
> + clocks = <>;
> + clock-names = "apb_pclk";
> + reg-shift = <2>;
> + interrupts = <16>;
> + status = "disabled";
> + };
> + };
> +};
>
[net-next] net: iavf: Use the ARRAY_SIZE macro for aq_to_posix
Use the ARRAY_SIZE macro to calculate the size of an array. This code was detected with the help of Coccinelle. Signed-off-by: Wei Xu --- drivers/net/ethernet/intel/iavf/iavf_adminq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.h b/drivers/net/ethernet/intel/iavf/iavf_adminq.h index baf2fe2..eead12c 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_adminq.h +++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.h @@ -120,7 +120,7 @@ static inline int iavf_aq_rc_to_posix(int aq_ret, int aq_rc) if (aq_ret == IAVF_ERR_ADMIN_QUEUE_TIMEOUT) return -EAGAIN; - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0] + if (!((u32)aq_rc < ARRAY_SIZE(aq_to_posix))) return -ERANGE; return aq_to_posix[aq_rc]; -- 2.8.1
[net-next] net: i40e: Use the ARRAY_SIZE macro for aq_to_posix
Use the ARRAY_SIZE macro to calculate the size of an array. This code was detected with the help of Coccinelle. Signed-off-by: Wei Xu --- drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h b/drivers/net/ethernet/intel/i40e/i40e_adminq.h index edec3df..11c5fca 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h @@ -120,7 +120,7 @@ static inline int i40e_aq_rc_to_posix(int aq_ret, int aq_rc) if (aq_ret == I40E_ERR_ADMIN_QUEUE_TIMEOUT) return -EAGAIN; - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0] + if (!((u32)aq_rc < ARRAY_SIZE(aq_to_posix))) return -ERANGE; return aq_to_posix[aq_rc]; -- 2.8.1
[net-next] net: smsc911x: Remove unused variables
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_rx_fastforward’:
drivers/net/ethernet/smsc/smsc911x.c:1199:16: warning: variable ‘temp’ set but
not used [-Wunused-but-set-variable]
drivers/net/ethernet/smsc/smsc911x.c: In function
‘smsc911x_eeprom_write_location’:
drivers/net/ethernet/smsc/smsc911x.c:2058:6: warning: variable ‘temp’ set but
not used [-Wunused-but-set-variable]
Signed-off-by: Wei Xu
---
drivers/net/ethernet/smsc/smsc911x.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index fc168f8..823d9a7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1196,9 +1196,8 @@ smsc911x_rx_fastforward(struct smsc911x_data *pdata,
unsigned int pktwords)
SMSC_WARN(pdata, hw, "Timed out waiting for "
"RX FFWD to finish, RX_DP_CTRL: 0x%08X", val);
} else {
- unsigned int temp;
while (pktwords--)
- temp = smsc911x_reg_read(pdata, RX_DATA_FIFO);
+ smsc911x_reg_read(pdata, RX_DATA_FIFO);
}
}
@@ -2055,7 +2054,6 @@ static int smsc911x_eeprom_write_location(struct
smsc911x_data *pdata,
u8 address, u8 data)
{
u32 op = E2P_CMD_EPC_CMD_ERASE_ | address;
- u32 temp;
int ret;
SMSC_TRACE(pdata, drv, "address 0x%x, data 0x%x", address, data);
@@ -2066,7 +2064,7 @@ static int smsc911x_eeprom_write_location(struct
smsc911x_data *pdata,
smsc911x_reg_write(pdata, E2P_DATA, (u32)data);
/* Workaround for hardware read-after-write restriction */
- temp = smsc911x_reg_read(pdata, BYTE_TEST);
+ smsc911x_reg_read(pdata, BYTE_TEST);
ret = smsc911x_eeprom_send_cmd(pdata, op);
}
--
2.8.1
Re: [PATCH] PCI: exynos: simplify with PTR_ERR_OR_ZERO
Hi All, Sorry for the noise and please ignore it. I found these kind of changes have been sent and rejected before. Best Regards, Wei On 2020/9/3 17:05, Wei Xu wrote: > Use PTR_ERR_OR_ZERO to make the code a little bit simpler. > This code was detected with the help of Coccinelle. > > Signed-off-by: Wei Xu > --- > drivers/pci/controller/dwc/pci-exynos.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pci-exynos.c > b/drivers/pci/controller/dwc/pci-exynos.c > index 8d82c43..f59f027 100644 > --- a/drivers/pci/controller/dwc/pci-exynos.c > +++ b/drivers/pci/controller/dwc/pci-exynos.c > @@ -90,10 +90,7 @@ static int exynos5440_pcie_get_mem_resources(struct > platform_device *pdev, > return -ENOMEM; > > ep->mem_res->elbi_base = devm_platform_ioremap_resource(pdev, 0); > - if (IS_ERR(ep->mem_res->elbi_base)) > - return PTR_ERR(ep->mem_res->elbi_base); > - > - return 0; > + return PTR_ERR_OR_ZERO(ep->mem_res->elbi_base); > } > > static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep) >
Re: [PATCH] net/mlx5e: kTLS, Fix GFP_KERNEL in spinlock context
Hi All,
Sorry for the noise and please ignore it!
I found a nearly same patch has been sent out 2 days before.
Best Regards,
Wei
On 2020/9/3 19:45, Wei Xu wrote:
> Replace GFP_KERNEL with GFP_ATOMIC while resync_post_get_progress_params
> is invoked in a spinlock context.
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Wei Xu
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> index acf6d80..1a32435 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> @@ -247,7 +247,7 @@ resync_post_get_progress_params(struct mlx5e_icosq *sq,
> int err;
> u16 pi;
>
> - buf = kzalloc(sizeof(*buf), GFP_KERNEL);
> + buf = kzalloc(sizeof(*buf), GFP_ATOMIC);
> if (unlikely(!buf)) {
> err = -ENOMEM;
> goto err_out;
>
[PATCH] net/mlx5e: kTLS, Fix GFP_KERNEL in spinlock context
Replace GFP_KERNEL with GFP_ATOMIC while resync_post_get_progress_params
is invoked in a spinlock context.
This code was detected with the help of Coccinelle.
Signed-off-by: Wei Xu
---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index acf6d80..1a32435 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -247,7 +247,7 @@ resync_post_get_progress_params(struct mlx5e_icosq *sq,
int err;
u16 pi;
- buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ buf = kzalloc(sizeof(*buf), GFP_ATOMIC);
if (unlikely(!buf)) {
err = -ENOMEM;
goto err_out;
--
2.8.1
[PATCH] PCI: exynos: simplify with PTR_ERR_OR_ZERO
Use PTR_ERR_OR_ZERO to make the code a little bit simpler. This code was detected with the help of Coccinelle. Signed-off-by: Wei Xu --- drivers/pci/controller/dwc/pci-exynos.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c index 8d82c43..f59f027 100644 --- a/drivers/pci/controller/dwc/pci-exynos.c +++ b/drivers/pci/controller/dwc/pci-exynos.c @@ -90,10 +90,7 @@ static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev, return -ENOMEM; ep->mem_res->elbi_base = devm_platform_ioremap_resource(pdev, 0); - if (IS_ERR(ep->mem_res->elbi_base)) - return PTR_ERR(ep->mem_res->elbi_base); - - return 0; + return PTR_ERR_OR_ZERO(ep->mem_res->elbi_base); } static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep) -- 2.8.1
Re: [PATCH] ARM: dts: hisilicon: Align L2 cache-controller nodename with dtschema
Hi Krzysztof,
On 2020/6/26 16:06, Krzysztof Kozlowski wrote:
> Fix dtschema validator warnings like:
> l2-cache: $nodename:0: 'l2-cache' does not match
> '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
>
> Signed-off-by: Krzysztof Kozlowski
Thanks!
Applied to the hisilicon arm32 dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/hi3620.dtsi | 2 +-
> arch/arm/boot/dts/hisi-x5hd2.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
> index 9c207a690df5..f0af1bf2b4d8 100644
> --- a/arch/arm/boot/dts/hi3620.dtsi
> +++ b/arch/arm/boot/dts/hi3620.dtsi
> @@ -71,7 +71,7 @@
> interrupt-parent = <>;
> ranges = <0 0xfc00 0x200>;
>
> - L2: l2-cache {
> + L2: cache-controller {
> compatible = "arm,pl310-cache";
> reg = <0x10 0x10>;
> interrupts = <0 15 4>;
> diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> index 696e6982a688..3ee7967c202d 100644
> --- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> +++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> @@ -381,7 +381,7 @@
> interrupts = <1 13 0xf01>;
> };
>
> - l2: l2-cache {
> + l2: cache-controller {
> compatible = "arm,pl310-cache";
> reg = <0x00a1 0x10>;
> interrupts = <0 15 4>;
>
Re: [PATCH 1/2] arm64: dts: hisilicon: Use phandles for overriding nodes in hi6220
Hi Krzysztof
On 2020/6/29 16:16, Krzysztof Kozlowski wrote:
> When overriding nodes, usage of phandles instead of full paths reduces
> possible mistakes (e.g. in duplicated unit address) and removes
> duplicate data. The UART nodes were extended via full path and phandle
> which makes it difficult to review and spot actual differences.
>
> No functional change (no difference in dtx_diff).
>
> Signed-off-by: Krzysztof Kozlowski
Thanks!
Series applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> .../arm64/boot/dts/hisilicon/hi6220-hikey.dts | 426 +-
> 1 file changed, 210 insertions(+), 216 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index c14205cd6bf5..a41e0db8e71b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -122,222 +122,6 @@
> power-off-delay-us = <10>;
> };
>
> - soc {
> - spi0: spi@f7106000 {
> - status = "ok";
> - };
> -
> - i2c0: i2c@f710 {
> - status = "ok";
> - };
> -
> - i2c1: i2c@f7101000 {
> - status = "ok";
> - };
> -
> - uart1: uart@f7111000 {
> - assigned-clocks = <_ctrl HI6220_UART1_SRC>;
> - assigned-clock-rates = <15000>;
> - status = "ok";
> -
> - bluetooth {
> - compatible = "ti,wl1835-st";
> - enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
> - clocks = <>;
> - clock-names = "ext_clock";
> - };
> - };
> -
> - uart2: uart@f7112000 {
> - status = "ok";
> - };
> -
> - uart3: uart@f7113000 {
> - status = "ok";
> - };
> -
> - /*
> - * Legend: proper name = the GPIO line is used as GPIO
> - * NC = not connected (not routed from the SoC)
> - * "[PER]" = pin is muxed for peripheral (not GPIO)
> - * "" = no idea, schematic doesn't say, could be
> - * unrouted (not connected to any external pin)
> - * LSEC = Low Speed External Connector
> - * HSEC = High Speed External Connector
> - *
> - * Pin assignments taken from LeMaker and CircuitCo Schematics
> - * Rev A1.
> - *
> - * For the lines routed to the external connectors the
> - * lines are named after the 96Boards CE Specification 1.0,
> - * Appendix "Expansion Connector Signal Description".
> - *
> - * When the 96Board naming of a line and the schematic name of
> - * the same line are in conflict, the 96Board specification
> - * takes precedence, which means that the external UART on the
> - * LSEC is named UART0 while the schematic and SoC names this
> - * UART2. This is only for the informational lines i.e. "[FOO]",
> - * the GPIO named lines "GPIO-A" thru "GPIO-L" are the only
> - * ones actually used for GPIO.
> - */
> - gpio0: gpio@f8011000 {
> - gpio-line-names = "PWR_HOLD", "DSI_SEL",
> - "USB_HUB_RESET_N", "USB_SEL", "HDMI_PD", "WL_REG_ON",
> - "PWRON_DET", "5V_HUB_EN";
> - };
> -
> - gpio1: gpio@f8012000 {
> - gpio-line-names = "SD_DET", "HDMI_INT", "PMU_IRQ_N",
> - "WL_HOST_WAKE", "NC", "NC", "NC", "BT_REG_ON";
> - };
> -
> - gpio2: gpio@f8013000 {
> - gpio-line-names =
> - "GPIO-A", /* LSEC Pin 23: GPIO2_0 */
> - "GPIO-B", /* LSEC Pin 24: GPIO2_1 */
> - "GPIO-C", /* LSEC Pin 25: GPIO2_2 */
> - "GPIO-D", /* LSEC Pin 26: GPIO2_3 */
> - "GPIO-E", /* LSEC Pin 27: GPIO2_4 */
> - "USB_ID_DET", "USB_VBUS_DET",
> - "GPIO-H"; /* LSEC Pin 30: GPIO2_7 */
> - };
> -
> - gpio3: gpio@f8014000 {
> - gpio-line-names = "GPIO3_0", "NC", "NC", "", "NC", "",
> - "WLAN_ACTIVE", "NC", "NC";
> - };
> -
> - gpio4: gpio@f702 {
> - gpio-line-names = "USER_LED1", "USER_LED2", "USER_LED3",
> - "USER_LED4", "SD_SEL", "NC", "NC", "BT_ACTIVE";
> - };
> -
> - gpio5: gpio@f7021000 {
> -
Re: [RESEND][PATCH] dts: hi3660: Add support for basic usb gadget on Hikey960
Hi John,
On 2020/7/21 9:25, John Stultz wrote:
> This patch adds basic core dwc3, usb phy and rt1711h nodes for
> usb support on Hikey960.
>
> This does not enable the mux/hub functionality on the board, so
> the USB-A host ports will not function, but does allow the USB-C
> port to function in gadget mode (unfortunately not in host, as
> the hub/mux functionality is needed to enable vbus output to
> power devices in host mode).
>
> This is based on an old patch originally by Yu Chen.
>
> Cc: Yu Chen
> Cc: Chunfeng Yun
> Cc: Wei Xu
> Cc: Binghui Wang
> Cc: YongQin Liu
> Cc: Rob Herring
> Cc: Matthias Brugger
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> .../boot/dts/hisilicon/hi3660-hikey960.dts| 72 +++
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 34 +
> 2 files changed, 106 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index e035cf195b19..ff392a47562c 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> model = "HiKey960";
> @@ -526,6 +527,48 @@
> {
> status = "okay";
>
> + rt1711h: rt1711h@4e {
> + compatible = "richtek,rt1711h";
> + reg = <0x4e>;
> + status = "ok";
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_cfg_func>;
> +
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + data-role = "dual";
> + power-role = "dual";
> + try-power-role = "sink";
> + source-pdos = PDO_FIXED_USB_COMM)>;
> + sink-pdos = + PDO_VAR(5000, 5000, 1000)>;
> + op-sink-microwatt = <1000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@1 {
> + reg = <1>;
> + usb_con_ss: endpoint {
> + remote-endpoint = <_ss>;
> + };
> + };
> + };
> + };
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rt1711h_ep: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_role_switch>;
> + };
> + };
> + };
> +
> adv7533: adv7533@39 {
> status = "ok";
> compatible = "adi,adv7533";
> @@ -612,3 +655,32 @@
> interrupts = <3 IRQ_TYPE_EDGE_RISING>;
> };
> };
> +
> + { /* USB */
> + dr_mode = "otg";
> + maximum-speed = "super-speed";
> + phy_type = "utmi";
> + snps,dis-del-phy-power-chg-quirk;
> + snps,lfps_filter_quirk;
> + snps,dis_u2_susphy_quirk;
> + snps,dis_u3_susphy_quirk;
> + snps,tx_de_emphasis_quirk;
> + snps,tx_de_emphasis = <1>;
> + snps,dis_enblslpm_quirk;
> + snps,gctl-reset-quirk;
> + usb-role-switch;
> + role-switch-default-mode = "host";
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dwc3_role_switch: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_ep>;
> + };
> +
> + dwc3_ss: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_con_ss>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index c39b78989ff9..d25aac5e0bf8 100644
> --- a
Re: [PATCH v2 0/3] io.h, logic_pio: Allow barriers for inX() and outX() be overridden
Hi John,
On 2020/3/28 0:06, John Garry wrote:
> Since commits a7851aa54c0c ("io: change outX() to have their own IO
> barrier overrides") and 87fe2d543f81 ("io: change inX() to have their own
> IO barrier overrides"), the outX() and inX() functions have memory
> barriers which can be overridden per-arch.
>
> However, under CONFIG_INDIRECT_PIO, logic_pio defines its own version of
> inX() and outX(), which still use readb et al. For these, the barrier
> after a raw read is weaker than it otherwise would be.
>
> This series generates consistent behaviour for logic_pio, by defining
> generic _inX() and _outX() in asm-generic/io.h, and using those in
> logic_pio. Generic _inX() and _outX() have per-arch overrideable
> barriers.
>
> The topic was discussed there originally:
> https://lore.kernel.org/lkml/2e80d7bc-32a0-cc40-00a9-8a383a196...@huawei.com/
>
> A small tidy-up patch is included.
>
> I hope that series can go through the arm-soc tree, as with other recent
> logic_pio changes.
>
> Hi Arnd,
>
> I added your tag, but please let me know if you have any issue with the
> updated change in patch #1.
>
> cheers
>
> - Differences to v1
> - fix x86 clang build by adding extra build swicth for _{in,out}X
> - added Arnd's RB tag
>
> John Garry (3):
> io: Provide _inX() and _outX()
> logic_pio: Improve macro argument name
> logic_pio: Use _inX() and _outX()
>
> include/asm-generic/io.h | 64
> +---
> lib/logic_pio.c | 22 -
> 2 files changed, 55 insertions(+), 31 deletions(-)
>
Thanks!
Series applied to the hisilicon SoC tree.
Best Regards,
Wei
Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
Hi Linus, On 2019/8/20 16:01, Linus Walleij wrote: On Mon, Aug 19, 2019 at 3:29 PM Wei Xu wrote: Invoke acpi_gpiochip_request_interrupts after the acpi data has been attached to the pl061 acpi node to register interruption. Otherwise it will be failed to register interruption for the ACPI case. Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked after gpiochip_add_irqchip but at that time the acpi data has not been attached yet. We need to fix this problem in gpiochip_add_data_with_key() instead. Thanks! Best Regards, Wei Yours, Linus Walleij ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps:
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x900"
The pl061 interruption is missed and the following output is not in the
/proc/interrupts on the v5.3-rc4 compared with the v5.2.0-rc7.
43: 0 ARMH0061:00 3 Edge ACPI:Event
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu
---
v2 -> v3:
* addressed the comments of Andy to show only affected output of
/proc/interrupts and drop the whole log of v5.2.0-rc7
v1- > v2:
* rebased on
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
drivers/gpio/gpio-pl061.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include
#include
#include
#include
@@ -24,6 +25,9 @@
#include
#include
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const
struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(>gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.1
Re: [PATCH v2] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
Hi Andy, Thanks! On 2019/8/16 21:40, Andy Shevchenko wrote: On Fri, Aug 16, 2019 at 12:07 PM Wei Xu wrote: Invoke acpi_gpiochip_request_interrupts after the acpi data has been attached to the pl061 acpi node to register interruption. Otherwise it will be failed to register interruption for the ACPI case. Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked after gpiochip_add_irqchip but at that time the acpi data has not been attached yet. 2. cat /proc/interrupts in the guest console: estuary:/$ cat /proc/interrupts CPU0 2: 3228 GICv3 27 Level arch_timer 4: 15 GICv3 33 Level uart-pl011 42: 0 GICv3 23 Level arm-pmu IPI0: 0 Rescheduling interrupts IPI1: 0 Function call interrupts IPI2: 0 CPU stop interrupts IPI3: 0 CPU stop (for crash dump) interrupts IPI4: 0 Timer broadcast interrupts IPI5: 0 IRQ work interrupts IPI6: 0 CPU wake-up interrupts Err: 0 But on QEMU v3.0.0 and Linux kernel v5.2.0-rc7, pl061 interruption is there as below: estuary:/$ cat /proc/interrupts CPU0 2: 2648 GICv3 27 Level arch_timer 4: 12 GICv3 33 Level uart-pl011 42: 0 GICv3 23 Level arm-pmu 43: 0 ARMH0061:00 3 Edge ACPI:Event IPI0: 0 Rescheduling interrupts IPI1: 0 Function call interrupts IPI2: 0 CPU stop interrupts IPI3: 0 CPU stop (for crash dump) interrupts IPI4: 0 Timer broadcast interrupts IPI5: 0 IRQ work interrupts IPI6: 0 CPU wake-up interrupts Err: 0 In above show only affected line. OK. Will update it in v3. And the whole dmesg log on Linux kernel v5.2.0-rc7 is as below: NO! Please, remove this huge noise! Sorry for the noise! I will drop it in v3. Best Regards, Wei
[PATCH v2] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
soundcards found.
[8.478229] Freeing unused kernel memory: 1344K
[8.480677] Run /init as init process
[9.767007] random: sshd: uninitialized urandom read (32 bytes read)
estuary:/$
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu
---
v1- > v2:
* rebased on
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
drivers/gpio/gpio-pl061.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include
#include
#include
#include
@@ -24,6 +25,9 @@
#include
#include
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const
struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(>gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.1
Re: [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
Hi Linus,
On 2019/8/14 17:04, Linus Walleij wrote:
Hi Wei,
thanks for your patch!
This doesn't apply for my "devel" branch, can you rebase
on this:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
We have moved some ACPI headers around recently.
Thanks to review!
I just sent out the v2 based on that.
On Mon, Aug 12, 2019 at 1:28 PM Wei Xu wrote:
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Makes sense.
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
I doubt this is a regression since I haven't seen anyone use this
gpiochip with ACPI before.
Please rename the patch "gpio: pl061: Add ACPI support" unless
you can convince me it worked without changes before.
In the v2, I attached the log on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
and
the pl061 driver can register ACPI interruption.
Based on that, I did not rename the patch but I am OK to rename it if
you have
any doubt.
Please include some ACPI people on review of this. From
MAINTAINERS:
ACPI
M: "Rafael J. Wysocki"
M: Len Brown
L: linux-a...@vger.kernel.org
I would also include Andy Shevchenko and Mika Westerberg for
the GPIO aspects.
Copied to all of them in the v2.
Thanks!
Best Regards,
Wei
Thanks!
Linus Walleij
.
[GIT PULL] Hisilicon fixes for v5.3
Hi ARM-SoC team, Please consider to pull the following fixes. Thanks! Best Regards, Wei --- The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://github.com/hisilicon/linux-hisi.git tags/hisi-fixes-for-5.3 for you to fetch changes up to 10e62b47973b0b0ceda076255bcb147b83e20517: bus: hisi_lpc: Add .remove method to avoid driver unbind crash (2019-08-13 14:54:34 +0800) Hisilicon fixes for v5.3-rc - Fixed RCU usage in logical PIO - Added a function to unregister a logical PIO range in logical PIO to support the fixes in the hisi-lpc driver - Fixed and optimized hisi-lpc driver to avoid potential use-after-free and driver unbind crash John Garry (5): lib: logic_pio: Fix RCU usage lib: logic_pio: Avoid possible overlap for unregistering regions lib: logic_pio: Add logic_pio_unregister_range() bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free bus: hisi_lpc: Add .remove method to avoid driver unbind crash drivers/bus/hisi_lpc.c| 47 ++ include/linux/logic_pio.h | 1 + lib/logic_pio.c | 73 +++ 3 files changed, 96 insertions(+), 25 deletions(-)
Re: [PATCH v4 0/5] Fixes for HiSilicon LPC driver and logical PIO code
Hi John, On 2019/7/30 21:29, John Garry wrote: As reported in [1], the hisi-lpc driver has certain issues in handling logical PIO regions, specifically unregistering regions. This series add a method to unregister a logical PIO region, and fixes up the driver to use them. RCU usage in logical PIO code looks to always have been broken, so that is fixed also. This is not a major fix as the list which RCU protects would be rarely modified. At this point, there are still separate ongoing discussions about how to stop the logical PIO and PCI host bridge code leaking ranges, as in [2], which I haven't had a chance to look at recently. Hopefully this series can go through the arm soc tree and the maintainers have no issue with that. I'm talking specifically about the logical PIO code, which went through PCI tree on only previous upstreaming. [1] https://lore.kernel.org/lkml/1560770148-57960-1-git-send-email-john.ga...@huawei.com/ [2] https://lore.kernel.org/lkml/4b24fd36-e716-7c5e-31cc-13da72780...@huawei.com/ Thanks! Series applied to the hisilicon fixes tree. Best Regards, Wei Changes since v3: https://lore.kernel.org/lkml/1561566418-22714-1-git-send-email-john.ga...@huawei.com/ - drop optimisation patch (lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at registration) Not a fix - rebase to v5.3-rc2 - cc stable Change since v2: - Add hisi_lpc_acpi_remove() stub to fix build for !CONFIG_ACPI Changes since v1: - Add more reasoning in RCU fix patch - Create separate patch to change LOGIC_PIO_CPU_MMIO registration to accomodate unregistration John Garry (5): lib: logic_pio: Fix RCU usage lib: logic_pio: Avoid possible overlap for unregistering regions lib: logic_pio: Add logic_pio_unregister_range() bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free bus: hisi_lpc: Add .remove method to avoid driver unbind crash drivers/bus/hisi_lpc.c| 47 + include/linux/logic_pio.h | 1 + lib/logic_pio.c | 73 +-- 3 files changed, 96 insertions(+), 25 deletions(-)
[PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
and found pl061 interruption is missed in the /proc/interrupts:
1.
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x900"
2. cat /proc/interrupts in the guest console:
estuary:/$ cat /proc/interrupts
CPU0
2: 3228 GICv3 27 Level arch_timer
4: 15 GICv3 33 Level uart-pl011
42: 0 GICv3 23 Level arm-pmu
IPI0: 0 Rescheduling interrupts
IPI1: 0 Function call interrupts
IPI2: 0 CPU stop interrupts
IPI3: 0 CPU stop (for crash dump) interrupts
IPI4: 0 Timer broadcast interrupts
IPI5: 0 IRQ work interrupts
IPI6: 0 CPU wake-up interrupts
Err: 0
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu
---
drivers/gpio/gpio-pl061.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include
#include
#include
#include
@@ -24,6 +25,9 @@
#include
#include
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev,
const struct amba_id *id)
if (ret)
return ret;
+if (has_acpi_companion(dev))
+acpi_gpiochip_request_interrupts(>gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.1
.
Re: [GIT PULL] Hisilicon fixes for v5.2
Hi Olof, On 2019/6/27 10:19, Olof Johansson wrote: On Tue, Jun 25, 2019 at 02:31:26PM +0100, John Garry wrote: On 25/06/2019 14:03, Olof Johansson wrote: are available in the Git repository at: git://github.com/hisilicon/linux-hisi.git tags/hisi-fixes-for-5.2 for you to fetch changes up to 07c811af1c00d7b4212eac86900b023b6405a954: lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at registration (2019-06-25 09:40:42 +0100) Hisilicon fixes for v5.2-rc - fixed RCU usage in logical PIO - Added a function to unregister a logical PIO range in logical PIO to support the fixes in the hisi-lpc driver - fixed and optimized hisi-lpc driver to avoid potential use-after-free and driver unbind crash Merged to fixes, thanks. This broke arm64 allmodconfig: arm64.allmodconfig: drivers/bus/hisi_lpc.c:656:3: error: implicit declaration of function 'hisi_lpc_acpi_remove'; did you mean 'hisi_lpc_acpi_probe'? [-Werror=implicit-function-declaration] Uhhh, that's my fault - I didn't provide a stub for !ACPI. Sorry. I'll send a fixed v3 series. No worries, it happens -- but it's good if maintainers do at least a few test builds before sending in pull requests so we don't catch all of it at our end. Sorry for the late reply! I had a trip last week and did the pull request in a hurry that forgot to do the some building test like allmodconfig, allyesconfig and so on. In the future, I will do more testing before sending out to avoid this kind fault. Best Regards, Wei -Olof .
Re: [GIT PULL] Hisilicon fixes for v5.2
Hi ARM-SoC team, Sorry, I forgot to mention that one or two patches in this patch set are not pure fix. We are also OK to queue for v5.3. Thanks! Best Regards, Wei On 6/25/2019 11:23 AM, Wei Xu wrote: > Hi ARM-SoC team, > > Please consider to pull the following changes. > Thanks! > > Best Regards, > Wei > > --- > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://github.com/hisilicon/linux-hisi.git tags/hisi-fixes-for-5.2 > > for you to fetch changes up to 07c811af1c00d7b4212eac86900b023b6405a954: > > lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at > registration (2019-06-25 09:40:42 +0100) > > > Hisilicon fixes for v5.2-rc > > - fixed RCU usage in logical PIO > - Added a function to unregister a logical PIO range in logical PIO > to support the fixes in the hisi-lpc driver > - fixed and optimized hisi-lpc driver to avoid potential use-after-free > and driver unbind crash > > > John Garry (6): > lib: logic_pio: Fix RCU usage > lib: logic_pio: Avoid possible overlap for unregistering regions > lib: logic_pio: Add logic_pio_unregister_range() > bus: hisi_lpc: Unregister logical PIO range to avoid potential > use-after-free > bus: hisi_lpc: Add .remove method to avoid driver unbind crash > lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at > registration > > drivers/bus/hisi_lpc.c| 43 > include/linux/logic_pio.h | 1 + > lib/logic_pio.c | 86 > +-- > 3 files changed, 99 insertions(+), 31 deletions(-) >
[GIT PULL] Hisilicon fixes for v5.2
Hi ARM-SoC team, Please consider to pull the following changes. Thanks! Best Regards, Wei --- The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://github.com/hisilicon/linux-hisi.git tags/hisi-fixes-for-5.2 for you to fetch changes up to 07c811af1c00d7b4212eac86900b023b6405a954: lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at registration (2019-06-25 09:40:42 +0100) Hisilicon fixes for v5.2-rc - fixed RCU usage in logical PIO - Added a function to unregister a logical PIO range in logical PIO to support the fixes in the hisi-lpc driver - fixed and optimized hisi-lpc driver to avoid potential use-after-free and driver unbind crash John Garry (6): lib: logic_pio: Fix RCU usage lib: logic_pio: Avoid possible overlap for unregistering regions lib: logic_pio: Add logic_pio_unregister_range() bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free bus: hisi_lpc: Add .remove method to avoid driver unbind crash lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at registration drivers/bus/hisi_lpc.c| 43 include/linux/logic_pio.h | 1 + lib/logic_pio.c | 86 +-- 3 files changed, 99 insertions(+), 31 deletions(-)
Re: [PATCH v2 0/6] Fixes for HiSilicon LPC driver and logical PIO code
Hi John, On 6/24/2019 3:35 PM, John Garry wrote: > As reported in [1], the hisi-lpc driver has certain issues in handling > logical PIO regions, specifically unregistering regions. > > This series add a method to unregister a logical PIO region, and fixes up > the driver to use them. > > RCU usage in logical PIO code looks to always have been broken, so that > is fixed also. This is not a major fix as the list which RCU protects > would be rarely modified. > > There is another patch to simplify logical PIO registration, made possible > by the fixes. > > At this point, there are still separate ongoing discussions about how to > stop the logical PIO and PCI host bridge code leaking ranges, as in [2]. > > Hopefully this series can go through the arm soc tree and the maintainers > have no issue with that. I'm talking specifically about the logical PIO > code, which went through PCI tree on only previous upstreaming. Thanks! Series applied to the hisilicon fix tree. But I am not sure it is proper for me to apply and send the pull request for this patch set. I will give it a try. Best Regards, Wei > > Cc. linux-...@vger.kernel.org > > [1] > https://lore.kernel.org/lkml/1560770148-57960-1-git-send-email-john.ga...@huawei.com/ > [2] > https://lore.kernel.org/lkml/4b24fd36-e716-7c5e-31cc-13da72780...@huawei.com/ > > Changes since v1: > - Add more reasoning in RCU fix patch > - Create separate patch to change LOGIC_PIO_CPU_MMIO registration to > accomodate unregistration > > John Garry (6): > lib: logic_pio: Fix RCU usage > lib: logic_pio: Avoid possible overlap for unregistering regions > lib: logic_pio: Add logic_pio_unregister_range() > bus: hisi_lpc: Unregister logical PIO range to avoid potential > use-after-free > bus: hisi_lpc: Add .remove method to avoid driver unbind crash > lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at > registration > > drivers/bus/hisi_lpc.c| 43 +--- > include/linux/logic_pio.h | 1 + > lib/logic_pio.c | 86 +++ > 3 files changed, 99 insertions(+), 31 deletions(-) >
Re: [PATCH 6/6] ARM: hisilicon: DT: Switch to SPDX header
Hi Lubomir,
On 6/11/2019 8:29 AM, Lubomir Rintel wrote:
> The original license text had a typo ("publishhed") which would be
> likely to confuse automated licensing auditing tools. Let's just switch
> to SPDX instead of fixing the wording.
>
> Signed-off-by: Lubomir Rintel
Thanks!
I found linux-next has already fix this.
Best Regards,
Wei
Re: [PATCH] arm64: dts: hisilicon: Switch to SPDX header
Hi Lubomir,
On 6/11/2019 8:20 AM, Lubomir Rintel wrote:
> The original license text had a typo ("publishhed") which would be
> likely to confuse automated licensing auditing tools. Let's just switch
> to SPDX instead of fixing the wording.
>
> Signed-off-by: Lubomir Rintel
Thanks!
I found linux-next has already fix this.
Best Regards,
Wei
Re: [PATCH v4] arm64: dts: hi3660: Add CoreSight support
Hi Leo, Wanglai On 5/16/2019 5:11 AM, Leo Yan wrote: > On Sat, Apr 20, 2019 at 10:00:35PM +0800, Wanglai Shi wrote: >> This patch adds DT bindings for the CoreSight trace components >> on hi3660, which is used by 96boards Hikey960. >> >> Signed-off-by: Wanglai Shi > > Hi Wei, > > Mathieu and me both have reviewed this patch, could you pick up this > patch? Thanks a lot! Applied to the hisilicon dt tree. Thanks! Best Regards, Wei
Re: [PATCH v2 01/11] ARM: dts: hip04: Update coresight DT bindings
Hi Leo, On 5/8/2019 3:18 AM, Leo Yan wrote: > CoreSight DT bindings have been updated, thus the old compatible strings > are obsolete and the drivers will report warning if DTS uses these > obsolete strings. > > This patch switches to the new bindings for CoreSight dynamic funnel and > static replicator, so can dismiss warning during initialisation. > > Cc: Wei Xu > Cc: Guodong Xu > Cc: Zhangfei Gao > Cc: Haojian Zhuang > Cc: Mathieu Poirier > Cc: Suzuki K Poulose > Signed-off-by: Leo Yan Applied to the hisilicon dt tree. Thanks! Best Regards, Wei
Re: [PATCH v2 07/11] arm64: dts: hi6220: Update coresight DT bindings
Hi Leo, On 5/8/2019 3:18 AM, Leo Yan wrote: > CoreSight DT bindings have been updated, thus the old compatible strings > are obsolete and the drivers will report warning if DTS uses these > obsolete strings. > > This patch switches to the new bindings for CoreSight dynamic funnel and > static replicator, so can dismiss warning during initialisation. > > Cc: Wei Xu > Cc: Guodong Xu > Cc: Zhangfei Gao > Cc: Haojian Zhuang > Cc: Mathieu Poirier > Cc: Suzuki K Poulose > Signed-off-by: Leo Yan Applied to the hisilicon dt tree. Thanks! Best Regards, Wei
Re: [RESEND][PATCH 0/3] DMA dts changes for hi3660
Hi John, On 4/4/2019 9:16 AM, John Stultz wrote: > Here are a few dts changes which didn't get picked up > for the last merge window to enable support for code > changes that did land in v5.1. > > Let me know if you have any objecitons or feedback! > > thanks > -john > > Cc: Tanglei Han > Cc: Zhuangluan Su > Cc: Ryan Grachek > Cc: Manivannan Sadhasivam > Cc: Wei Xu > Cc: Rob Herring > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > > > John Stultz (2): > arm64: dts: hi3660: Add dma to uart nodes > arm64: dts: hi3660: Fixup unofficial dma-min-chan to dma-channel-mask > > Youlin Wang (1): > arm64: dts: hi3660: Add hisi asp dma device > > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > Thanks! Applied the series to the hisilicon dts tree. Best Regards, Wei
Re: [PATCH 0/3] Add MMC controller support for HI3670 SoC
Hi Manivannan, On 2/28/2019 3:45 PM, Manivannan Sadhasivam wrote: > Hello, > > This patchset adds MMC controller support for HI3670 SoC. Since HI3670 > SoC is architecturally same as the HI3660 SoC, HI3660 DWMMC driver is > reused here with DT compatible fallback approach. Also, SD and WiFi > supports are added for the HiKey970 board. > > Wei: > > Please apply this patchset along with the reset and UFS patches in the > following order: > > 1. Reset support patches > 2. MMC support patches > 3. UFS support patches > > PS: Since there is no PMIC support available yet, fixed-regulator nodes > are used to get the driver working (regulators are enabled by bootloader). > > Thanks, > Mani > > Manivannan Sadhasivam (3): > dt-bindings: mmc: Add HI3670 MMC controller binding > arm64: dts: hisilicon: hi3670: Add MMC controller support > arm64: dts: hisilicon: hikey970: Add SD and WiFi support > > .../devicetree/bindings/mmc/k3-dw-mshc.txt| 2 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 75 > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 37 ++ > .../boot/dts/hisilicon/hikey970-pinctrl.dtsi | 115 ++ > 4 files changed, 229 insertions(+) > Thanks! Applied the series to the hisilicon dts tree with the order. Best Regards, Wei
Re: [PATCH v2 0/2] Add Reset controller support for HI3670 SoC
Hi Manivannan, On 2/15/2019 5:49 AM, Manivannan Sadhasivam wrote: > Hello, > > This patchset adds Reset controller support for HiSilicon HI3670 SoC. > HI3670 SoC is architecturally same as HI3660 SoC, hence the same driver > is reused. > > This patchset has been tested on HiKey970 board. > > Thanks, > Mani > > Changes in v2: > > * Used the DT compatible fallback approach instead of adding a new one > for HI3670 > > Manivannan Sadhasivam (2): > dt-bindings: reset: Add HI3670 reset controller binding > arm64: dts: hisilicon: hi3670: Add reset controller support > > .../devicetree/bindings/reset/hisilicon,hi3660-reset.txt | 7 --- > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 6 ++ > 2 files changed, 10 insertions(+), 3 deletions(-) > Thanks! Applied the series to the hisilicon dts tree. Best Regards, Wei
Re: [PATCH] HISI LPC: Don't fail probe for unrecognised child devices
Hi John,
On 1/3/2019 11:57 AM, John Garry wrote:
> Currently for ACPI-based FW we fail the probe for an unrecognised child
> HID.
>
> However, there is FW in the field with LPC child devices having fake HIDs,
> namely "IPI0002", which was an IPMI device invented to support the
> initial out-of-tree LPC host driver, different from the final mainline
> version.
>
> To provide compatibility support for these dodgy FWs, just discard the
> unrecognised HIDs instead of failing the probe altogether.
>
> Tested-by: Zengruan Ye
> Signed-off-by: John Garry
Updated the subject as "bus: hisi_lpc: xxx" to follow the style and
applied to the hisilicon tree.
Thanks!
Best Regards,
Wei
>
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> index d5f8545..19d7b6f 100644
> --- a/drivers/bus/hisi_lpc.c
> +++ b/drivers/bus/hisi_lpc.c
> @@ -522,10 +522,9 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
>
> if (!found) {
> dev_warn(hostdev,
> - "could not find cell for child device (%s)\n",
> + "could not find cell for child device (%s),
> discarding\n",
>hid);
> - ret = -ENODEV;
> - goto fail;
> + continue;
> }
>
> pdev = platform_device_alloc(cell->name, PLATFORM_DEVID_AUTO);
>
Re: [PATCH v2] arm64: dts: hikey: Give wifi some time after power-on
Hi Ulf,
On 2/4/2019 6:06 AM, Ulf Hansson wrote:
> On Fri, 1 Feb 2019 at 17:34, Wei Xu wrote:
>>
>> Hi Jan,
>>
>> On 1/24/2019 7:52 AM, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> Somewhere along recent changes to power control of the wl1835, power-on
>>> became very unreliable on the hikey, failing like this:
>>>
>>> wl1271_sdio: probe of mmc2:0001:1 failed with error -16
>>> wl1271_sdio: probe of mmc2:0001:2 failed with error -16
>>>
>>> After playing with some dt parameters and comparing to other users of
>>> this chip, it turned out we need some power-on delay to make things
>>> stable again. In contrast to those other users which define 200 ms, the
>>> hikey would already be happy with 1 ms. Still, we use the safer 10 ms,
>>> like on the Ultra96.
>>>
>>> Fixes: ea452678734e ("arm64: dts: hikey: Fix WiFi support")
>>> Signed-off-by: Jan Kiszka
>>> Acked-by: Ulf Hansson
>>
>> Applied to the hisilicon soc dt tree.
>
> Wei, can you please also add a stable tag to it?
Yes, added below tag into this patch.
Cc: #4.12+
Thanks for your kindly reminder :)
Best Regards,
Wei
>
> [...]
>
> Thanks and kind regards
> Uffe
>
> .
>
Re: [PATCH v2] arm64/hisilicon: fix SDcard detection
Hi Vincent, On 1/14/2019 8:24 AM, Vincent Guittot wrote: > The SDcard detection of hikey960 is active low so cd-inverted is wrong. > Instead of adding cd-inverted, we should better set correctly cd-gpios > to use GPIO_ACTIVE_LOW. > > Signed-off-by: Vincent Guittot Updated the subject as Leo suggested and applied to the hisilicon tree. Thanks! Best Regards, Wei > --- > > SD card detection was not working on v5.0-rc1 but patch > https://marc.info/?l=linux-mmc=154637189021211=2 makes it work. > Nevertheles, latest changes in of_mmc_detection makes possible to have > a correct DT config. > > arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts > b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts > index 71bfe41..dc314e7 100644 > --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts > +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts > @@ -665,8 +665,7 @@ > sd-uhs-sdr50; > sd-uhs-sdr104; > disable-wp; > - cd-inverted; > - cd-gpios = < 3 0>; > + cd-gpios = < 3 GPIO_ACTIVE_LOW>; > pinctrl-names = "default"; > pinctrl-0 = <_pmx_func >_clk_cfg_func >
Re: [PATCH][RESEND] arm64: dts: hikey: Add DMA entries for Bluetooth UART
Hi John, On 1/23/2019 8:30 PM, John Stultz wrote: > Add dma0 references for bluetooth uart to enable dma > for bt transfers. > > Cc: Manivannan Sadhasivam > Cc: Ryan Grachek > Cc: Wei Xu > Cc: Rob Herring > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Signed-off-by: John Stultz Applied to the hisilicon soc dt tree. Thanks! Best Regards, Wei > --- > arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi > b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi > index aec9e37..fa15a08 100644 > --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi > +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi > @@ -319,6 +319,8 @@ > clock-names = "uartclk", "apb_pclk"; > pinctrl-names = "default"; > pinctrl-0 = <_pmx_func _cfg_func1 > _cfg_func2>; > + dmas = < 8 9>; > + dma-names = "rx", "tx"; > status = "disabled"; > }; > >
Re: [PATCH] arm64: dts: hikey: Revert "Enable HS200 mode on eMMC"
Hi John,
On 1/23/2019 8:06 PM, John Stultz wrote:
> From: Alistair Strachan
>
> This reverts commit abd7d0972a192ee653efc7b151a6af69db58f2bb. This
> change was already partially reverted by John Stultz in commit
> 9c6d26df1fae ("arm64: dts: hikey: Fix eMMC corruption regression").
>
> This change appears to cause controller resets and block read failures
> which prevents successful booting on some hikey boards.
>
> Cc: Ryan Grachek
> Cc: Wei Xu
> Cc: Manivannan Sadhasivam
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: stable #4.17+
> Signed-off-by: Alistair Strachan
> Signed-off-by: John Stultz
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index 6102350..7092460 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -300,7 +300,6 @@
>
> dwmmc_0: dwmmc0@f723d000 {
> cap-mmc-highspeed;
> - mmc-hs200-1_8v;
> non-removable;
> bus-width = <0x8>;
> vmmc-supply = <>;
>
Re: [PATCH v2] arm64: dts: hikey: Give wifi some time after power-on
Hi Jan,
On 1/24/2019 7:52 AM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Somewhere along recent changes to power control of the wl1835, power-on
> became very unreliable on the hikey, failing like this:
>
> wl1271_sdio: probe of mmc2:0001:1 failed with error -16
> wl1271_sdio: probe of mmc2:0001:2 failed with error -16
>
> After playing with some dt parameters and comparing to other users of
> this chip, it turned out we need some power-on delay to make things
> stable again. In contrast to those other users which define 200 ms, the
> hikey would already be happy with 1 ms. Still, we use the safer 10 ms,
> like on the Ultra96.
>
> Fixes: ea452678734e ("arm64: dts: hikey: Fix WiFi support")
> Signed-off-by: Jan Kiszka
> Acked-by: Ulf Hansson
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
>
> Changes in v2:
> - set delay to 10 ms
> - updated changelog
>
> Who will take care of updating also the Hikey firmware dts with this
> change?
>
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index 610235028cc7..ba946543dd0a 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -118,6 +118,7 @@
> reset-gpios = < 5 GPIO_ACTIVE_LOW>;
> clocks = <>;
> clock-names = "ext_clock";
> + post-power-on-delay-ms = <10>;
> power-off-delay-us = <10>;
> };
>
> --
> 2.16.4
>
> .
>
Re: [PATCH 05/10] ARM64: dts: hisilicon: Add all CPUs in cooling maps
Hi Viresh,
On 2018/11/16 10:04, Viresh Kumar wrote:
> Each CPU can (and does) participate in cooling down the system but the
> DT only captures a handful of them, normally CPU0, in the cooling maps.
> Things work by chance currently as under normal circumstances its the
> first CPU of each cluster which is used by the operating systems to
> probe the cooling devices. But as soon as this CPU ordering changes and
> any other CPU is used to bring up the cooling device, we will start
> seeing failures.
>
> Also the DT is rather incomplete when we list only one CPU in the
> cooling maps, as the hardware doesn't have any such limitations.
>
> Update cooling maps to include all devices affected by individual trip
> points.
>
> Signed-off-by: Viresh Kumar
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 --
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 -
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index d943a96eedee..20ae40df61d5 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -1118,12 +1118,18 @@
> map0 {
> trip = <>;
> contribution = <1024>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> map1 {
> trip = <>;
> contribution = <512>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> };
> };
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 97d5bf2c6ec5..aec9e371c2a7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -893,7 +893,14 @@
> cooling-maps {
> map0 {
> trip = <>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> };
> };
>
Re: [PATCH 05/10] ARM64: dts: hisilicon: Add all CPUs in cooling maps
Hi Viresh,
On 2018/11/16 10:04, Viresh Kumar wrote:
> Each CPU can (and does) participate in cooling down the system but the
> DT only captures a handful of them, normally CPU0, in the cooling maps.
> Things work by chance currently as under normal circumstances its the
> first CPU of each cluster which is used by the operating systems to
> probe the cooling devices. But as soon as this CPU ordering changes and
> any other CPU is used to bring up the cooling device, we will start
> seeing failures.
>
> Also the DT is rather incomplete when we list only one CPU in the
> cooling maps, as the hardware doesn't have any such limitations.
>
> Update cooling maps to include all devices affected by individual trip
> points.
>
> Signed-off-by: Viresh Kumar
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 --
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 -
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index d943a96eedee..20ae40df61d5 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -1118,12 +1118,18 @@
> map0 {
> trip = <>;
> contribution = <1024>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> map1 {
> trip = <>;
> contribution = <512>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> };
> };
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 97d5bf2c6ec5..aec9e371c2a7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -893,7 +893,14 @@
> cooling-maps {
> map0 {
> trip = <>;
> - cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + cooling-device = <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> };
> };
>
Re: [PATCH 04/10] arm64: dts: hi3660: Add missing cooling device properties for CPUs
Hi Viresh,
On 2018/11/16 10:04, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index f432b0a88c65..d943a96eedee 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -79,6 +79,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu@2 {
> @@ -91,6 +92,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu@3 {
> @@ -103,6 +105,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu4: cpu@100 {
> @@ -129,6 +132,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu6: cpu@102 {
> @@ -141,6 +145,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu7: cpu@103 {
> @@ -153,6 +158,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> idle-states {
>
Re: [PATCH 04/10] arm64: dts: hi3660: Add missing cooling device properties for CPUs
Hi Viresh,
On 2018/11/16 10:04, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index f432b0a88c65..d943a96eedee 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -79,6 +79,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu@2 {
> @@ -91,6 +92,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu@3 {
> @@ -103,6 +105,7 @@
> capacity-dmips-mhz = <592>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER0>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu4: cpu@100 {
> @@ -129,6 +132,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu6: cpu@102 {
> @@ -141,6 +145,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu7: cpu@103 {
> @@ -153,6 +158,7 @@
> capacity-dmips-mhz = <1024>;
> clocks = <_clock HI3660_CLK_STUB_CLUSTER1>;
> operating-points-v2 = <_opp>;
> + #cooling-cells = <2>;
> };
>
> idle-states {
>
Re: [PATCH v3 0/7] Standardize onboard LED support for 96Boards
Hi Manivannan, On 2018/10/31 13:38, Linus Walleij wrote: > On Mon, Oct 29, 2018 at 10:43 AM Manivannan Sadhasivam > wrote: > >> This patchset standardizes the onboard LEDs on 96Boards by maintaining >> common labels and triggers as below: >> >> green:user1 default-trigger: heartbeat >> green:user2 default-trigger: mmc0/disk-activity (onboard-storage) >> green:user3 default-trigger: mmc1 (SD card) >> green:user4 default-trigger: none, panic-indicator >> yellow:wlan default-trigger: phy0tx >> blue:bt default-trigger: hci0-power >> >> This standardization is required to provide a common behaviour of LEDs >> across all mainline supported 96Boards and also making it easier to >> control it using an userspace library like MRAA. >> >> For Rock960 and Ficus boards, the LED support is added in this patchset. >> Rest of the boards are converted to adopt the standard. >> >> Note: Since there is no UFS trigger available for now, user2 LED trigger >> is set to none on HiKey960. > > This series: > Reviewed-by: Linus Walleij > > It makes a lot of sense to try to unify the userspace ABI so we get > some kind of order here instead of trying to counteract it with > per-device kludges in userspace. It definately makes things better! > > Yours, > Linus Walleij > > . > Applied hisilicon part(patch 3,4 and 5) to the hisilicon soc dt tree. Thanks! Best Regards, Wei
Re: [PATCH v3 0/7] Standardize onboard LED support for 96Boards
Hi Manivannan, On 2018/10/31 13:38, Linus Walleij wrote: > On Mon, Oct 29, 2018 at 10:43 AM Manivannan Sadhasivam > wrote: > >> This patchset standardizes the onboard LEDs on 96Boards by maintaining >> common labels and triggers as below: >> >> green:user1 default-trigger: heartbeat >> green:user2 default-trigger: mmc0/disk-activity (onboard-storage) >> green:user3 default-trigger: mmc1 (SD card) >> green:user4 default-trigger: none, panic-indicator >> yellow:wlan default-trigger: phy0tx >> blue:bt default-trigger: hci0-power >> >> This standardization is required to provide a common behaviour of LEDs >> across all mainline supported 96Boards and also making it easier to >> control it using an userspace library like MRAA. >> >> For Rock960 and Ficus boards, the LED support is added in this patchset. >> Rest of the boards are converted to adopt the standard. >> >> Note: Since there is no UFS trigger available for now, user2 LED trigger >> is set to none on HiKey960. > > This series: > Reviewed-by: Linus Walleij > > It makes a lot of sense to try to unify the userspace ABI so we get > some kind of order here instead of trying to counteract it with > per-device kludges in userspace. It definately makes things better! > > Yours, > Linus Walleij > > . > Applied hisilicon part(patch 3,4 and 5) to the hisilicon soc dt tree. Thanks! Best Regards, Wei
Re: [PATCH 0/5] Add Pinctrl and GPIO support for HI3670 SoC
Hi Manivannan, On 2018/11/12 7:17, Manivannan Sadhasivam wrote: > On Wed, Oct 31, 2018 at 10:43:00AM +0100, Linus Walleij wrote: >> On Tue, Oct 23, 2018 at 9:07 PM Manivannan Sadhasivam >> wrote: >> >>> This patchset adds Pinctrl and GPIO support for HI3670 SoC from HiSilicon >>> found in the HiKey970 developement board. Also, the remaining UARTs are >>> enabled and GPIO line names are added based on the Schematics and the >>> 96Boards Consumer Edition spec. >>> >>> Note: These patches are based on the below common clk patches pushed >>> earlier: >>> >>> arm64: dts: hisilicon: Add clock nodes for Hi3670 SoC >>> arm64: dts: hisilicon: Source SoC clock for UART6 >> >> All looks good to me. >> Acked-by: Linus Walleij >> for the series. >> > > Hi Wei, > > Any update on this patchset? Sorry for the late reply! Series applied to the hisilicon soc dt tree with minor changes in the subject. Thanks! Best Regards, Wei > > Thanks, > Mani > >> Yours, >> Linus Walleij > >
Re: [PATCH 0/5] Add Pinctrl and GPIO support for HI3670 SoC
Hi Manivannan, On 2018/11/12 7:17, Manivannan Sadhasivam wrote: > On Wed, Oct 31, 2018 at 10:43:00AM +0100, Linus Walleij wrote: >> On Tue, Oct 23, 2018 at 9:07 PM Manivannan Sadhasivam >> wrote: >> >>> This patchset adds Pinctrl and GPIO support for HI3670 SoC from HiSilicon >>> found in the HiKey970 developement board. Also, the remaining UARTs are >>> enabled and GPIO line names are added based on the Schematics and the >>> 96Boards Consumer Edition spec. >>> >>> Note: These patches are based on the below common clk patches pushed >>> earlier: >>> >>> arm64: dts: hisilicon: Add clock nodes for Hi3670 SoC >>> arm64: dts: hisilicon: Source SoC clock for UART6 >> >> All looks good to me. >> Acked-by: Linus Walleij >> for the series. >> > > Hi Wei, > > Any update on this patchset? Sorry for the late reply! Series applied to the hisilicon soc dt tree with minor changes in the subject. Thanks! Best Regards, Wei > > Thanks, > Mani > >> Yours, >> Linus Walleij > >
Re: [PATCH 3/4] arm64: dts: hisilicon: Source SoC clock for UART6
Hi Manivannan,
On 2018/9/21 7:01, Manivannan Sadhasivam wrote:
> Remove fixed clock and source SoC clock for UART6 for
> HiSilicon Hi3670 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index 8a0ee4b08886..34a2f0dbc6f7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -187,17 +187,12 @@
> #clock-cells = <1>;
> };
>
> - uart6_clk: clk_19_2M {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1920>;
> - };
> -
> uart6: serial@fff32000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0 0xfff32000 0x0 0x1000>;
> interrupts = ;
> - clocks = <_clk _clk>;
> + clocks = <_ctrl HI3670_CLK_UART6>,
> + <_ctrl HI3670_PCLK>;
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
>
Re: [PATCH 3/4] arm64: dts: hisilicon: Source SoC clock for UART6
Hi Manivannan,
On 2018/9/21 7:01, Manivannan Sadhasivam wrote:
> Remove fixed clock and source SoC clock for UART6 for
> HiSilicon Hi3670 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index 8a0ee4b08886..34a2f0dbc6f7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -187,17 +187,12 @@
> #clock-cells = <1>;
> };
>
> - uart6_clk: clk_19_2M {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1920>;
> - };
> -
> uart6: serial@fff32000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0 0xfff32000 0x0 0x1000>;
> interrupts = ;
> - clocks = <_clk _clk>;
> + clocks = <_ctrl HI3670_CLK_UART6>,
> + <_ctrl HI3670_PCLK>;
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
>
Re: [PATCH 2/4] arm64: dts: hisilicon: Add clock nodes for Hi3670 SoC
Hi Manivannan,
On 2018/9/21 7:01, Manivannan Sadhasivam wrote:
> Add clock nodes for HiSilicon Hi3670 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 43 +++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index c90e6f6a34ec..8a0ee4b08886 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -7,6 +7,7 @@
> */
>
> #include
> +#include
>
> / {
> compatible = "hisilicon,hi3670";
> @@ -144,6 +145,48 @@
> #size-cells = <2>;
> ranges;
>
> + crg_ctrl: crg_ctrl@fff35000 {
> + compatible = "hisilicon,hi3670-crgctrl", "syscon";
> + reg = <0x0 0xfff35000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + pctrl: pctrl@e8a09000 {
> + compatible = "hisilicon,hi3670-pctrl", "syscon";
> + reg = <0x0 0xe8a09000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + pmuctrl: crg_ctrl@fff34000 {
> + compatible = "hisilicon,hi3670-pmuctrl", "syscon";
> + reg = <0x0 0xfff34000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + sctrl: sctrl@fff0a000 {
> + compatible = "hisilicon,hi3670-sctrl", "syscon";
> + reg = <0x0 0xfff0a000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + iomcu: iomcu@ffd7e000 {
> + compatible = "hisilicon,hi3670-iomcu", "syscon";
> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + media1_crg: media1_crgctrl@e87ff000 {
> + compatible = "hisilicon,hi3670-media1-crg", "syscon";
> + reg = <0x0 0xe87ff000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + media2_crg: media2_crgctrl@e890 {
> + compatible = "hisilicon,hi3670-media2-crg","syscon";
> + reg = <0x0 0xe890 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> uart6_clk: clk_19_2M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
>
Re: [PATCH 2/4] arm64: dts: hisilicon: Add clock nodes for Hi3670 SoC
Hi Manivannan,
On 2018/9/21 7:01, Manivannan Sadhasivam wrote:
> Add clock nodes for HiSilicon Hi3670 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
Applied to the hisilicon soc dt tree.
Thanks!
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 43 +++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index c90e6f6a34ec..8a0ee4b08886 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -7,6 +7,7 @@
> */
>
> #include
> +#include
>
> / {
> compatible = "hisilicon,hi3670";
> @@ -144,6 +145,48 @@
> #size-cells = <2>;
> ranges;
>
> + crg_ctrl: crg_ctrl@fff35000 {
> + compatible = "hisilicon,hi3670-crgctrl", "syscon";
> + reg = <0x0 0xfff35000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + pctrl: pctrl@e8a09000 {
> + compatible = "hisilicon,hi3670-pctrl", "syscon";
> + reg = <0x0 0xe8a09000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + pmuctrl: crg_ctrl@fff34000 {
> + compatible = "hisilicon,hi3670-pmuctrl", "syscon";
> + reg = <0x0 0xfff34000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + sctrl: sctrl@fff0a000 {
> + compatible = "hisilicon,hi3670-sctrl", "syscon";
> + reg = <0x0 0xfff0a000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + iomcu: iomcu@ffd7e000 {
> + compatible = "hisilicon,hi3670-iomcu", "syscon";
> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + media1_crg: media1_crgctrl@e87ff000 {
> + compatible = "hisilicon,hi3670-media1-crg", "syscon";
> + reg = <0x0 0xe87ff000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + media2_crg: media2_crgctrl@e890 {
> + compatible = "hisilicon,hi3670-media2-crg","syscon";
> + reg = <0x0 0xe890 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> uart6_clk: clk_19_2M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
>
Re: [PATCH v2 03/11] arm64: dts: hi6220: Update coresight bindings for hardware ports
Hi Suzuki,
On 2018/9/12 14:53, Suzuki K Poulose wrote:
> Switch to updated coresight bindings for hw ports.
>
> Cc: xuw...@hisilicon.com
> Cc: lipengche...@huawei.com
> Cc: Mathieu Poirier
> Tested-by: Leo Yan
> Signed-off-by: Suzuki K Poulose
Thanks!
Applied to the hisilicon dt tree.
Best Regards,
Wei
> ---
> .../boot/dts/hisilicon/hi6220-coresight.dtsi | 181 +-
> 1 file changed, 86 insertions(+), 95 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> index 7afee5d5087b..68c52f1149be 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> @@ -20,22 +20,18 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + out-ports {
> + port {
> soc_funnel_out: endpoint {
> remote-endpoint =
> <_in>;
> };
> };
> + };
>
> - port@1 {
> - reg = <0>;
> + in-ports {
> + port {
> soc_funnel_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_funnel_out>;
> };
> @@ -49,21 +45,17 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + in-ports {
> + port {
> etf_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_funnel_out>;
> };
> };
> + };
>
> - port@1 {
> - reg = <0>;
> + out-ports {
> + port {
> etf_out: endpoint {
> remote-endpoint =
> <_in>;
> @@ -77,20 +69,20 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + in-ports {
> + port {
> replicator_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_out>;
> };
> };
> + };
>
> - port@1 {
> + out-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> reg = <0>;
> replicator_out0: endpoint {
> remote-endpoint =
> @@ -98,7 +90,7 @@
> };
> };
>
> - port@2 {
> + port@1 {
> reg = <1>;
> replicator_out1: endpoint {
> remote-endpoint =
> @@ -114,14 +106,9 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
Re: [PATCH v2 03/11] arm64: dts: hi6220: Update coresight bindings for hardware ports
Hi Suzuki,
On 2018/9/12 14:53, Suzuki K Poulose wrote:
> Switch to updated coresight bindings for hw ports.
>
> Cc: xuw...@hisilicon.com
> Cc: lipengche...@huawei.com
> Cc: Mathieu Poirier
> Tested-by: Leo Yan
> Signed-off-by: Suzuki K Poulose
Thanks!
Applied to the hisilicon dt tree.
Best Regards,
Wei
> ---
> .../boot/dts/hisilicon/hi6220-coresight.dtsi | 181 +-
> 1 file changed, 86 insertions(+), 95 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> index 7afee5d5087b..68c52f1149be 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> @@ -20,22 +20,18 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + out-ports {
> + port {
> soc_funnel_out: endpoint {
> remote-endpoint =
> <_in>;
> };
> };
> + };
>
> - port@1 {
> - reg = <0>;
> + in-ports {
> + port {
> soc_funnel_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_funnel_out>;
> };
> @@ -49,21 +45,17 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + in-ports {
> + port {
> etf_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_funnel_out>;
> };
> };
> + };
>
> - port@1 {
> - reg = <0>;
> + out-ports {
> + port {
> etf_out: endpoint {
> remote-endpoint =
> <_in>;
> @@ -77,20 +69,20 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + in-ports {
> + port {
> replicator_in: endpoint {
> - slave-mode;
> remote-endpoint =
> <_out>;
> };
> };
> + };
>
> - port@1 {
> + out-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> reg = <0>;
> replicator_out0: endpoint {
> remote-endpoint =
> @@ -98,7 +90,7 @@
> };
> };
>
> - port@2 {
> + port@1 {
> reg = <1>;
> replicator_out1: endpoint {
> remote-endpoint =
> @@ -114,14 +106,9 @@
> clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
> clock-names = "apb_pclk";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
Re: [PATCH v2 06/11] arm: dts: hip04: Update coresight bindings for hardware ports
Hi Suzuki,
On 2018/9/12 14:53, Suzuki K Poulose wrote:
> Switch to the new the hardware port bindings.
>
> Cc: Wei Xu
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
Thanks!
Applied to the hisilicon dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/hip04.dtsi | 346 ++-
> 1 file changed, 176 insertions(+), 170 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
> index 44044f275115..0f917b272ff3 100644
> --- a/arch/arm/boot/dts/hip04.dtsi
> +++ b/arch/arm/boot/dts/hip04.dtsi
> @@ -277,10 +277,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb0_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb0_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -291,10 +292,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb1_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb1_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -305,10 +307,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb2_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb2_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -319,10 +322,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb3_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb3_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -333,10 +337,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - tpiu_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + tpiu_in_port: endpoint@0 {
> + remote-endpoint = <_out_port0>;
> + };
> };
> };
> };
> @@ -347,7 +352,7 @@
>*/
> compatible = "arm,coresight-replicator";
>
> - ports {
> + out-ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -365,12 +370,11 @@
> remote-endpoint = <_in_port0>;
> };
> };
> + };
>
> - /* replicator input port */
> - port@2 {
> - reg = <0>;
> + in-ports {
> + port {
> replicator0_in_port0: endpoint {
> - slave-mode;
> remote-endpoint = <_out_port0>;
> };
> };
> @@ -383,7 +387,7 @@
>*/
> compatible = "arm,coresight-replicator";
>
>
Re: [PATCH v2 06/11] arm: dts: hip04: Update coresight bindings for hardware ports
Hi Suzuki,
On 2018/9/12 14:53, Suzuki K Poulose wrote:
> Switch to the new the hardware port bindings.
>
> Cc: Wei Xu
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
Thanks!
Applied to the hisilicon dt tree.
Best Regards,
Wei
> ---
> arch/arm/boot/dts/hip04.dtsi | 346 ++-
> 1 file changed, 176 insertions(+), 170 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
> index 44044f275115..0f917b272ff3 100644
> --- a/arch/arm/boot/dts/hip04.dtsi
> +++ b/arch/arm/boot/dts/hip04.dtsi
> @@ -277,10 +277,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb0_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb0_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -291,10 +292,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb1_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb1_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -305,10 +307,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb2_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb2_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -319,10 +322,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - etb3_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + etb3_in_port: endpoint@0 {
> + remote-endpoint =
> <_out_port0>;
> + };
> };
> };
> };
> @@ -333,10 +337,11 @@
>
> clocks = <_375m>;
> clock-names = "apb_pclk";
> - port {
> - tpiu_in_port: endpoint@0 {
> - slave-mode;
> - remote-endpoint = <_out_port0>;
> + in-ports {
> + port {
> + tpiu_in_port: endpoint@0 {
> + remote-endpoint = <_out_port0>;
> + };
> };
> };
> };
> @@ -347,7 +352,7 @@
>*/
> compatible = "arm,coresight-replicator";
>
> - ports {
> + out-ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -365,12 +370,11 @@
> remote-endpoint = <_in_port0>;
> };
> };
> + };
>
> - /* replicator input port */
> - port@2 {
> - reg = <0>;
> + in-ports {
> + port {
> replicator0_in_port0: endpoint {
> - slave-mode;
> remote-endpoint = <_out_port0>;
> };
> };
> @@ -383,7 +387,7 @@
>*/
> compatible = "arm,coresight-replicator";
>
>
Re: [PATCH 0/4] Add HiSilicon Hi3670 SoC and HiKey970 board
Hi Manivannan, On 2018/8/10 18:53, Manivannan Sadhasivam wrote: > This patchset adds support for Hi3670 SoC and HiKey970 board. Hi3670 SoC > is very similar to the Hi3660 SoC with additional NPU support. For now, > only UART6 has been enabled which is configured by the bootloader for > console support. > > HiKey970 board is one of the 96Boards Consumer Edition and AI platform > based on the Hi3670 SoC. > > With this patchset, the Hikey970 board is able to boot into ramdisk with > 8 cores. > > Thanks, > Mani > > Manivannan Sadhasivam (4): > dt-bindings: arm: hisilicon: Add binding for Hi3670 SoC > arm64: dts: Add devicetree for Hisilicon Hi3670 SoC > dt-bindings: arm: hisilicon: Add binding for HiKey970 board > arm64: dts: Add devicetree support for HiKey970 board > > .../bindings/arm/hisilicon/hisilicon.txt | 8 + > arch/arm64/boot/dts/hisilicon/Makefile| 1 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 35 > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 162 ++ > 4 files changed, 206 insertions(+) > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670.dtsi > Thanks! Fine to me and applied the series to the hisilicon dts tree. Best Regards, Wei
Re: [PATCH 0/4] Add HiSilicon Hi3670 SoC and HiKey970 board
Hi Manivannan, On 2018/8/10 18:53, Manivannan Sadhasivam wrote: > This patchset adds support for Hi3670 SoC and HiKey970 board. Hi3670 SoC > is very similar to the Hi3660 SoC with additional NPU support. For now, > only UART6 has been enabled which is configured by the bootloader for > console support. > > HiKey970 board is one of the 96Boards Consumer Edition and AI platform > based on the Hi3670 SoC. > > With this patchset, the Hikey970 board is able to boot into ramdisk with > 8 cores. > > Thanks, > Mani > > Manivannan Sadhasivam (4): > dt-bindings: arm: hisilicon: Add binding for Hi3670 SoC > arm64: dts: Add devicetree for Hisilicon Hi3670 SoC > dt-bindings: arm: hisilicon: Add binding for HiKey970 board > arm64: dts: Add devicetree support for HiKey970 board > > .../bindings/arm/hisilicon/hisilicon.txt | 8 + > arch/arm64/boot/dts/hisilicon/Makefile| 1 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 35 > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 162 ++ > 4 files changed, 206 insertions(+) > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670.dtsi > Thanks! Fine to me and applied the series to the hisilicon dts tree. Best Regards, Wei
Re: [PATCH] arm64: dts: hisilicon: Add missing clocks property for CPUs
Hi Viresh, On 2018/7/31 8:24, Viresh Kumar wrote: > On 23-07-18, 08:36, Viresh Kumar wrote: >> The clocks property should either be present for all the CPUs of a >> cluster or none. If these are present only for a subset of CPUs of a >> cluster then things will start falling apart as soon as the CPUs are >> brought online in a different order. For example, this will happen >> because the operating system looks for such properties in the CPU node >> it is trying to bring up, so that it can register a cooling device. >> >> Add missing clocks property. >> >> Signed-off-by: Viresh Kumar >> --- >> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++ >> 1 file changed, 7 insertions(+) > > @Wei: Can you please apply this one as well ? Sorry for the late reply! I will apply it after 4.19-rc1 released. Thanks! Best Regards, Wei
Re: [PATCH] arm64: dts: hisilicon: Add missing clocks property for CPUs
Hi Viresh, On 2018/7/31 8:24, Viresh Kumar wrote: > On 23-07-18, 08:36, Viresh Kumar wrote: >> The clocks property should either be present for all the CPUs of a >> cluster or none. If these are present only for a subset of CPUs of a >> cluster then things will start falling apart as soon as the CPUs are >> brought online in a different order. For example, this will happen >> because the operating system looks for such properties in the CPU node >> it is trying to bring up, so that it can register a cooling device. >> >> Add missing clocks property. >> >> Signed-off-by: Viresh Kumar >> --- >> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++ >> 1 file changed, 7 insertions(+) > > @Wei: Can you please apply this one as well ? Sorry for the late reply! I will apply it after 4.19-rc1 released. Thanks! Best Regards, Wei
Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps
Hi Viresh, On 2018/7/19 3:40, Viresh Kumar wrote: > On 18-07-18, 16:34, Wei Xu wrote: >> Hi Viresh, >> >> On 2018/7/5 6:09, Viresh Kumar wrote: >>> Hi, >>> >>> This is an attempt to fix the broken or partially defined DT bindings >>> for cooling-maps. We should list every device that participates in >>> cooling down at a certain trip point, instead of just the first in the >>> list as that depends on certain ordering of events to work properly. >>> >>> The first patch extends the binding to allow a list of phandles in >>> "cooling-device" property and the second patch fixes one of the >>> platform's DT. >>> >>> This will be followed up by fixing all platform DT bindings that have >>> these issues after this set is accepted. >>> >>> The kernel also requires some changes to handle the phandle list, but >>> wouldn't break with these changes as it reads the first phandle in the >>> list for now. We can update that separately. >>> >>> -- >>> viresh >>> >>> Viresh Kumar (2): >>> dt-bindings: thermal: Allow multiple devices to share cooling map >>> arm64: dts: hi6220: Add all CPUs in cooling maps >>> >>> Documentation/devicetree/bindings/thermal/thermal.txt | 11 +++ >>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 - >>> 2 files changed, 11 insertions(+), 9 deletions(-) >>> >> >> Thanks! >> Applied both to the hisilicon dt tree. > > Hi Wei, > > I expected the first patch to go via the thermal tree as it is for the > thermal core maintainers. Second patch can very well go from your > tree, but only after the 1st one is applied by thermal maintainers. > OK. I will drop them in the pull request and apply the dts patch later. Best Regards, Wei
Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps
Hi Viresh, On 2018/7/19 3:40, Viresh Kumar wrote: > On 18-07-18, 16:34, Wei Xu wrote: >> Hi Viresh, >> >> On 2018/7/5 6:09, Viresh Kumar wrote: >>> Hi, >>> >>> This is an attempt to fix the broken or partially defined DT bindings >>> for cooling-maps. We should list every device that participates in >>> cooling down at a certain trip point, instead of just the first in the >>> list as that depends on certain ordering of events to work properly. >>> >>> The first patch extends the binding to allow a list of phandles in >>> "cooling-device" property and the second patch fixes one of the >>> platform's DT. >>> >>> This will be followed up by fixing all platform DT bindings that have >>> these issues after this set is accepted. >>> >>> The kernel also requires some changes to handle the phandle list, but >>> wouldn't break with these changes as it reads the first phandle in the >>> list for now. We can update that separately. >>> >>> -- >>> viresh >>> >>> Viresh Kumar (2): >>> dt-bindings: thermal: Allow multiple devices to share cooling map >>> arm64: dts: hi6220: Add all CPUs in cooling maps >>> >>> Documentation/devicetree/bindings/thermal/thermal.txt | 11 +++ >>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 - >>> 2 files changed, 11 insertions(+), 9 deletions(-) >>> >> >> Thanks! >> Applied both to the hisilicon dt tree. > > Hi Wei, > > I expected the first patch to go via the thermal tree as it is for the > thermal core maintainers. Second patch can very well go from your > tree, but only after the 1st one is applied by thermal maintainers. > OK. I will drop them in the pull request and apply the dts patch later. Best Regards, Wei
Re: [PATCH 0/3] ARM: hisi: fix of_iomap errors
Hi Nicholas, On 2018/7/12 10:28, Nicholas Mc Guire wrote: > This patch set addresses two issues in arch/arm/mach-hisi/hotplug.c > > 1) The hisi hotplug functions were using a few unchecked >of_iomap() while at the same time the system relied on >those mappings. Checks for !NULL were inserted. > > 2) Further some mandatory of_node_put() were missing and have >been inserted. > > > . > Thanks! Applied all the 3 patches to the hisilicon SoC tree. Best Regards, Wei
Re: [PATCH 0/3] ARM: hisi: fix of_iomap errors
Hi Nicholas, On 2018/7/12 10:28, Nicholas Mc Guire wrote: > This patch set addresses two issues in arch/arm/mach-hisi/hotplug.c > > 1) The hisi hotplug functions were using a few unchecked >of_iomap() while at the same time the system relied on >those mappings. Checks for !NULL were inserted. > > 2) Further some mandatory of_node_put() were missing and have >been inserted. > > > . > Thanks! Applied all the 3 patches to the hisilicon SoC tree. Best Regards, Wei
Re: [PATCH] arm64: dts: hikey960: Remove deprecated MMC properties
Hi Ryan,
On 2018/6/18 19:08, Ryan Grachek wrote:
> Signed-off-by: Ryan Grachek
Thanks!
Applied to the hisilicon dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 -
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8
> 2 files changed, 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index c706f70ce9f2..abc991619c75 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -611,7 +611,6 @@
> broken-cd;
> /* WL_EN */
> vmmc-supply = <_en>;
> - ti,non-removable;
> non-removable;
> cap-power-off-card;
> keep-power-in-suspend;
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 484b837757f3..74c0509f99e9 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -1121,7 +1121,6 @@
> bus-width = <0x4>;
> disable-wp;
> cap-sd-highspeed;
> - supports-highspeed;
> card-detect-delay = <200>;
> reg = <0x0 0xff37f000 0x0 0x1000>;
> interrupts = ;
> @@ -1142,12 +1141,6 @@
> sd-uhs-sdr50;
> sd-uhs-sdr104;
> status = "disabled";
> -
> - slot@0 {
> - reg = <0x0>;
> - bus-width = <4>;
> - disable-wp;
> - };
> };
>
> /* SDIO */
> @@ -1162,7 +1155,6 @@
> reset-names = "reset";
> card-detect-delay = <200>;
> cap-sd-highspeed;
> - supports-highspeed;
> keep-power-in-suspend;
> pinctrl-names = "default";
> pinctrl-0 = <_pmx_func
>
