it expects a unsigned int, but got a __be32
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In commit 93a714d6b5 ("multicast: Extend ip address command to enable
multicast group join/leave on") we added a new flag IFA_F_MCAUTOJOIN
to make user able to add multicast address on ethernet interface.
This works for IPv4, but not for IPv6. See the inet6_addr_add code.
static int inet6_addr_add()
{
...
if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
ipv6_mc_config(net->ipv6.mc_autojoin_sk, true...)
}
ifp = ipv6_add_addr(idev, cfg, true, extack); <- always fail with maddr
if (!IS_ERR(ifp)) {
...
} else if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
ipv6_mc_config(net->ipv6.mc_autojoin_sk, false...)
}
}
But in ipv6_add_addr() it will check the address type and reject multicast
address directly. So this feature is never worked for IPv6.
We should not remove the multicast address check totally in ipv6_add_addr(),
but could accept multicast address only when IFA_F_MCAUTOJOIN flag supplied.
v2: update commit description
Fixes: 93a714d6b5 ("multicast: Extend ip address command to enable multicast group join/leave on")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The SF2 binding does not specify that the CPU port should have
properties mandatory for successfully instantiating a PHYLINK object. As
such, there will be missing properties (including fixed-link) and when
attempting to validate and later configure link modes, we will have an
incorrect set of parameters (interface, speed, duplex).
Simply prevent the CPU port from being configured through PHYLINK since
bcm_sf2_imp_setup() takes care of that already.
Fixes: 0e27921816 ("net: dsa: Use PHYLINK for the CPU/DSA ports")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This series includes updates to mlx5 ethernet and core driver:
Vlad submits part 3 of 3 part series to allow TC flow handling
for concurrent execution.
Vlad says:
==========
Structure mlx5e_neigh_hash_entry code that uses it are refactored in
following ways:
- Extend neigh_hash_entry with rcu and modify its users to always take
reference to the structure when using it (neigh_hash_entry has already
had atomic reference counter which was only used when scheduling neigh
update on workqueue from atomic context of neigh update netevent).
- Always use mlx5e_neigh_update_table->encap_lock when modifying neigh
update hash table and list. Originally, this lock was only used to
synchronize with netevent handler function, which is called from bh
context and cannot use rtnl lock for synchronization. Use rcu read lock
instead of encap_lock to lookup nhe in atomic context of netevent even
handler function. Convert encap_lock to mutex to allow creating new
neigh hash entries while holding it, which is safe to do because the
lock is no longer used in atomic context.
- Rcu-ify mlx5e_neigh_hash_entry->encap_list by changing operations on
encap list to their rcu counterparts and extending encap structure
with rcu_head to free the encap instances after rcu grace period. This
allows fast traversal of list of encaps attached to nhe under rcu read
lock protection.
- Take encap_table_lock when accessing encap entries in neigh update and
neigh stats update code to protect from concurrent encap entry
insertion or removal.
This approach leads to potential race condition when neigh update and
neigh stats update code can access encap and flow entries that are not
fully initialized or are being destroyed, or neigh can change state
without updating encaps that are created concurrently. Prevent these
issues by following changes in flow and encap initialization:
- Extend mlx5e_tc_flow with 'init_done' completion. Modify neigh update
to wait for both encap and flow completions to prevent concurrent
access to a structure that is being initialized by tc.
- Skip structures that failed during initialization: encaps with
encap_id<0 and flows that don't have OFFLOADED flag set.
- To ensure that no new flows are added to encap when it is being
accessed by neigh update or neigh stats update, take encap_table_lock
mutex.
- To prevent concurrent deletion by tc, ensure that neigh update and
neigh stats update hold references to encap and flow instances while
using them.
With changes presented in this patch set it is now safe to execute tc
concurrently with neigh update and neigh stats update. However, these
two workqueue tasks modify same flow "tmp_list" field to store flows
with reference taken in temporary list to release the references after
update operation finishes and should not be executed concurrently with
each other.
Last 3 patches of this series provide 3 new mlx5 trace points to track
mlx5 tc requests and mlx5 neigh updates.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGhZs6bAKwk/OTgTpSD+KveBX+j4FAl1dy9YACgkQSD+KveBX
+j6kIAf+PgnUuqH/VJKRVqLDvCvHJMV+pmfnTUBJNJinkg2QTgRw2+0hKj5bJgit
EOKxVbJEB4bC7FERjgTNY981fl2hK7/NQSWcWemhH7mwvnzAffpIuXMrK6Sw1uD9
FHSeMCIRZLnaQi7oZYK7TEptChh4lsxVOMF9rLCAZ+ivbJFqYLOVRvo936FD91FN
6gqzccyXY9srz9ideOZHxOLqGGFfDktw/Ijr5uyylVRSJFnj3zLhVAshNEYISHIE
1a3cQQ9k7RmYCdlEcKxWO81doaNx3E9t110opqlDTm7ETOaqH/tOuMQDbABuVG0Q
ELKnFwuPG2Hi26jcusasvMjYyYttXg==
=0UbW
-----END PGP SIGNATURE-----
Merge tag 'mlx5-updates-2019-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5 tc flow handling for concurrent execution (Part 3)
This series includes updates to mlx5 ethernet and core driver:
Vlad submits part 3 of 3 part series to allow TC flow handling
for concurrent execution.
Vlad says:
==========
Structure mlx5e_neigh_hash_entry code that uses it are refactored in
following ways:
- Extend neigh_hash_entry with rcu and modify its users to always take
reference to the structure when using it (neigh_hash_entry has already
had atomic reference counter which was only used when scheduling neigh
update on workqueue from atomic context of neigh update netevent).
- Always use mlx5e_neigh_update_table->encap_lock when modifying neigh
update hash table and list. Originally, this lock was only used to
synchronize with netevent handler function, which is called from bh
context and cannot use rtnl lock for synchronization. Use rcu read lock
instead of encap_lock to lookup nhe in atomic context of netevent even
handler function. Convert encap_lock to mutex to allow creating new
neigh hash entries while holding it, which is safe to do because the
lock is no longer used in atomic context.
- Rcu-ify mlx5e_neigh_hash_entry->encap_list by changing operations on
encap list to their rcu counterparts and extending encap structure
with rcu_head to free the encap instances after rcu grace period. This
allows fast traversal of list of encaps attached to nhe under rcu read
lock protection.
- Take encap_table_lock when accessing encap entries in neigh update and
neigh stats update code to protect from concurrent encap entry
insertion or removal.
This approach leads to potential race condition when neigh update and
neigh stats update code can access encap and flow entries that are not
fully initialized or are being destroyed, or neigh can change state
without updating encaps that are created concurrently. Prevent these
issues by following changes in flow and encap initialization:
- Extend mlx5e_tc_flow with 'init_done' completion. Modify neigh update
to wait for both encap and flow completions to prevent concurrent
access to a structure that is being initialized by tc.
- Skip structures that failed during initialization: encaps with
encap_id<0 and flows that don't have OFFLOADED flag set.
- To ensure that no new flows are added to encap when it is being
accessed by neigh update or neigh stats update, take encap_table_lock
mutex.
- To prevent concurrent deletion by tc, ensure that neigh update and
neigh stats update hold references to encap and flow instances while
using them.
With changes presented in this patch set it is now safe to execute tc
concurrently with neigh update and neigh stats update. However, these
two workqueue tasks modify same flow "tmp_list" field to store flows
with reference taken in temporary list to release the references after
update operation finishes and should not be executed concurrently with
each other.
Last 3 patches of this series provide 3 new mlx5 trace points to track
mlx5 tc requests and mlx5 neigh updates.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Most importantly per-process address spaces on GPUs that are capable of
providing proper isolation has finished baking. This is the base for
our softpin implementation, which allows us to support the texture
descriptor buffers used by GC7000 series GPUs without a major UAPI
extension/rework.
Shortlog of notable changes:
- code cleanup from Fabio
- fix performance counters on GC880 and GC2000 GPUs from Christian
- drmP.h header removal from Sam
- per process address space support on MMUv2 GPUs from me
- softpin support from me
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1565946875.2641.73.camel@pengutronix.de
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function restore_process_worker:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:949:29: warning:
variable pdd set but not used [-Wunused-but-set-variable]
It is not used since
commit 5b87245faf ("drm/amdkfd: Simplify kfd2kgd interface")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_common_early_init':
drivers/gpu/drm/amd/amdgpu/nv.c:471:7: warning:
variable 'psp_enabled' set but not used [-Wunused-but-set-variable]
It's not used since inroduction in
commit c6b6a42175 ("drm/amdgpu: add navi10 common ip block (v3)")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When building arm32 allyesconfig:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by dc_link.c
>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive drivers/built-in.a
>>> referenced by dc_link.c
>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive drivers/built-in.a
time_taken_in_ns is of type unsigned long long so we need to use div_u64
to avoid this error.
Fixes: b5b1f45549 ("drm/amd/display: Enable type C hotplug")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Error out if the AMDGPU_CS ioctl is called with multiple SYNCOBJ_OUT and/or
TIMELINE_SIGNAL chunks, since otherwise the last chunk wins while the
allocated array as well as the reference counts of sync objects are leaked.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We need to ensure that we're holding the lock on the CRTC when setting
the CRC source since we're modifying the CRTC state directly.
We also need to wait for any outstanding non-blocking commits to finish
so they aren't reading state that's potentially being modified -
non-blocking commits don't hold the CRTC lock while doing commit tail
work.
[How]
Lock the CRTC using its mutex. While holding the lock check if there's
any commit active on the CRTC - if there is, it's non-blocking and
we should wait until it's finished by waiting for hw_done to be
signaled since that's the last point where we touch CRTC state.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Calling amdgpu_dm_crtc_set_crc_source in amdgpu_dm directly has the
consequence of adding additional vblank references or starting DPRX
CRC capture more than once without calling stop first.
Vblank references for CRC capture should be managed entirely by opening
and closing the CRC file from userspace.
Stream state also shouldn't be required on the CRC so we can close the
file after the CRTC has been disabled.
[How]
Do DC programming required for configuring CRC capture separately from
setting the source. Whenever we re-enable or reset a CRC this
programming should be reapplied.
CRC vblank reference handling in amdgpu_dm can be entirely dropped after
this.
Stream state also no longer needs to be required since we can just defer
the programming to when the stream is actually enabled.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This change is a refactor in preparation for adding locking and removing
the requirement for a stream state on the CRTC for enabling CRC capture
to fix igt@kms_plane_multiple@* warnings.
[How]
We can get the aux by finding the matching connector for the CRTC
with the assumption that we're not doing cloning.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The call to drm_crtc_vblank_get can fail if vblank is disabled and
we try to increment the reference.
Since drm_crtc_vblank_get internally drops the reference when it fails
it means the subsequent drm_crtc_vblank_put(...) when closing the file
drops a zero reference.
This was found via igt@kms_plane@pixel-format-pipe-A-planes.
[How]
Check the return code and return it on failure.
We wouldn't have been able to enable CRC reading anyway since vblank
wasn't enabled.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Disable MMHUB PG for navi10 according to the production requirement.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
"COMPUTE" was wrongly spelled as "CUSTOM".
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Problems with current settings:
1. The min value was overrided to 0 on Vega20 & Navi10. While
the expected should be -273.15 C.
2. The thermal min/max threshold was output in wrong unit on
Navi10 & Arcturus. As TEMP_RANGE_MIN/MAX is already in
millicelsius. And "*1000" in smu_v11_0_start_thermal_control
makes the output wrongly.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On fclk dpm disabled, the default dpm table will be setup with only one
level and clock frequency as bootup value.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is available with firmwareinfo table v3.2 or later.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Do not expose those unsupported clock domains through sysfs on
Arcturus.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Update smc fw and driver interface header.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
fix size type errors, from uint32_t to uint16_t.
it will cause only initializes the highest 16 bits in
smu_get_atom_data_table function.
bug report:
This fixes the following static checker warning.
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:390 smu_v11_0_setup_pptable()
warn: passing casted pointer '&size' to 'smu_get_atom_data_table()' 32 vs 16.
Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
the bellow patch refine the sensor read sequence,
but missed to add arcuturs support. (arcuturs_ppt.c)
it will cause some sensor is not supported in arcturus.
drm/amd/powerplay: change smu_read_sensor sequence in smu
Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
'_navi10_ip_offset_HEADER' is already used in 'navi10_ip_offset.h', so use
'_navi12_ip_offset_HEADER' instead here.
Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
so that more visible vram can be available for umd.
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Tianci.Yin <tianci.yin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The name field in node topology has not been used. We re-purpose it to
hold the asic name, which can be queried by user space applications
through sysfs.
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is to improve performance.
Signed-off-by: Feifei Xu <Feifei.Xu@amd.com>
Tested-by: Candice Li <candice.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
firmware header information is printed for direct fw loading but not
added for psp fw loading yet
v2: squash in warning fix (Alex)
Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
s/r list in rlc firmware is ready, so remove the special autoload handling
Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The only place where state->max_bpc is updated on the connector is
at the start of atomic check during drm_atomic_connector_check. It
isn't updated when adding the connectors to the atomic state after
the fact. It also doesn't necessarily reflect the right value when
called in amdgpu during mode validation outside of atomic check.
This can cause the wrong bpc to be used even if the max_requested_bpc
is the correct value.
[How]
Don't rely on state->max_bpc reflecting the real bpc value and just
do the min(...) based on display info bpc and max_requested_bpc.
Fixes: 01933ba42d ("drm/amd/display: Use current connector state if NULL when checking bpc")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to set certain power gating flags after we determine
if the firmware version is sufficient to support gfxoff.
Previously we set the pg flags in early init, but we later
we might have disabled gfxoff if the firmware versions didn't
support it. Move adding the additional pg flags after we
determine whether or not to support gfxoff.
Fixes: 005440066f ("drm/amdgpu: enable gfxoff again on raven series (v2)")
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
610 has vipt aliasing issue, so we need to finish the cache flush
apis mentioned in cachetlb.rst to avoid data corruption.
Here is the list of modified apis in the patch:
- flush_kernel_dcache_page (new add)
- flush_dcache_mmap_lock (new add)
- flush_dcache_mmap_unlock (new add)
- flush_kernel_vmap_range (new add)
- invalidate_kernel_vmap_range (new add)
- flush_anon_page (new add)
- flush_cache_range (new add)
- flush_cache_vmap (flush all)
- flush_cache_vunmap (flush all)
- flush_cache_mm (only dcache flush)
- flush_icache_page (just nop)
- copy_from_user_page (remove no need flush)
- copy_to_user_page (remove no need flush)
Change to V2:
- Fixup compile error with xa_lock*(&mapping->i_pages)
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@infradead.org>
mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no
longer have any users, they have all been converted to use
mmu_notifier_put().
So delete this difficult to use interface.
Link: https://lore.kernel.org/r/20190806231548.25242-12-jgg@ziepe.ca
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ralph Campbell <rcampbell@nvidia.com>
Tested-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
At this point the ucontext is only being stored to access the ib_device,
so just store the ib_device directly instead. This is more natural and
logical as the umem has nothing to do with the ucontext.
Link: https://lore.kernel.org/r/20190806231548.25242-8-jgg@ziepe.ca
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
This is a significant simplification, no extra list is kept per FD, and
the interval tree is now shared between all the ucontexts, reducing
overhead if there are multiple ucontexts active.
Link: https://lore.kernel.org/r/20190806231548.25242-7-jgg@ziepe.ca
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
From rdma.git
Jason Gunthorpe says:
====================
This is a collection of general cleanups for ODP to clarify some of the
flows around umem creation and use of the interval tree.
====================
The branch is based on v5.3-rc5 due to dependencies, and is being taken
into hmm.git due to dependencies in the next patches.
* odp_fixes:
RDMA/mlx5: Use odp instead of mr->umem in pagefault_mr
RDMA/mlx5: Use ib_umem_start instead of umem.address
RDMA/core: Make invalidate_range a device operation
RDMA/odp: Use kvcalloc for the dma_list and page_list
RDMA/odp: Check for overflow when computing the umem_odp end
RDMA/odp: Provide ib_umem_odp_release() to undo the allocs
RDMA/odp: Split creating a umem_odp from ib_umem_get
RDMA/odp: Make the three ways to create a umem_odp clear
RMDA/odp: Consolidate umem_odp initialization
RDMA/odp: Make it clearer when a umem is an implicit ODP umem
RDMA/odp: Iterate over the whole rbtree directly
RDMA/odp: Use the common interval tree library instead of generic
RDMA/mlx5: Fix MR npages calculation for IB_ACCESS_HUGETLB
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Add SM8150 and SC7180 AOSS QMP to the list of possible bindings.
Tested-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Update max processor count to reflect the number of
co-processors on SC7180 SoCs.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Tested-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
