Re: [PATCH] net: core: Fix to store new mtu setting in netdevice.
On 01.01.2019 09:42, Murali Krishna Policharla wrote:
> Store newly configured mtu settings in the netdevice after mtu
> configuration is successful to the dsa switch.
>
> Fixes: 2315dc91a5 ("net: make dev_set_mtu() honor notification return code")
> Signed-off-by: Murali Krishna Policharla
> Reviewed-by: Florian Fainelli
> ---
> net/core/dev.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 722d50d..58617aa 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7586,12 +7586,15 @@ int dev_change_flags(struct net_device *dev, unsigned
> int flags)
> int __dev_set_mtu(struct net_device *dev, int new_mtu)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
> + int ret = 0;
>
> if (ops->ndo_change_mtu)
> - return ops->ndo_change_mtu(dev, new_mtu);
Is there a .ndo_change_mtu callback, which does not assign a new mtu itself?
> + ret = ops->ndo_change_mtu(dev, new_mtu);
>
> - dev->mtu = new_mtu;
> - return 0;
> + if (ret >= 0)
> + dev->mtu = new_mtu;
> +
> + return ret;
> }
> EXPORT_SYMBOL(__dev_set_mtu);
>
>
Re: [PATCH] infiniband: bnxt_re: qplib: Check the return value of send_message
On Wed, Dec 26, 2018 at 12:56:22PM -0600, Aditya Pakki wrote: > In bnxt_qplib_map_tc2cos(), bnxt_qplib_rcfw_send_message() can return > an error value. The fix returns the error from the latter function > upstream. > > Signed-off-by: Aditya Pakki > --- > drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c > b/drivers/infiniband/hw/bnxt_re/qplib_sp.c > index 5216b5f844cc..adb8eae5193c 100644 > --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c > +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c > @@ -778,9 +778,8 @@ int bnxt_qplib_map_tc2cos(struct bnxt_qplib_res *res, u16 > *cids) > req.cos0 = cpu_to_le16(cids[0]); > req.cos1 = cpu_to_le16(cids[1]); > > - bnxt_qplib_rcfw_send_message(rcfw, (void *), (void *), NULL, > - 0); > - return 0; > + return bnxt_qplib_rcfw_send_message(rcfw, (void *), (void *), > + NULL, 0); > } AFAIK, there is no need to do casting to/from void*. Thanks > > int bnxt_qplib_get_roce_stats(struct bnxt_qplib_rcfw *rcfw, > -- > 2.17.1 > signature.asc Description: PGP signature
Re: [PATCH 6/6] MAINTAINERS: Add linux-actions mailing list for Actions Semi
On Tue, Jan 01, 2019 at 04:32:40AM +0100, Andreas Färber wrote: > Am 01.01.19 um 04:26 schrieb Manivannan Sadhasivam: > > On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote: > >> On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote: > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >> [] > >>> @@ -1240,6 +1240,7 @@ ARM/ACTIONS SEMI ARCHITECTURE > >>> M: Andreas Färber > >>> R: Manivannan Sadhasivam > >>> L: linux-arm-ker...@lists.infradead.org (moderated for > >>> non-subscribers) > >>> +L: linux-acti...@lists.infradead.org (moderated for > >>> non-subscribers) > >>> S: Maintained > >>> N: owl > >> > >> The N: entry matches too many non-owl entries like: > >> > >> Documentation/parport-lowlevel.txt > >> drivers/misc/ibmasm/lowlevel.c > >> drivers/misc/ibmasm/lowlevel.h > >> fs/udf/lowle > >> vel.c > >> net/ipv6/ip6_flowlabel.c > >> sound/soc/samsung/lowland.c > >> > >> Maybe there should be two entries > >> > >> N: /owl > >> N: -owl > >> > > > > Thanks for letting us know. Yes, we need to change it. How about below? > > > > N: owl- > > N: -owl > > No underscores anywhere? > There is nothing with underscore yet and I don't think we'll add it in future. Thanks, Mani > Cheers, > Andreas > > > > > Will do it as a follow-up patch if agreed! > > > > Regards, > > Mani > > > >> > > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg)
[PATCH] net: core: Fix to store new mtu setting in netdevice.
Store newly configured mtu settings in the netdevice after mtu
configuration is successful to the dsa switch.
Fixes: 2315dc91a5 ("net: make dev_set_mtu() honor notification return code")
Signed-off-by: Murali Krishna Policharla
Reviewed-by: Florian Fainelli
---
net/core/dev.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 722d50d..58617aa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7586,12 +7586,15 @@ int dev_change_flags(struct net_device *dev, unsigned
int flags)
int __dev_set_mtu(struct net_device *dev, int new_mtu)
{
const struct net_device_ops *ops = dev->netdev_ops;
+ int ret = 0;
if (ops->ndo_change_mtu)
- return ops->ndo_change_mtu(dev, new_mtu);
+ ret = ops->ndo_change_mtu(dev, new_mtu);
- dev->mtu = new_mtu;
- return 0;
+ if (ret >= 0)
+ dev->mtu = new_mtu;
+
+ return ret;
}
EXPORT_SYMBOL(__dev_set_mtu);
--
1.9.1
RE: How to force RC to forward p2p TLPs
There is no method to force an RC to forward requests p2p. RC's are also not required to support p2p and whether they do or not is implementation specific. There is also currently no PCIe based standard to determine whether an RC supports p2p or in what capacity. Also, even if p2p is supported, it might not be supported in a system that enables Virtualization (the Virtualization would have to setup p2p tables to allow it). There is currently a PCIe ECR that has been submitted, but is undergoing review, that defines a PCIe capability for bridge devices (Root Ports and Switch Downstream Ports) that would allow them to advertise what level of p2p is supported by the device. Eric Wehage Huawei Principal Engineer, PCIe -Original Message- From: Bjorn Helgaas [mailto:helg...@kernel.org] Sent: Friday, December 28, 2018 6:29 PM To: yu Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Logan Gunthorpe ; Stephen Bates ; Jonathan Cameron ; Eric Wehage ; Alexander Duyck Subject: Re: How to force RC to forward p2p TLPs [+cc Logan, Stephen, Jonathan, Eric, Alex] On Sat, Dec 22, 2018 at 12:50:19PM +0800, yu wrote: > Hi all, > > We have a PCIE card which has a PEX8732 switch on-board, and there > are two endpoint SOCs like graphic decoder behind the switch, and by > default the ACS is enabled in 8732. > > We use the p2p DMA to transfer data between these two endpoint SOCs, > and if the host server is not enable ACS in BIOS, the p2p works well, > but when ACS is enabled in BIOS, the p2p is always failed. With the > help of a protocol analyzer, we can see that the TLP is redirected to > RC, and RC just discard it. > > I tried to find how to make RC forward redirected TLP to its original > target, but nothing found, it seems this is highly related to the RC > vendors. > > In the PCIE 4.0 spec, the section of the RC behavior of the p2p > request redirect said that ''implementation-specific logic within the > RC that determines whether the request is directed towards its > original target, or blocked as an ACS Violation error. the algorithms > and specific controls for making this determination are not > architected by this spec''. > > > So is there some spec or document to describe how to set the RC? Any > suggestion is appreciated. Not that I'm aware of, but the folks I cc'd would know a lot more about this area. Bjorn
Re: [PATCH v12 0/7] Introduce on-chip interconnect API
Hi Olof, Georgi, Happy new year! :-) Quoting Georgi Djakov (2018-12-08 21:15:35) > Hi Olof, > > On 9.12.18 2:33, Olof Johansson wrote: > > Hi Georgi, > > > > On Sat, Dec 8, 2018 at 9:02 AM Georgi Djakov > > wrote: > >> > >> Modern SoCs have multiple processors and various dedicated cores (video, > >> gpu, > >> graphics, modem). These cores are talking to each other and can generate a > >> lot of data flowing through the on-chip interconnects. These interconnect > >> buses could form different topologies such as crossbar, point to point > >> buses, > >> hierarchical buses or use the network-on-chip concept. > >> > >> These buses have been sized usually to handle use cases with high data > >> throughput but it is not necessary all the time and consume a lot of power. > >> Furthermore, the priority between masters can vary depending on the running > >> use case like video playback or CPU intensive tasks. > >> > >> Having an API to control the requirement of the system in terms of > >> bandwidth > >> and QoS, so we can adapt the interconnect configuration to match those by > >> scaling the frequencies, setting link priority and tuning QoS parameters. > >> This configuration can be a static, one-time operation done at boot for > >> some > >> platforms or a dynamic set of operations that happen at run-time. > >> > >> This patchset introduce a new API to get the requirement and configure the > >> interconnect buses across the entire chipset to fit with the current > >> demand. > >> The API is NOT for changing the performance of the endpoint devices, but > >> only > >> the interconnect path in between them. > >> > >> The API is using a consumer/provider-based model, where the providers are > >> the interconnect buses and the consumers could be various drivers. > >> The consumers request interconnect resources (path) to an endpoint and set > >> the desired constraints on this data flow path. The provider(s) receive > >> requests from consumers and aggregate these requests for all master-slave > >> pairs on that path. Then the providers configure each participating in the > >> topology node according to the requested data flow path, physical links and > >> constraints. The topology could be complicated and multi-tiered and is SoC > >> specific. > > > > This patch series description fails to describe why you need a brand > > new subsystem for this instead of either using one of the current > > ones, or adapting it to fit the needs you have. > > > > Primarily, I'm wondering what's missing from drivers/devfreq to fit your > > needs? > > The devfreq subsystem seems to be more oriented towards a device (like > GPU or CPU) that controls the power/performance characteristics by > itself and not the performance of other devices. The main problem of > using it is that it's using a reactive approach - for example monitor > some performance counters and then reconfigure bandwidth after some > bottleneck has already occurred. This is suboptimal and might not work > well. The new solution does the opposite by allowing drivers to > express their needs in advance and be proactive. Devfreq also does not > seem suitable for configuring complex, multi-tiered bus topologies and > aggregating constraints provided by drivers. [reflowed Georgi's responses] Agreed that devfreq is not good for this. Like any good driver framework, the interconnect framework provides a client/consumer api to device drivers to express their needs (in this case, throughput over a bus or interconnect). On modern SoCs these topologies can be quite complicated, which requires a provider api. I think that a dedicated framework makes sense for this. > > > The series also doesn't seem to provide any kind of indication how > > this will be used by end points. You have one driver for one SoC that > > just contains large tables that are parsed at probe time, but no > > driver hooks anywhere that will actually change any settings depending > > on use cases. Also, the bindings as posted don't seem to include any > > of this kind of information. So it's hard to get a picture of how this > > is going to be used in reality, which makes it hard to judge whether > > it is a good solution or not. > > Here are links to some of the examples that are on the mailing list > already. I really should have included them in the cover letter. > https://lkml.org/lkml/2018/12/7/584 > https://lkml.org/lkml/2018/10/11/499 > https://lkml.org/lkml/2018/9/20/986 > https://lkml.org/lkml/2018/11/22/772 > > Platforms drivers for different SoCs are available: > https://lkml.org/lkml/2018/11/17/368 > https://lkml.org/lkml/2018/8/10/380 > There is a discussion on linux-pm about supporting also Tegra > platforms in addition to NXP and Qualcomm. Just FYI, Alex will renew his efforts to port iMX over to this framework after the new year. I honestly don't know if this series is ready to be merged or not. I stopped reviewing it a long time ago. But there is interest in the
kernel BUG at kernel/sched/core.c:3490!
Running some mmap() workloads to put the system on low memory situation with
swapping and OOM, and then it trigger this BUG(),
void __noreturn do_task_dead(void)
{
/* Causes final put_task_struct in finish_task_switch(): */
set_special_state(TASK_DEAD);
/* Tell freezer to ignore us: */
current->flags |= PF_NOFREEZE;
__schedule(false);
BUG();
/* Avoid "noreturn function does return" - but don't continue if BUG()
is a NOP: */
for (;;)
cpu_relax();
}
[ 422.863911] kernel BUG at kernel/sched/core.c:3490!
[ 422.868634] oom01 (3177) used greatest stack depth: 28712 bytes left
[ 422.869109] invalid opcode: [#1] SMP KASAN NOPTI
[ 422.880325] CPU: 86 PID: 3235 Comm: oom01 Kdump: loaded Tainted: GW
4.20.0+ #5
[ 422.888995] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10,
BIOS A40 09/07/2018
[ 422.897590] RIP: 0010:do_task_dead+0x73/0x90
[ 422.901893] Code: 48 c7 43 10 80 00 00 00 4c 89 ee 4c 89 e7 e8 34 26 8a 00 48
8d 7b 24 e8 3b b6 2e 00 81 4b 24 00 80 00 00 31 ff e8 8d 4c 89 00 <0f> 0b 48 c7
c7 40 2c 53 b1 e8 da e7 51 00 0f 1f 44 00 00 66 2e 0f
[ 422.920783] RSP: 0018:888392daf5a8 EFLAGS: 00010282
[ 422.926048] RAX: RBX: 88810e23aec0 RCX:
[ 422.933234] RDX: dc00 RSI: dc00 RDI: ed10725b5ea8
[ 422.940419] RBP: 888392daf5c0 R08: fbfff6338a76 R09: fbfff6338a75
[ 422.947604] R10: fbfff6338a75 R11: b19c53ab R12: 88810e23b510
[ 422.954789] R13: 0246 R14: R15: 888638f636d8
[ 422.961974] FS: 7f105ff5d700() GS:88905e30()
knlGS:
[ 422.970118] CS: 0010 DS: ES: CR0: 80050033
[ 422.975905] CR2: 7f105ff5d9d0 CR3: 000a23e1e000 CR4: 001406a0
[ 422.983087] Call Trace:
[ 422.985564] do_exit+0x95e/0xe30
[ 422.988821] ? dump_align+0x50/0x50
[ 422.992338] ? mm_update_next_owner+0x570/0x570
[ 422.996906] ? __kasan_slab_free+0x1af/0x210
[ 423.001207] ? kmem_cache_free+0xc0/0x350
[ 423.005247] ? __dequeue_signal+0x2bd/0x370
[ 423.009460] ? dequeue_signal+0x90/0x2d0
[ 423.013410] ? get_signal+0x296/0xf30
[ 423.017100] ? do_signal+0x93/0x9d0
[ 423.020619] ? exit_to_usermode_loop+0x130/0x170
[ 423.025271] ? prepare_exit_to_usermode+0x1d7/0x1f0
[ 423.030187] ? retint_user+0x8/0x18
[ 423.033704] ? trace_hardirqs_off+0x9d/0x230
[ 423.038005] ? trace_hardirqs_on_caller+0x230/0x230
[ 423.042919] ? do_raw_spin_trylock+0x180/0x180
[ 423.047396] ? do_raw_spin_lock+0xf0/0x1f0
[ 423.051524] ? rwlock_bug.part.0+0x60/0x60
[ 423.055656] ? __dequeue_signal+0x2bd/0x370
[ 423.059871] ? _raw_spin_unlock_irqrestore+0x34/0x50
[ 423.064873] ? __debug_check_no_obj_freed+0x204/0x330
[ 423.069963] ? debug_object_free+0x10/0x10
[ 423.074092] ? trace_hardirqs_on_caller+0x9f/0x230
[ 423.078920] ? check_stack_object+0x22/0x60
[ 423.083138] ? debug_lockdep_rcu_enabled+0x22/0x40
[ 423.087964] ? kmem_cache_free+0x22e/0x350
[ 423.092091] ? __dequeue_signal+0x2bd/0x370
[ 423.096309] ? debug_lockdep_rcu_enabled+0x22/0x40
[ 423.101137] ? get_signal+0x530/0xf30
[ 423.104828] ? __flush_itimer_signals+0x310/0x310
[ 423.109567] ? check_flags.part.18+0x220/0x220
[ 423.114045] ? recalc_sigpending+0x6e/0x110
[ 423.118258] ? __sigqueue_alloc+0x4e0/0x4e0
[ 423.122470] ? lockdep_hardirqs_on+0x11/0x290
[ 423.126861] do_group_exit+0xc1/0x1d0
[ 423.130552] ? __x64_sys_exit+0x30/0x30
[ 423.134416] get_signal+0x4a6/0xf30
[ 423.137933] ? ptrace_notify+0xb0/0xb0
[ 423.141708] ? force_sig_fault+0xb3/0xf0
[ 423.145659] ? force_sigsegv+0x90/0x90
[ 423.149440] ? set_signal_archinfo+0x6f/0xa0
[ 423.153738] ? __do_page_fault+0x6b1/0x6d0
[ 423.157863] ? mm_fault_error+0x140/0x140
[ 423.161903] do_signal+0x93/0x9d0
[ 423.165244] ? lockdep_hardirqs_on+0x11/0x290
[ 423.169632] ? trace_hardirqs_on+0x9d/0x230
[ 423.173846] ? ftrace_destroy_function_files+0x50/0x50
[ 423.179022] ? do_raw_spin_trylock+0x180/0x180
[ 423.183498] ? setup_sigcontext+0x260/0x260
[ 423.187712] ? do_page_fault+0x119/0x53c
[ 423.191663] ? lockdep_hardirqs_on+0x11/0x290
[ 423.196050] ? trace_hardirqs_on+0x9d/0x230
[ 423.200264] ? ftrace_destroy_function_files+0x50/0x50
[ 423.205441] ? task_work_run+0x118/0x1a0
[ 423.209393] ? mark_held_locks+0x23/0xb0
[ 423.213345] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 423.217999] ? retint_user+0x18/0x18
[ 423.221602] exit_to_usermode_loop+0x130/0x170
[ 423.226081] ? lockdep_sys_exit_thunk+0x29/0x29
[ 423.230647] prepare_exit_to_usermode+0x1d7/0x1f0
[ 423.235387] ? syscall_slow_exit_work+0x380/0x380
[ 423.240127] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 423.244866] ? page_fault+0x5/0x20
[ 423.248294] retint_user+0x8/0x18
[ 423.251637] RIP: 0033:0x40f910
[ 423.254719] Code: Bad RIP value.
[ 423.257970] RSP: 002b:7f105ff5cec0 EFLAGS:
[PATCH 12/13] arm: dts: mediatek: Get rid of mediatek,larb for MM nodes
After adding device_link between the IOMMU consumer and smi, the mediatek,larb is unnecessary now. CC: Matthias Brugger Signed-off-by: Yong Wu --- arch/arm/boot/dts/mt2701.dtsi | 1 - arch/arm/boot/dts/mt7623.dtsi | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index 180377e..938fa31 100644 --- a/arch/arm/boot/dts/mt2701.dtsi +++ b/arch/arm/boot/dts/mt2701.dtsi @@ -563,7 +563,6 @@ clock-names = "jpgdec-smi", "jpgdec"; power-domains = < MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <>; iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>, < MT2701_M4U_PORT_JPGDEC_BSDMA>; }; diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi index d01bdee..c831398 100644 --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -774,7 +774,6 @@ clock-names = "jpgdec-smi", "jpgdec"; power-domains = < MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <>; iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>, < MT2701_M4U_PORT_JPGDEC_BSDMA>; }; -- 1.9.1
[PATCH 13/13] arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index abd2f15..8babd71 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -895,7 +895,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <>;
mediatek,vpu = <>;
};
@@ -906,7 +905,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <>;
};
mdp_rsz0: rsz@14003000 {
@@ -936,7 +934,6 @@
clocks = < CLK_MM_MDP_WDMA>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WDMA>;
- mediatek,larb = <>;
};
mdp_wrot0: wrot@14007000 {
@@ -945,7 +942,6 @@
clocks = < CLK_MM_MDP_WROT0>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT0>;
- mediatek,larb = <>;
};
mdp_wrot1: wrot@14008000 {
@@ -954,7 +950,6 @@
clocks = < CLK_MM_MDP_WROT1>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT1>;
- mediatek,larb = <>;
};
ovl0: ovl@1400c000 {
@@ -964,7 +959,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
};
ovl1: ovl@1400d000 {
@@ -974,7 +968,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
};
rdma0: rdma@1400e000 {
@@ -984,7 +977,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
};
rdma1: rdma@1400f000 {
@@ -994,7 +986,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
rdma2: rdma@1401 {
@@ -1004,7 +995,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
};
wdma0: wdma@14011000 {
@@ -1014,7 +1004,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
};
wdma1: wdma@14012000 {
@@ -1024,7 +1013,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
};
color0: color@14013000 {
@@ -1268,7 +1256,6 @@
<0 0x16027800 0 0x800>, /* VDEC_HWB */
<0 0x16028400 0 0x400>; /* VDEC_HWG */
interrupts = ;
- mediatek,larb = <>;
iommus = < M4U_PORT_HW_VDEC_MC_EXT>,
< M4U_PORT_HW_VDEC_PP_EXT>,
< M4U_PORT_HW_VDEC_AVC_MV_EXT>,
@@ -1329,8 +1316,6 @@
<0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
interrupts = ,
;
- mediatek,larb = <>,
- <>;
iommus = < M4U_PORT_VENC_RCPU>,
< M4U_PORT_VENC_REC>,
< M4U_PORT_VENC_BSDMA>,
--
1.9.1
[PATCH 10/13] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 14 --
include/soc/mediatek/smi.h | 20
2 files changed, 34 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 30930e4..a1dc34b 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -123,20 +123,6 @@ static void mtk_smi_clk_disable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_apb);
}
-int mtk_smi_larb_get(struct device *larbdev)
-{
- int ret = pm_runtime_get_sync(larbdev);
-
- return (ret < 0) ? ret : 0;
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
-
-void mtk_smi_larb_put(struct device *larbdev)
-{
- pm_runtime_put_sync(larbdev);
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
-
static int
mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
{
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 2b410d2..b993aa2 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -25,26 +25,6 @@ struct mtk_smi_iommu {
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
-/*
- * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
- * It also initialize some basic setting(like iommu).
- * mtk_smi_larb_put: Disable the power domain and clocks for this local
arbiter.
- * Both should be called in non-atomic context.
- *
- * Returns 0 if successful, negative on failure.
- */
-int mtk_smi_larb_get(struct device *larbdev);
-void mtk_smi_larb_put(struct device *larbdev);
-
-#else
-
-static inline int mtk_smi_larb_get(struct device *larbdev)
-{
- return 0;
-}
-
-static inline void mtk_smi_larb_put(struct device *larbdev) { }
-
#endif
#endif
--
1.9.1
[PATCH 11/13] iommu/mediatek: Use builtin_platform_driver
MediaTek IOMMU should wait for smi larb which need wait for the
power domain(mtk-scpsys.c) and the multimedia ccf who both are
module init. Thus, subsys_initcall for MediaTek IOMMU is not helpful.
Switch to builtin_platform_driver.
Meanwhile, the ".remove" can be removed. Move its content to
".shutdown".
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 23 ++-
drivers/iommu/mtk_iommu_v1.c | 16 ++--
2 files changed, 4 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 735ae8d..2798b12 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -690,7 +690,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, _iommu_com_ops, match);
}
-static int mtk_iommu_remove(struct platform_device *pdev)
+static void mtk_iommu_shutdown(struct platform_device *pdev)
{
struct mtk_iommu_data *data = platform_get_drvdata(pdev);
@@ -703,12 +703,6 @@ static int mtk_iommu_remove(struct platform_device *pdev)
clk_disable_unprepare(data->bclk);
devm_free_irq(>dev, data->irq, data);
component_master_del(>dev, _iommu_com_ops);
- return 0;
-}
-
-static void mtk_iommu_shutdown(struct platform_device *pdev)
-{
- mtk_iommu_remove(pdev);
}
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
@@ -791,7 +785,6 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
- .remove = mtk_iommu_remove,
.shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu",
@@ -799,16 +792,4 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.pm = _iommu_pm_ops,
}
};
-
-static int __init mtk_iommu_init(void)
-{
- int ret;
-
- ret = platform_driver_register(_iommu_driver);
- if (ret != 0)
- pr_err("Failed to register MTK IOMMU driver\n");
-
- return ret;
-}
-
-subsys_initcall(mtk_iommu_init)
+builtin_platform_driver(mtk_iommu_driver);
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 022bad9..5464918 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -648,7 +648,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, _iommu_com_ops, match);
}
-static int mtk_iommu_remove(struct platform_device *pdev)
+static void mtk_iommu_shutdown(struct platform_device *pdev)
{
struct mtk_iommu_data *data = platform_get_drvdata(pdev);
@@ -661,12 +661,6 @@ static int mtk_iommu_remove(struct platform_device *pdev)
clk_disable_unprepare(data->bclk);
devm_free_irq(>dev, data->irq, data);
component_master_del(>dev, _iommu_com_ops);
- return 0;
-}
-
-static void mtk_iommu_shutdown(struct platform_device *pdev)
-{
- mtk_iommu_remove(pdev);
}
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
@@ -705,7 +699,6 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
- .remove = mtk_iommu_remove,
.shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu-v1",
@@ -713,9 +706,4 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.pm = _iommu_pm_ops,
}
};
-
-static int __init m4u_init(void)
-{
- return platform_driver_register(_iommu_driver);
-}
-subsys_initcall(m4u_init);
+builtin_platform_driver(mtk_iommu_driver);
--
1.9.1
[PATCH 08/13] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
Signed-off-by: Yong Wu
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 19 ---
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 38 --
4 files changed, 61 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 79ca03a..90e1641 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
@@ -24,7 +23,6 @@
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
int ret = 0;
@@ -32,18 +30,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pdev = mtkdev->plat_dev;
pm = >pm;
pm->mtkdev = mtkdev;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- if (WARN_ON(!pdev)) {
- of_node_put(node);
- return -1;
- }
- pm->larbvdec = >dev;
pdev = mtkdev->plat_dev;
pm->dev = >dev;
@@ -181,16 +168,10 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
ret = clk_set_parent(pm->vdec_sel, pm->vdecpll);
if (ret)
mtk_v4l2_err("clk_set_parent vdec_sel vdecpll fail %d", ret);
-
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret)
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
-
}
void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
{
- mtk_smi_larb_put(pm->larbvdec);
clk_disable_unprepare(pm->vdec_sel);
clk_disable_unprepare(pm->vdecpll);
clk_disable_unprepare(pm->univpll_d2);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 3cffb38..2696e14 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -191,9 +191,6 @@ struct mtk_vcodec_pm {
struct clk *venc_sel;
struct clk *univpll1_d2;
struct clk *venc_lt_sel;
- struct device *larbvdec;
- struct device *larbvenc;
- struct device *larbvenclt;
struct device *dev;
struct mtk_vcodec_dev *mtkdev;
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 54631ad..7401619 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include "mtk_vcodec_drv.h"
#include "mtk_vcodec_enc.h"
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
index 3e73e9d..a3abd3d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include "mtk_vcodec_enc_pm.h"
#include "mtk_vcodec_util.h"
@@ -25,7 +24,6 @@
int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct device *dev;
struct mtk_vcodec_pm *pm;
@@ -38,31 +36,6 @@ int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
pm->dev = >dev;
dev = >dev;
- node = of_parse_phandle(dev->of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("no mediatek,larb found");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- if (!pdev) {
- mtk_v4l2_err("no mediatek,larb device found");
- return -1;
- }
- pm->larbvenc = >dev;
-
- node = of_parse_phandle(dev->of_node, "mediatek,larb", 1);
- if (!node) {
- mtk_v4l2_err("no mediatek,larb found");
- return -1;
- }
-
- pdev = of_find_device_by_node(node);
- if (!pdev) {
- mtk_v4l2_err("no mediatek,larb device found");
- return -1;
- }
-
- pm->larbvenclt = >dev;
pdev = mtkdev->plat_dev;
pm->dev = >dev;
@@ -117,21 +90,10 @@ void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm)
ret =
[PATCH 05/13] memory: mtk-smi: Add device-link between smi-larb and smi-common
Normally, If the smi-larb HW need work, we should enable the smi-common
HW power and clock firstly.
This patch adds device-link between the smi-larb dev and the smi-common
dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
(smi-common-dev) will be called automatically.
Since smi is built-in driver like IOMMU and never unbound,
DL_FLAG_AUTOREMOVE_* is not needed.
CC: Matthias Brugger
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 9688341..30930e4 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -271,6 +271,7 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *smi_node;
struct platform_device *smi_pdev;
+ struct device_link *link;
larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
if (!larb)
@@ -310,6 +311,12 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
if (!platform_get_drvdata(smi_pdev))
return -EPROBE_DEFER;
larb->smi_common_dev = _pdev->dev;
+ link = device_link_add(dev, larb->smi_common_dev,
+ DL_FLAG_PM_RUNTIME);
+ if (!link) {
+ dev_err(dev, "Unable to link smi-common dev\n");
+ return -ENODEV;
+ }
} else {
dev_err(dev, "Failed to get the smi_common device\n");
return -EINVAL;
@@ -333,17 +340,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct
device *dev)
const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
int ret;
- /* Power on smi-common. */
- ret = pm_runtime_get_sync(larb->smi_common_dev);
- if (ret < 0) {
- dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
- return ret;
- }
-
ret = mtk_smi_clk_enable(>smi);
if (ret < 0) {
dev_err(dev, "Failed to enable clock(%d).\n", ret);
- pm_runtime_put_sync(larb->smi_common_dev);
return ret;
}
@@ -358,7 +357,6 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
device *dev)
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
mtk_smi_clk_disable(>smi);
- pm_runtime_put_sync(larb->smi_common_dev);
return 0;
}
--
1.9.1
[PATCH 06/13] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Rick Chang
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 22 --
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 --
2 files changed, 24 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 2a5d500..23da32c 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include "mtk_jpeg_hw.h"
#include "mtk_jpeg_core.h"
@@ -901,11 +900,6 @@ static int mtk_jpeg_queue_init(void *priv, struct
vb2_queue *src_vq,
static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
{
- int ret;
-
- ret = mtk_smi_larb_get(jpeg->larb);
- if (ret)
- dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
clk_prepare_enable(jpeg->clk_jdec_smi);
clk_prepare_enable(jpeg->clk_jdec);
}
@@ -914,7 +908,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
clk_disable_unprepare(jpeg->clk_jdec);
clk_disable_unprepare(jpeg->clk_jdec_smi);
- mtk_smi_larb_put(jpeg->larb);
}
static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
@@ -1059,21 +1052,6 @@ static int mtk_jpeg_release(struct file *file)
static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
{
- struct device_node *node;
- struct platform_device *pdev;
-
- node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
- if (!node)
- return -EINVAL;
- pdev = of_find_device_by_node(node);
- if (WARN_ON(!pdev)) {
- of_node_put(node);
- return -EINVAL;
- }
- of_node_put(node);
-
- jpeg->larb = >dev;
-
jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
if (IS_ERR(jpeg->clk_jdec))
return PTR_ERR(jpeg->clk_jdec);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 1a6cdfd..e35fb79 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -55,7 +55,6 @@ enum mtk_jpeg_ctx_state {
* @dec_reg_base: JPEG registers mapping
* @clk_jdec: JPEG hw working clock
* @clk_jdec_smi: JPEG SMI bus clock
- * @larb: SMI device
*/
struct mtk_jpeg_dev {
struct mutexlock;
@@ -69,7 +68,6 @@ struct mtk_jpeg_dev {
void __iomem*dec_reg_base;
struct clk *clk_jdec;
struct clk *clk_jdec_smi;
- struct device *larb;
};
/**
--
1.9.1
[PATCH 09/13] drm/mediatek: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 11 ---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 26 --
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 -
3 files changed, 38 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 92ecb9b..fbf859e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include "mtk_drm_drv.h"
#include "mtk_drm_crtc.h"
@@ -371,20 +370,12 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
struct drm_crtc_state *old_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
int ret;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
- ret = mtk_smi_larb_get(comp->larb_dev);
- if (ret) {
- DRM_ERROR("Failed to get larb: %d\n", ret);
- return;
- }
-
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
- mtk_smi_larb_put(comp->larb_dev);
return;
}
@@ -396,7 +387,6 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
struct drm_crtc_state *old_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
int i;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
@@ -419,7 +409,6 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
- mtk_smi_larb_put(comp->larb_dev);
mtk_crtc->enabled = false;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 54ca794..ede15c9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -265,8 +265,6 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
const struct mtk_ddp_comp_funcs *funcs)
{
enum mtk_ddp_comp_type type;
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
return -EINVAL;
@@ -296,30 +294,6 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
if (IS_ERR(comp->clk))
return PTR_ERR(comp->clk);
- /* Only DMA capable components need the LARB property */
- comp->larb_dev = NULL;
- if (type != MTK_DISP_OVL &&
- type != MTK_DISP_RDMA &&
- type != MTK_DISP_WDMA)
- return 0;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev,
- "Missing mediadek,larb phandle in %pOF node\n", node);
- return -EINVAL;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- return -EPROBE_DEFER;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = _pdev->dev;
-
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 8399229..b8dc17e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -91,7 +91,6 @@ struct mtk_ddp_comp {
struct clk *clk;
void __iomem *regs;
int irq;
- struct device *larb_dev;
enum mtk_ddp_comp_id id;
const struct mtk_ddp_comp_funcs *funcs;
};
--
1.9.1
[PATCH 07/13] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 38 ---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 --
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
3 files changed, 41 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 03aba03..4f7cbc4 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_comp.h"
@@ -66,14 +65,6 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
{
int i, err;
- if (comp->larb_dev) {
- err = mtk_smi_larb_get(comp->larb_dev);
- if (err)
- dev_err(dev,
- "failed to get larb, err %d. type:%d id:%d\n",
- err, comp->type, comp->id);
- }
-
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
if (IS_ERR(comp->clk[i]))
continue;
@@ -94,16 +85,11 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
mtk_mdp_comp *comp)
continue;
clk_disable_unprepare(comp->clk[i]);
}
-
- if (comp->larb_dev)
- mtk_smi_larb_put(comp->larb_dev);
}
int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
int i;
if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
@@ -124,30 +110,6 @@ int mtk_mdp_comp_init(struct device *dev, struct
device_node *node,
break;
}
- /* Only DMA capable components need the LARB property */
- comp->larb_dev = NULL;
- if (comp->type != MTK_MDP_RDMA &&
- comp->type != MTK_MDP_WDMA &&
- comp->type != MTK_MDP_WROT)
- return 0;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev,
- "Missing mediadek,larb phandle in %pOF node\n", node);
- return -EINVAL;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- return -EPROBE_DEFER;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = _pdev->dev;
-
return 0;
}
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 63b3983..602d577 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -47,7 +47,6 @@ enum mtk_mdp_comp_id {
* @dev_node: component device node
* @clk: clocks required for component
* @regs: Mapped address of component registers.
- * @larb_dev: SMI device required for component
* @type: component type
* @id:component ID
*/
@@ -55,7 +54,6 @@ struct mtk_mdp_comp {
struct device_node *dev_node;
struct clk *clk[2];
void __iomem*regs;
- struct device *larb_dev;
enum mtk_mdp_comp_type type;
enum mtk_mdp_comp_idid;
};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index bbb24fb..adb098d 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_core.h"
#include "mtk_mdp_m2m.h"
--
1.9.1
[PATCH 04/13] iommu/mediatek: Add device_link between the consumer and the larb devices
MediaTek IOMMU don't have its power-domain. all the consumer connect
with smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 15 +--
drivers/iommu/mtk_iommu_v1.c | 14 --
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 202e41b..735ae8d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -247,6 +247,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
struct mtk_smi_larb_iommu*larb_mmu;
unsigned int larbid, portid;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct device_link *link;
int i;
for (i = 0; i < fwspec->num_ids; ++i) {
@@ -257,10 +258,20 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
dev_dbg(dev, "%s iommu port: %d\n",
enable ? "enable" : "disable", portid);
- if (enable)
+ if (enable) {
larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
- else
+ /* Link the consumer with the larb device(supplier) */
+ link = device_link_add(dev, larb_mmu->dev,
+ DL_FLAG_PM_RUNTIME |
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link) {
+ dev_err(dev, "Unable to link %s\n",
+ dev_name(larb_mmu->dev));
+ return;
+ }
+ } else {
larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid);
+ }
}
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 9386aee..022bad9 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -201,6 +201,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
struct mtk_smi_larb_iommu*larb_mmu;
unsigned int larbid, portid;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct device_link *link;
int i;
for (i = 0; i < fwspec->num_ids; ++i) {
@@ -211,10 +212,19 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
dev_dbg(dev, "%s iommu port: %d\n",
enable ? "enable" : "disable", portid);
- if (enable)
+ if (enable) {
larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
- else
+ link = device_link_add(dev, larb_mmu->dev,
+ DL_FLAG_PM_RUNTIME |
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link) {
+ dev_err(dev, "Unable to link %s\n",
+ dev_name(larb_mmu->dev));
+ return;
+ }
+ } else {
larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid);
+ }
}
}
--
1.9.1
[PATCH 03/13] iommu/mediatek: Add probe_defer for smi-larb
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.
This is a preparing patch for adding device_link.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 36526c9..202e41b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -645,7 +645,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
id = i;
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev)
+ if (!plarbdev || !plarbdev->dev.driver)
return -EPROBE_DEFER;
data->smi_imu.larb_imu[id].dev = >dev;
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index f8b8275..9386aee 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -601,7 +601,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
plarbdev = of_platform_device_create(
larb_spec.np, NULL,
platform_bus_type.dev_root);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larb_spec.np);
return -EPROBE_DEFER;
}
--
1.9.1
[PATCH 01/13] dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
---
I guess it should go through Matthias's tree if the patch is ok,
thus I don't separate to different patches. If it's really needed,
please feel free to tell me.
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.txt | 4
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8
Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 4
4 files changed, 25 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 8469de5..464b92f 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -56,8 +56,6 @@ Required properties (DMA function blocks):
"mediatek,-disp-rdma"
"mediatek,-disp-wdma"
the supported chips are mt2701 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as
defined
- in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -78,7 +76,6 @@ ovl0: ovl@1400c000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
};
ovl1: ovl@1400d000 {
@@ -88,7 +85,6 @@ ovl1: ovl@1400d000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
};
rdma0: rdma@1400e000 {
@@ -98,7 +94,6 @@ rdma0: rdma@1400e000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
};
rdma1: rdma@1400f000 {
@@ -108,7 +103,6 @@ rdma1: rdma@1400f000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
rdma2: rdma@1401 {
@@ -118,7 +112,6 @@ rdma2: rdma@1401 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
};
wdma0: wdma@14011000 {
@@ -128,7 +121,6 @@ wdma0: wdma@14011000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
};
wdma1: wdma@14012000 {
@@ -138,7 +130,6 @@ wdma1: wdma@14012000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
};
color0: color@14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index 044b119..7978f21 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -15,9 +15,6 @@ Required properties:
- clock-names: must contain "jpgdec-smi" and "jpgdec".
- power-domains: a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
-- mediatek,larb: must contain the local arbiters in the current Socs, see
- Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -32,7 +29,6 @@ Example:
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index 0d03e3a..df69c5a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -27,9 +27,6 @@ Required properties (DMA function blocks, child node):
- iommus: should point to the respective IOMMU block with master port as
argument, see
[PATCH 00/13] Clean up "mediatek,larb" after adding device_link
MediaTek IOMMU block diagram always like below: M4U | smi-common | - | | ... | | larb1 larb2 | | vdec venc All the consumer connect with smi-larb, then connect with smi-common. MediaTek IOMMU don't have its power-domain. When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, Firstly, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. The ref_count of the device_link normally is over 1, when the consumer device driver is removed, we should remove all the device_link, Hence, I add the patch "driver core: xxx" at the beginning of this patchset. After adding the device_link, then "mediatek,larb" property can be removed. the iommu consumer don't need call the mtk_smi_larb_get/put to enable the power and clock of smi-larb and smi-common. This patchset depends on "MT8183 IOMMU SUPPORT"[1]. [1] https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032387.html Yong Wu (13): dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW driver core: Remove the link if there is no driver with AUTO flag iommu/mediatek: Add probe_defer for smi-larb iommu/mediatek: Add device_link between the consumer and the larb devices memory: mtk-smi: Add device-link between smi-larb and smi-common media: mtk-jpeg: Get rid of mtk_smi_larb_get/put media: mtk-mdp: Get rid of mtk_smi_larb_get/put media: mtk-vcodec: Get rid of mtk_smi_larb_get/put drm/mediatek: Get rid of mtk_smi_larb_get/put memory: mtk-smi: Get rid of mtk_smi_larb_get/put iommu/mediatek: Use builtin_platform_driver arm: dts: mediatek: Get rid of mediatek,larb for MM nodes arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes .../bindings/display/mediatek/mediatek,disp.txt| 9 - .../bindings/media/mediatek-jpeg-decoder.txt | 4 --- .../devicetree/bindings/media/mediatek-mdp.txt | 8 - .../devicetree/bindings/media/mediatek-vcodec.txt | 4 --- arch/arm/boot/dts/mt2701.dtsi | 1 - arch/arm/boot/dts/mt7623.dtsi | 1 - arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 drivers/base/core.c| 4 +-- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 11 -- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 26 -- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 1 - drivers/iommu/mtk_iommu.c | 40 +- drivers/iommu/mtk_iommu_v1.c | 32 - drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 22 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h| 2 -- drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 38 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 -- drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 - .../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 19 -- drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 3 -- drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 - .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 38 drivers/memory/mtk-smi.c | 30 include/soc/mediatek/smi.h | 20 --- 24 files changed, 40 insertions(+), 292 deletions(-) -- 1.9.1
[PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag
DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link automatically on consumer/supplier driver unbind", that means we should remove whole the device_link when there is no this driver no matter what the ref_count of the link is. CC: Greg Kroah-Hartman Signed-off-by: Yong Wu --- The ref_count of our device_link normally is over 1. When the consumer device driver is removed, whole the device_link should be removed. Thus, I add this patch. --- drivers/base/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 04bbcd7..4f3c5bc 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -511,7 +511,7 @@ static void __device_links_no_driver(struct device *dev) continue; if (link->flags & DL_FLAG_AUTOREMOVE_CONSUMER) - kref_put(>kref, __device_link_del); + __device_link_del(>kref); else if (link->status != DL_STATE_SUPPLIER_UNBIND) WRITE_ONCE(link->status, DL_STATE_AVAILABLE); } @@ -556,7 +556,7 @@ void device_links_driver_cleanup(struct device *dev) */ if (link->status == DL_STATE_SUPPLIER_UNBIND && link->flags & DL_FLAG_AUTOREMOVE_SUPPLIER) - kref_put(>kref, __device_link_del); + __device_link_del(>kref); WRITE_ONCE(link->status, DL_STATE_DORMANT); } -- 1.9.1
[PATCH v5 19/20] iommu/mediatek: Add shutdown callback
In the reboot burning test, if some Multimedia HW has something wrong,
It may keep send the invalid request to IOMMU. In order to avoid
affect the reboot flow, we add the shutdown callback to disable
M4U HW when shutdown.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 6 ++
drivers/iommu/mtk_iommu_v1.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ddf1969..dcb02e3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -703,6 +703,11 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
+static void mtk_iommu_shutdown(struct platform_device *pdev)
+{
+ mtk_iommu_remove(pdev);
+}
+
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -784,6 +789,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
+ .shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu",
.of_match_table = of_match_ptr(mtk_iommu_of_ids),
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 6ede428..517dfbd 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -662,6 +662,11 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
+static void mtk_iommu_shutdown(struct platform_device *pdev)
+{
+ mtk_iommu_remove(pdev);
+}
+
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -699,6 +704,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
+ .shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu-v1",
.of_match_table = mtk_iommu_of_ids,
--
1.9.1
[PATCH v5 20/20] iommu/mediatek: Switch to SPDX license identifier
Switch to SPDX license identifier for MediaTek iommu/smi and their header files. Signed-off-by: Yong Wu Reviewed-by: Rob Herring --- drivers/iommu/mtk_iommu.c | 10 +- drivers/iommu/mtk_iommu.h | 10 +- drivers/iommu/mtk_iommu_v1.c | 10 +- drivers/memory/mtk-smi.c | 10 +- include/dt-bindings/memory/mt2701-larb-port.h | 10 +- include/dt-bindings/memory/mt8173-larb-port.h | 10 +- include/soc/mediatek/smi.h| 10 +- 7 files changed, 7 insertions(+), 63 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index dcb02e3..36526c9 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -1,15 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h index c500bfd..e09f2220 100644 --- a/drivers/iommu/mtk_iommu.h +++ b/drivers/iommu/mtk_iommu.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Honghui Zhang - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef _MTK_IOMMU_H_ diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index 517dfbd..f8b8275 100644 --- a/drivers/iommu/mtk_iommu_v1.c +++ b/drivers/iommu/mtk_iommu_v1.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * IOMMU API for MTK architected m4u v1 implementations * @@ -5,15 +6,6 @@ * Author: Honghui Zhang * * Based on driver/iommu/mtk_iommu.c - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index 10e6493..9688341 100644 --- a/drivers/memory/mtk-smi.c +++ b/drivers/memory/mtk-smi.c @@ -1,15 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h index 6764d74..c511f0f 100644 --- a/include/dt-bindings/memory/mt2701-larb-port.h +++ b/include/dt-bindings/memory/mt2701-larb-port.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015 MediaTek Inc. * Author: Honghui Zhang - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef _MT2701_LARB_PORT_H_ diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h index 111b4b0..a62bfeb 100644 --- a/include/dt-bindings/memory/mt8173-larb-port.h +++ b/include/dt-bindings/memory/mt8173-larb-port.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu - * - * This
[PATCH v5 14/20] iommu/mediatek: Add mmu1 support
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-
||| |...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in the M4U HW, like this diagram:
EMI
-
| |
mmu0 mmu1 <- M4U
| |
-
|
smi-common
|
-
||| |...
larb0 larb1 larb2 larb3
This patch add support for mmu1. In order to get better performance,
we could adjust some larbs go to mmu1 while the others still go to
mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
value of that register is 0 which means all the larbs go to mmu0
defaultly.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 47 +--
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 66e3615..7fcef19 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -70,27 +70,32 @@
#define F_MISS_FIFO_ERR_INT_EN BIT(6)
#define F_INT_CLR_BIT BIT(12)
-#define REG_MMU_INT_MAIN_CONTROL 0x124
-#define F_INT_TRANSLATION_FAULTBIT(0)
-#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
-#define F_INT_INVALID_PA_FAULT BIT(2)
-#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
-#define F_INT_TLB_MISS_FAULT BIT(4)
-#define F_INT_MISS_TRANSACTION_FIFO_FAULT BIT(5)
-#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
+#define REG_MMU_INT_MAIN_CONTROL 0x124 /* mmu0 | mmu1 */
+#define F_INT_TRANSLATION_FAULT(BIT(0) | BIT(7))
+#define F_INT_MAIN_MULTI_HIT_FAULT (BIT(1) | BIT(8))
+#define F_INT_INVALID_PA_FAULT (BIT(2) | BIT(9))
+#define F_INT_ENTRY_REPLACEMENT_FAULT (BIT(3) | BIT(10))
+#define F_INT_TLB_MISS_FAULT (BIT(4) | BIT(11))
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT (BIT(5) | BIT(12))
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT (BIT(6) | BIT(13))
#define REG_MMU_CPE_DONE 0x12C
#define REG_MMU_FAULT_ST1 0x134
+#define F_REG_MMU0_FAULT_MASK GENMASK(6, 0)
+#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
-#define REG_MMU_FAULT_VA 0x13c
+#define REG_MMU0_FAULT_VA 0x13c
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
-#define REG_MMU_INVLD_PA 0x140
-#define REG_MMU_INT_ID 0x150
-#define F_MMU0_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
-#define F_MMU0_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
+#define REG_MMU0_INVLD_PA 0x140
+#define REG_MMU1_FAULT_VA 0x144
+#define REG_MMU1_INVLD_PA 0x148
+#define REG_MMU0_INT_ID0x150
+#define REG_MMU1_INT_ID0x154
+#define F_MMU_INT_ID_LARB_ID(a)(((a) >> 7) & 0x7)
+#define F_MMU_INT_ID_PORT_ID(a)(((a) >> 2) & 0x1f)
#define MTK_PROTECT_PA_ALIGN 128
@@ -209,13 +214,19 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
/* Read error info from registers */
int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
- fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+ if (int_state & F_REG_MMU0_FAULT_MASK) {
+ regval = readl_relaxed(data->base + REG_MMU0_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU0_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU0_INVLD_PA);
+ } else {
+ regval = readl_relaxed(data->base + REG_MMU1_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU1_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU1_INVLD_PA);
+ }
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
- fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
- regval = readl_relaxed(data->base + REG_MMU_INT_ID);
- fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
- fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ fault_port = F_MMU_INT_ID_PORT_ID(regval);
fault_larb = data->plat_data->larbid_remap[fault_larb];
--
1.9.1
[PATCH v5 18/20] iommu/mediatek: Fix VLD_PA_RANGE register backup when suspend
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 7fcef19..ddf1969 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -716,6 +716,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
*dev)
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
+ reg->vld_pa_range = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -740,6 +741,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
+ writel_relaxed(reg->vld_pa_range, base + REG_MMU_VLD_PA_RNG);
if (m4u_dom)
writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 0a7c463..c500bfd 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -33,6 +33,7 @@ struct mtk_iommu_suspend_reg {
u32 int_control0;
u32 int_main_control;
u32 ivrp_paddr;
+ u32 vld_pa_range;
};
enum mtk_iommu_plat {
--
1.9.1
[PATCH v5 16/20] memory: mtk-smi: Add bus_sel for mt8183
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In mt8173 and mt2712, we don't get the performance issue,
Keep its default value(0x0), that means all the larbs enter mmu0.
Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 9790801..08cf40d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,12 @@
#define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+/* SMI COMMON */
+#define SMI_BUS_SEL0x220
+#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
+/* All are MMU0 defaultly. Only specialize mmu1 here. */
+#define F_MMU1_LARB(larbid)(0x1 << SMI_BUS_LARB_SHIFT(larbid))
+
enum mtk_smi_gen {
MTK_SMI_GEN1,
MTK_SMI_GEN2
@@ -57,6 +63,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
bool has_gals;
+ u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
};
struct mtk_smi_larb_gen {
@@ -72,8 +79,8 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
- void __iomem*smi_ao_base;
-
+ void __iomem*smi_ao_base; /* only for gen1 */
+ void __iomem*base;/* only for gen2 */
const struct mtk_smi_common_plat *plat;
};
@@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
device *dev)
static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
.gen = MTK_SMI_GEN2,
.has_gals = true,
+ .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
+ F_MMU1_LARB(7),
};
static const struct of_device_id mtk_smi_common_of_ids[] = {
@@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
ret = clk_prepare_enable(common->clk_async);
if (ret)
return ret;
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ common->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(common->base))
+ return PTR_ERR(common->base);
}
pm_runtime_enable(dev);
platform_set_drvdata(pdev, common);
@@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct platform_device
*pdev)
static int __maybe_unused mtk_smi_common_resume(struct device *dev)
{
struct mtk_smi *common = dev_get_drvdata(dev);
+ u32 bus_sel = common->plat->bus_sel;
int ret;
ret = mtk_smi_clk_enable(common);
@@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
device *dev)
dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
return ret;
}
+
+ if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
+ writel(bus_sel, common->base + SMI_BUS_SEL);
return 0;
}
--
1.9.1
[PATCH v5 15/20] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives a chance to get rid of mtk_smi_larb_get/put which could
be a next topic.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 113 ++-
1 file changed, 72 insertions(+), 41 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index a430721..9790801 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -86,17 +86,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-static int mtk_smi_enable(const struct mtk_smi *smi)
+static int mtk_smi_clk_enable(const struct mtk_smi *smi)
{
int ret;
- ret = pm_runtime_get_sync(smi->dev);
- if (ret < 0)
- return ret;
-
ret = clk_prepare_enable(smi->clk_apb);
if (ret)
- goto err_put_pm;
+ return ret;
ret = clk_prepare_enable(smi->clk_smi);
if (ret)
@@ -118,59 +114,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
-err_put_pm:
- pm_runtime_put_sync(smi->dev);
return ret;
}
-static void mtk_smi_disable(const struct mtk_smi *smi)
+static void mtk_smi_clk_disable(const struct mtk_smi *smi)
{
clk_disable_unprepare(smi->clk_gals1);
clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
- pm_runtime_put_sync(smi->dev);
}
int mtk_smi_larb_get(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
- int ret;
+ int ret = pm_runtime_get_sync(larbdev);
- /* Enable the smi-common's power and clocks */
- ret = mtk_smi_enable(common);
- if (ret)
- return ret;
-
- /* Enable the larb's power and clocks */
- ret = mtk_smi_enable(>smi);
- if (ret) {
- mtk_smi_disable(common);
- return ret;
- }
-
- /* Configure the iommu info for this larb */
- larb_gen->config_port(larbdev);
-
- return 0;
+ return (ret < 0) ? ret : 0;
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
void mtk_smi_larb_put(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
-
- /*
-* Don't de-configure the iommu info for this larb since there may be
-* several modules in this larb.
-* The iommu info will be reset after power off.
-*/
-
- mtk_smi_disable(>smi);
- mtk_smi_disable(common);
+ pm_runtime_put_sync(larbdev);
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
@@ -385,12 +350,52 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
+ int ret;
+
+ /* Power on smi-common. */
+ ret = pm_runtime_get_sync(larb->smi_common_dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
+ return ret;
+ }
+
+ ret = mtk_smi_clk_enable(>smi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable clock(%d).\n", ret);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return ret;
+ }
+
+ /* Configure the basic setting for this larb */
+ larb_gen->config_port(dev);
+
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(>smi);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_larb_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_larb_suspend, mtk_smi_larb_resume, NULL)
+};
+
static struct platform_driver mtk_smi_larb_driver = {
.probe = mtk_smi_larb_probe,
.remove = mtk_smi_larb_remove,
.driver = {
.name = "mtk-smi-larb",
.of_match_table = mtk_smi_larb_of_ids,
+ .pm = _larb_pm_ops,
}
};
@@ -489,12 +494,38 @@ static int mtk_smi_common_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused mtk_smi_common_resume(struct device *dev)
+{
+
[PATCH v5 13/20] iommu/mediatek: Add mt8183 IOMMU support
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
the ARM Short-descriptor like mt8173, and most of the HW registers
are the same.
Here list main differences between mt8183 and mt8173/mt2712:
1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
mode".
4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
the bit[33:32] in the physical address of the pgtable base, But the
standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
we add a mask.
5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
6) mt8183 need reset_axi like mt8173.
7) the larb-id in smi-common is remapped. M4U should add its larbid_remap.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 15 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 20
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2913ddb..66e3615 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -36,6 +36,7 @@
#include "mtk_iommu.h"
#define REG_MMU_PT_BASE_ADDR 0x000
+#define MMU_PT_ADDR_MASK GENMASK(31, 7)
#define REG_MMU_INVALIDATE 0x020
#define F_ALL_INVLD0x2
@@ -342,7 +343,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
data->m4u_dom = dom;
- writel(dom->cfg.arm_v7s_cfg.ttbr[0],
+ writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
}
@@ -712,6 +713,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = >reg;
+ struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
void __iomem *base = data->base;
int ret;
@@ -727,8 +729,8 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
- if (data->m4u_dom)
- writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+ if (m4u_dom)
+ writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
return 0;
}
@@ -753,9 +755,16 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
+static const struct mtk_iommu_plat_data mt8183_data = {
+ .m4u_plat = M4U_MT8183,
+ .reset_axi= true,
+ .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt2712-m4u", .data = _data},
{ .compatible = "mediatek,mt8173-m4u", .data = _data},
+ { .compatible = "mediatek,mt8183-m4u", .data = _data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index a8c5d1e..0a7c463 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -39,6 +39,7 @@ enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
M4U_MT8173,
+ M4U_MT8183,
};
struct mtk_iommu_plat_data {
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 91634d7..a430721 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -285,6 +285,13 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
+ .has_gals = true,
+ .config_port= mtk_smi_larb_config_port_gen2_general,
+ .larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),
+ /* IPU0 | IPU1 | CCU */
+};
+
static const struct of_device_id mtk_smi_larb_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-larb",
@@ -298,6 +305,10 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
.compatible = "mediatek,mt2712-smi-larb",
.data = _smi_larb_mt2712
},
+ {
+ .compatible = "mediatek,mt8183-smi-larb",
+ .data = _smi_larb_mt8183
+ },
{}
};
@@ -391,6 +402,11 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
.gen = MTK_SMI_GEN2,
};
+static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
+ .gen = MTK_SMI_GEN2,
[PATCH v5 17/20] memory: mtk-smi: Get rid of need_larbid
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
It's no need to parse it again in SMI driver. Only clean some codes.
This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
and mt8183.
After this patch, the "mediatek,larb-id" only be needed for mt2712
which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U
in which the larbs in the "mediatek,larbs" always are ordered.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 08cf40d..10e6493 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -67,7 +67,6 @@ struct mtk_smi_common_plat {
};
struct mtk_smi_larb_gen {
- bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
@@ -153,18 +152,9 @@ void mtk_smi_larb_put(struct device *larbdev)
struct mtk_smi_iommu *smi_iommu = data;
unsigned int i;
- if (larb->larb_gen->need_larbid) {
- larb->mmu = _iommu->larb_imu[larb->larbid].mmu;
- return 0;
- }
-
- /*
-* If there is no larbid property, Loop to find the corresponding
-* iommu information.
-*/
- for (i = 0; i < smi_iommu->larb_nr; i++) {
+ for (i = 0; i < MTK_LARB_NR_MAX; i++) {
if (dev == smi_iommu->larb_imu[i].dev) {
- /* The 'mmu' may be updated in iommu-attach/detach. */
+ larb->larbid = i;
larb->mmu = _iommu->larb_imu[i].mmu;
return 0;
}
@@ -243,7 +233,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {
- .need_larbid = true,
.port_in_larb = {
LARB0_PORT_OFFSET, LARB1_PORT_OFFSET,
LARB2_PORT_OFFSET, LARB3_PORT_OFFSET
@@ -252,7 +241,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
- .need_larbid = true,
.config_port= mtk_smi_larb_config_port_gen2_general,
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
@@ -291,7 +279,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *smi_node;
struct platform_device *smi_pdev;
- int err;
larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
if (!larb)
@@ -321,15 +308,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
}
larb->smi.dev = dev;
- if (larb->larb_gen->need_larbid) {
- err = of_property_read_u32(dev->of_node, "mediatek,larb-id",
- >larbid);
- if (err) {
- dev_err(dev, "missing larbid property\n");
- return err;
- }
- }
-
smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
if (!smi_node)
return -EINVAL;
--
1.9.1
[PATCH v5 08/20] iommu/mediatek: Add larb-id remapped support
The larb-id may be remapped in the smi-common, this means the
larb-id reported in the mtk_iommu_isr isn't the real larb-id,
Take mt8183 as a example:
M4U
|
-
| SMI common |
-0-7-5-6-1-2--3-4- <- Id remapped
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc imgcam
As above, larb0 connects with the id 0 in smi-common.
larb1 connects with the id 7 in smi-common.
...
If the larb-id reported in the isr is 7, actually it's larb1(vdec).
In order to output the right larb-id in the isr, we add a larb-id
remapping relationship in this patch.
If there is no this larb-id remapping in some SoCs, use the linear
mapping array instead.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 4
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 847082c..eca1536 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -220,6 +220,8 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = data->plat_data->larbid_remap[fault_larb];
+
if (report_iommu_fault(>domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
@@ -742,12 +744,14 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b8749ac..eec19a6 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,8 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
+
+ unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
struct mtk_iommu_domain;
--
1.9.1
[PATCH v5 12/20] memory: mtk-smi: Add gals support
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
--
||
gals0-rx gals1-rx
||
||
gals0-tx gals1-tx
||
SMI Common
|
+-++-+- ...
| || |
| gals-rx gals-rx |
| || |
| || |
| gals-tx gals-tx |
| || |
larb1 larb2 larb3 larb4
GALS only help transfer the command/data while it doesn't have the
configuring register, thus it has the special "smi" clock and doesn't
have the "apb" clock. From the diagram above, we add "gals0" and
"gals1" clocks for smi-common and add a "gals" clock for smi-larb.
This patch adds gals clock supporting in the SMI. Note that some larbs
may still don't have the "gals" clock like larb1 and larb4 above.
This is also a preparing patch for mt8183 which has GALS.
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8a2f968..91634d7 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -56,6 +56,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
+ bool has_gals;
};
struct mtk_smi_larb_gen {
@@ -63,11 +64,13 @@ struct mtk_smi_larb_gen {
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
+ bool has_gals;
};
struct mtk_smi {
struct device *dev;
struct clk *clk_apb, *clk_smi;
+ struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem*smi_ao_base;
@@ -99,8 +102,20 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
if (ret)
goto err_disable_apb;
+ ret = clk_prepare_enable(smi->clk_gals0);
+ if (ret)
+ goto err_disable_smi;
+
+ ret = clk_prepare_enable(smi->clk_gals1);
+ if (ret)
+ goto err_disable_gals0;
+
return 0;
+err_disable_gals0:
+ clk_disable_unprepare(smi->clk_gals0);
+err_disable_smi:
+ clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
err_put_pm:
@@ -110,6 +125,8 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
static void mtk_smi_disable(const struct mtk_smi *smi)
{
+ clk_disable_unprepare(smi->clk_gals1);
+ clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
pm_runtime_put_sync(smi->dev);
@@ -310,6 +327,15 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
larb->smi.clk_smi = devm_clk_get(dev, "smi");
if (IS_ERR(larb->smi.clk_smi))
return PTR_ERR(larb->smi.clk_smi);
+
+ if (larb->larb_gen->has_gals) {
+ /* The larbs may still haven't gals even if the SoC support.*/
+ larb->smi.clk_gals0 = devm_clk_get(dev, "gals");
+ if (PTR_ERR(larb->smi.clk_gals0) == -ENOENT)
+ larb->smi.clk_gals0 = NULL;
+ else if (IS_ERR(larb->smi.clk_gals0))
+ return PTR_ERR(larb->smi.clk_gals0);
+ }
larb->smi.dev = dev;
if (larb->larb_gen->need_larbid) {
@@ -402,6 +428,16 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
if (IS_ERR(common->clk_smi))
return PTR_ERR(common->clk_smi);
+ if (common->plat->has_gals) {
+ common->clk_gals0 = devm_clk_get(dev, "gals0");
+ if (IS_ERR(common->clk_gals0))
+ return PTR_ERR(common->clk_gals0);
+
+ common->clk_gals1 = devm_clk_get(dev, "gals1");
+ if (IS_ERR(common->clk_gals1))
+ return PTR_ERR(common->clk_gals1);
+ }
+
/*
* for mtk smi gen 1, we need to get the ao(always on) base to config
* m4u port, and we need to enable the aync clock for transform the smi
--
1.9.1
[PATCH v5 11/20] iommu/mediatek: Move vld_pa_rng into plat_data
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
range) register while mt2712 have. Move it into the plat_data.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8d8ab21..2913ddb 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -548,7 +548,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->vld_pa_rng) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1__ to 0x1__. here record bit[32:30].
@@ -741,6 +741,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .vld_pa_rng = true,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b46aeaa..a8c5d1e 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -48,6 +48,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
boolreset_axi;
+ boolvld_pa_rng;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
1.9.1
[PATCH v5 10/20] iommu/mediatek: Move reset_axi into plat_data
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while
it is extended to REG_MMU_CTRL which contains _STANDARD_AXI_MODE in
the other SoCs. I move this property to plat_data since both mt8173
and mt8183 use this property.
It is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 4 ++--
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 35a1263..8d8ab21 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -558,8 +558,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- /* It's MISC control register whose default value is ok except mt8173.*/
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->reset_axi)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -749,6 +748,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .reset_axi= true,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index eec19a6..b46aeaa 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,7 +47,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
-
+ boolreset_axi;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
1.9.1
[PATCH v5 09/20] iommu/mediatek: Refine protect memory definition
The protect memory setting is a little different in the different SoCs. In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault protect) shift bit is normally 4 while it shift 5 bits only in the mt8173. This patch delete the complex MACRO and use a common if-else instead. Also, use "F_MMU_TF_PROT_TO_PROGRAM_ADDR" instead of the hard code(2) which means the M4U will output the dirty data to the programmed address that we allocated dynamically when translation fault occurs. Signed-off-by: Yong Wu --- @Nicalos, I don't put it in the plat_data since only the previous mt8173 shift 5. As I know, the latest SoC always use the new setting like mt2712 and mt8183. Thus, I think it is unnecessary to put it in plat_data and let all the latest SoC set it. Hence, I still keep "== mt8173" for this like the reg REG_MMU_CTRL_REG. --- drivers/iommu/mtk_iommu.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index eca1536..35a1263 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -53,11 +53,7 @@ #define REG_MMU_CTRL_REG 0x110 #define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4) -#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \ - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5) -/* It's named by F_MMU_TF_PROT_SEL in mt2712. */ -#define F_MMU_TF_PROTECT_SEL(prot, data) \ - (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data)) +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR 2 #define REG_MMU_IVRP_PADDR 0x114 @@ -521,9 +517,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data) return ret; } - regval = F_MMU_TF_PROTECT_SEL(2, data); if (data->plat_data->m4u_plat == M4U_MT8173) - regval |= F_MMU_PREFETCH_RT_REPLACE_MOD; + regval = F_MMU_PREFETCH_RT_REPLACE_MOD | + (F_MMU_TF_PROT_TO_PROGRAM_ADDR << 5); + else + regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR << 4; writel_relaxed(regval, data->base + REG_MMU_CTRL_REG); regval = F_L2_MULIT_HIT_EN | -- 1.9.1
[PATCH v6 06/20] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
is remapped to high address from 0x1__ to 0x1__, the
bit32 is always enabled. thus, in the M4U, we always enable the bit9
for all PTEs which means to enable bit32 of physical address.
but in mt8183, M4U support the dram from 0x4000_ to 0x3__
which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
32bits.
In order to unify code, in the "4GB mode", we add the bit32 for the
physical address manually in our driver.
Correspondingly, Adding bit32 and bit33 for the PA in the iova_to_phys
has to been moved into v7s.
Regarding whether the pagetable address could be over 4GB, the mt8183
support it while the previous mt8173 don't. thus keep it as is.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 31 ---
drivers/iommu/io-pgtable.h | 7 +++
drivers/iommu/mtk_iommu.c | 14 --
drivers/iommu/mtk_iommu.h | 1 +
4 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 11d8505..8803a35 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -124,7 +124,9 @@
#define ARM_V7S_TEX_MASK 0x7
#define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) <<
ARM_V7S_TEX_SHIFT)
-#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB mode */
+/* MediaTek extend the two bits below for over 4GB mode */
+#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
+#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT6
@@ -183,13 +185,22 @@ static dma_addr_t __arm_v7s_dma_addr(void *pages)
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ }
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -198,7 +209,14 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int
lvl,
else
mask = ARM_V7S_LVL_MASK(lvl);
- return pte & mask;
+ paddr = pte & mask;
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ }
+ return paddr;
}
static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
@@ -315,9 +333,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int lvl,
if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
pte |= ARM_V7S_ATTR_NS_SECTION;
- if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)
- pte |= ARM_V7S_ATTR_MTK_4GB;
-
return pte;
}
@@ -504,7 +519,9 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned
long iova,
if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
return 0;
- if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
+ if (WARN_ON(upper_32_bits(iova)) ||
+ WARN_ON(upper_32_bits(paddr) &&
+ !(iop->cfg.quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)))
return -ERANGE;
ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 47d5ae5..69db115 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -62,10 +62,9 @@ struct io_pgtable_cfg {
* (unmapped) entries but the hardware might do so anyway, perform
* TLB maintenance when mapping as well as when unmapping.
*
-* IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
-* PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
-* when the SoC is in "4GB mode" and they can only access the high
-* remap of DRAM (0x1_ to 0x1_).
+* IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) MediaTek IOMMUs
[PATCH v5 07/20] iommu/mediatek: Add bclk can be supported optionally
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 +++---
drivers/iommu/mtk_iommu.h | 3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ae1aa5a..847082c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -613,9 +613,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- data->bclk = devm_clk_get(dev, "bclk");
- if (IS_ERR(data->bclk))
- return PTR_ERR(data->bclk);
+ if (data->plat_data->has_bclk) {
+ data->bclk = devm_clk_get(dev, "bclk");
+ if (IS_ERR(data->bclk))
+ return PTR_ERR(data->bclk);
+ }
larb_nr = of_count_phandle_with_args(dev->of_node,
"mediatek,larbs", NULL);
@@ -739,11 +741,13 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5890e55..b8749ac 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -44,6 +44,9 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
boolhas_4gb_mode;
+
+ /* HW will use the EMI clock if there isn't the "bclk". */
+ boolhas_bclk;
};
struct mtk_iommu_domain;
--
1.9.1
[PATCH v5 05/20] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 --
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index cec29bf..11d8505 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -173,18 +173,38 @@ struct arm_v7s_io_pgtable {
spinlock_t split_lock;
};
+static bool arm_v7s_pte_is_cont(arm_v7s_iopte pte, int lvl);
+
static dma_addr_t __arm_v7s_dma_addr(void *pages)
{
return (dma_addr_t)virt_to_phys(pages);
}
-static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl)
+static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
+ struct io_pgtable_cfg *cfg)
{
+ return paddr & ARM_V7S_LVL_MASK(lvl);
+}
+
+static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
+ struct io_pgtable_cfg *cfg)
+{
+ arm_v7s_iopte mask;
+
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
- pte &= ARM_V7S_TABLE_MASK;
+ mask = ARM_V7S_TABLE_MASK;
+ else if (arm_v7s_pte_is_cont(pte, lvl))
+ mask = ARM_V7S_LVL_MASK(lvl) * ARM_V7S_CONT_PAGES;
else
- pte &= ARM_V7S_LVL_MASK(lvl);
- return phys_to_virt(pte);
+ mask = ARM_V7S_LVL_MASK(lvl);
+
+ return pte & mask;
+}
+
+static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
+ struct arm_v7s_io_pgtable *data)
+{
+ return phys_to_virt(iopte_to_paddr(pte, lvl, >iop.cfg));
}
static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
@@ -396,7 +416,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
if (num_entries > 1)
pte = arm_v7s_pte_to_cont(pte, lvl);
- pte |= paddr & ARM_V7S_LVL_MASK(lvl);
+ pte |= paddr_to_iopte(paddr, lvl, cfg);
__arm_v7s_set_pte(ptep, pte, num_entries, cfg);
return 0;
@@ -462,7 +482,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data,
unsigned long iova,
}
if (ARM_V7S_PTE_IS_TABLE(pte, lvl)) {
- cptep = iopte_deref(pte, lvl);
+ cptep = iopte_deref(pte, lvl, data);
} else if (pte) {
/* We require an unmap first */
WARN_ON(!selftest_running);
@@ -512,7 +532,8 @@ static void arm_v7s_free_pgtable(struct io_pgtable *iop)
arm_v7s_iopte pte = data->pgd[i];
if (ARM_V7S_PTE_IS_TABLE(pte, 1))
- __arm_v7s_free_table(iopte_deref(pte, 1), 2, data);
+ __arm_v7s_free_table(iopte_deref(pte, 1, data),
+2, data);
}
__arm_v7s_free_table(data->pgd, 1, data);
kmem_cache_destroy(data->l2_tables);
@@ -582,7 +603,7 @@ static size_t arm_v7s_split_blk_unmap(struct
arm_v7s_io_pgtable *data,
if (!ARM_V7S_PTE_IS_TABLE(pte, 1))
return 0;
- tablep = iopte_deref(pte, 1);
+ tablep = iopte_deref(pte, 1, data);
return __arm_v7s_unmap(data, iova, size, 2, tablep);
}
@@ -641,7 +662,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable
*data,
io_pgtable_tlb_add_flush(iop, iova, blk_size,
ARM_V7S_BLOCK_SIZE(lvl + 1), false);
io_pgtable_tlb_sync(iop);
- ptep = iopte_deref(pte[i], lvl);
+ ptep = iopte_deref(pte[i], lvl, data);
__arm_v7s_free_table(ptep, lvl + 1, data);
} else if (iop->cfg.quirks &
IO_PGTABLE_QUIRK_NON_STRICT) {
/*
@@ -666,7 +687,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable
*data,
}
/* Keep on walkin' */
- ptep = iopte_deref(pte[0], lvl);
+ ptep = iopte_deref(pte[0], lvl, data);
return __arm_v7s_unmap(data, iova, size, lvl + 1, ptep);
}
@@ -692,7 +713,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct
io_pgtable_ops *ops,
do {
ptep += ARM_V7S_LVL_IDX(iova, ++lvl);
pte = READ_ONCE(*ptep);
- ptep = iopte_deref(pte, lvl);
+ ptep = iopte_deref(pte, lvl, data);
} while (ARM_V7S_PTE_IS_TABLE(pte, lvl));
if (!ARM_V7S_PTE_IS_VALID(pte))
@@ -701,7 +722,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct
io_pgtable_ops *ops,
mask = ARM_V7S_LVL_MASK(lvl);
if (arm_v7s_pte_is_cont(pte, lvl))
mask *= ARM_V7S_CONT_PAGES;
- return (pte & mask) | (iova & ~mask);
+ return iopte_to_paddr(pte, lvl, >iop.cfg) | (iova & ~mask);
}
static
[PATCH v5 04/20] memory: mtk-smi: Use a struct for the platform data for smi-common
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/memory/mtk-smi.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 9fd6b3d..8a2f968 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,15 @@
#define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+enum mtk_smi_gen {
+ MTK_SMI_GEN1,
+ MTK_SMI_GEN2
+};
+
+struct mtk_smi_common_plat {
+ enum mtk_smi_gen gen;
+};
+
struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
@@ -61,6 +70,8 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem*smi_ao_base;
+
+ const struct mtk_smi_common_plat *plat;
};
struct mtk_smi_larb { /* larb: local arbiter */
@@ -72,11 +83,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-enum mtk_smi_gen {
- MTK_SMI_GEN1,
- MTK_SMI_GEN2
-};
-
static int mtk_smi_enable(const struct mtk_smi *smi)
{
int ret;
@@ -351,18 +357,26 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
}
};
+static const struct mtk_smi_common_plat mtk_smi_common_gen1 = {
+ .gen = MTK_SMI_GEN1,
+};
+
+static const struct mtk_smi_common_plat mtk_smi_common_gen2 = {
+ .gen = MTK_SMI_GEN2,
+};
+
static const struct of_device_id mtk_smi_common_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = _smi_common_gen2,
},
{
.compatible = "mediatek,mt2701-smi-common",
- .data = (void *)MTK_SMI_GEN1
+ .data = _smi_common_gen1,
},
{
.compatible = "mediatek,mt2712-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = _smi_common_gen2,
},
{}
};
@@ -372,13 +386,13 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct mtk_smi *common;
struct resource *res;
- enum mtk_smi_gen smi_gen;
int ret;
common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
if (!common)
return -ENOMEM;
common->dev = dev;
+ common->plat = of_device_get_match_data(dev);
common->clk_apb = devm_clk_get(dev, "apb");
if (IS_ERR(common->clk_apb))
@@ -394,8 +408,7 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
* clock into emi clock domain, but for mtk smi gen2, there's no smi ao
* base.
*/
- smi_gen = (enum mtk_smi_gen)of_device_get_match_data(dev);
- if (smi_gen == MTK_SMI_GEN1) {
+ if (common->plat->gen == MTK_SMI_GEN1) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
common->smi_ao_base = devm_ioremap_resource(dev, res);
if (IS_ERR(common->smi_ao_base))
--
1.9.1
[PATCH v5 02/20] iommu/mediatek: Use a struct as the platform data
Use a struct as the platform special data instead of the enumeration.
This is a prepare patch for adding mt8183 iommu support.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 24
drivers/iommu/mtk_iommu.h | 6 +-
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index de3e022..189d1b5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -54,7 +54,7 @@
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
- ((data)->m4u_plat == M4U_MT2712 ? 4 : 5)
+ ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
/* It's named by F_MMU_TF_PROT_SEL in mt2712. */
#define F_MMU_TF_PROTECT_SEL(prot, data) \
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
@@ -520,7 +520,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
}
regval = F_MMU_TF_PROTECT_SEL(2, data);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
@@ -541,14 +541,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
regval = lower_32_bits(data->protect_base) |
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1__ to 0x1__. here record bit[32:30].
@@ -559,7 +559,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
/* It's MISC control register whose default value is ok except mt8173.*/
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -592,7 +592,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
data->dev = dev;
- data->m4u_plat = (enum mtk_iommu_plat)of_device_get_match_data(dev);
+ data->plat_data = of_device_get_match_data(dev);
/* Protect memory. HW will access here while translation fault.*/
protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
@@ -736,9 +736,17 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
};
+static const struct mtk_iommu_plat_data mt2712_data = {
+ .m4u_plat = M4U_MT2712,
+};
+
+static const struct mtk_iommu_plat_data mt8173_data = {
+ .m4u_plat = M4U_MT8173,
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
- { .compatible = "mediatek,mt2712-m4u", .data = (void *)M4U_MT2712},
- { .compatible = "mediatek,mt8173-m4u", .data = (void *)M4U_MT8173},
+ { .compatible = "mediatek,mt2712-m4u", .data = _data},
+ { .compatible = "mediatek,mt8173-m4u", .data = _data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 778498b..333a0ef 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -41,6 +41,10 @@ enum mtk_iommu_plat {
M4U_MT8173,
};
+struct mtk_iommu_plat_data {
+ enum mtk_iommu_plat m4u_plat;
+};
+
struct mtk_iommu_domain;
struct mtk_iommu_data {
@@ -57,7 +61,7 @@ struct mtk_iommu_data {
booltlb_flush_active;
struct iommu_device iommu;
- enum mtk_iommu_plat m4u_plat;
+ const struct mtk_iommu_plat_data *plat_data;
struct list_headlist;
};
--
1.9.1
[PATCH v5 03/20] memory: mtk-smi: Use a general config_port interface
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt8183,
IPU0/1 and CCU connect with smi-common directly, they also are not
the normal larb. Hence, we add a "larb_direct_to_common_mask" for these
larbs which connect to smi-commmon directly.
This is also a preparing patch for adding mt8183 SMI support.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/memory/mtk-smi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8f2d152..9fd6b3d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -53,6 +53,7 @@ struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
+ unsigned int larb_direct_to_common_mask;
};
struct mtk_smi {
@@ -176,17 +177,13 @@ void mtk_smi_larb_put(struct device *larbdev)
return -ENODEV;
}
-static void mtk_smi_larb_config_port_mt2712(struct device *dev)
+static void mtk_smi_larb_config_port_gen2_general(struct device *dev)
{
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
u32 reg;
int i;
- /*
-* larb 8/9 is the bdpsys larb, the iommu_en is enabled defaultly.
-* Don't need to set it again.
-*/
- if (larb->larbid == 8 || larb->larbid == 9)
+ if (BIT(larb->larbid) & larb->larb_gen->larb_direct_to_common_mask)
return;
for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
@@ -261,7 +258,8 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
.need_larbid = true,
- .config_port = mtk_smi_larb_config_port_mt2712,
+ .config_port= mtk_smi_larb_config_port_gen2_general,
+ .larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
static const struct of_device_id mtk_smi_larb_of_ids[] = {
--
1.9.1
[PATCH v5 01/20] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
This patch adds decriptions for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
--
||
gals0-rx gals1-rx
||
||
gals0-tx gals1-tx
||
SMI Common
|
+-+-++-+-+---+---+
| | || | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | || | | | |
| | || | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | || | | | |
larb0 larb1 IPU0IPU1 larb4 larb5 larb6CCU
disp vdec img camvenc imgcam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
>From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 15 ++-
.../memory-controllers/mediatek,smi-common.txt | 11 +-
.../memory-controllers/mediatek,smi-larb.txt | 3 +
include/dt-bindings/memory/mt8183-larb-port.h | 130 +
4 files changed, 153 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index 6922db5..6e758996 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -36,6 +36,10 @@ each local arbiter.
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
+ In some SoCs, there may be a GALS(Global Async Local Sync) module between
+smi-common and m4u, and additional GALS module between smi-larb and
+smi-common. GALS can been seen as a "asynchronous fifo" which could help
+synchronize for the modules in different clock frequency.
Required properties:
- compatible : must be one of the following string:
@@ -44,18 +48,23 @@ Required properties:
"mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
generation one m4u HW.
"mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
+ "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
-- clock-names : must be "bclk", It is the block clock of m4u.
+- clock-names : Only 1 optional clock:
+ - "bclk": the block clock of m4u.
+ Note that m4u use the EMI clock which always has been enabled before kernel
+ if there is no this "bclk".
- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
- dt-binding/memory/mt2712-larb-port.h for mt2712, and
- dt-binding/memory/mt8173-larb-port.h for mt8173.
+ dt-binding/memory/mt2712-larb-port.h for mt2712,
+ dt-binding/memory/mt8173-larb-port.h for mt8173, and
+ dt-binding/memory/mt8183-larb-port.h for mt8183.
Example:
iommu: iommu@10205000 {
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
[PATCH v5 00/18] MT8183 IOMMU SUPPORT
This patchset mainly adds support for mt8183 IOMMU and SMI. mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The mt8183 M4U-SMI HW diagram is as below: EMI | M4U | -- || gals0-rx gals1-rx || || gals0-tx gals1-tx || SMI Common | +-+-++-+-+---+---+ | | || | | | | | | gals-rx gals-rx | gals-rx gals-rx gals-rx | | || | | | | | | || | | | | | | gals-tx gals-tx | gals-tx gals-tx gals-tx | | || | | | | larb0 larb1 IPU0IPU1 larb4 larb5 larb6CCU disp vdec img camvenc imgcam All the connections are HW fixed, SW can NOT adjust it. Compared with mt8173, we add a GALS(Global Async Local Sync) module between SMI-common and M4U, and additional GALS between larb2/3/5/6 and SMI-common. GALS can help synchronize for the modules in different clock frequency, it can be seen as a "asynchronous fifo". GALS can only help transfer the command/data while it doesn't have the configuring register, thus it has the special "smi" clock and it doesn't have the "apb" clock. From the diagram above, we add "gals0" and "gals1" clocks for smi-common and add a "gals" clock for smi-larb. >From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera Control Unit) is connected with smi-common directly, we can take them as "larb2", "larb3" and "larb7", and their register spaces are different with the normal larb. This is the general purpose of each patch in this patchset: the patch 1..13 add the iommu/smi support for mt8183; the patch 14..16 add mmu1 support; the last patches contain some minor changes: -patch 17 cleanup some smi codes(delete need_larbid). -patch 18 fix a issue(fix vld_pa_rng). -patch 19 improve the code flow(add shutdown). -patch 20 switch to SPDX license. The dtsi was included at [1] since it should depend on power-domain and ccf nodes. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016539.html Change notes: v5: 1) Remove this patch "iommu/mediatek: Constify iommu_ops" for here as it was applied for v4.21. 2) Again, add 3 preparing patches. Move two property into the plat_data. iommu/mediatek: Move vld_pa_rng into plat_data iommu/mediatek: Move reset_axi into plat_data iommu/mediatek: Refine protect memory definition 3) Change the string "larb_special_mask" to "larb_direct_to_common_mask". 4) Add shutdown callback for mtk_iommu_v1 in patch[19/20]. v4: http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016205.html 1) Add 3 preparing patches. Seperate some minor meaningful code into a new patch according to Matthias's suggestion. memory: mtk-smi: Add gals support iommu/mediatek: Add larb-id remapped support iommu/mediatek: Add bclk can be supported optionally 2) rebase on "iommu/mediatek: Make it explicitly non-modular" which was applied. https://lore.kernel.org/patchwork/patch/1020125/ 3) add some comment about "mediatek,larb-id" in the commit message of the patch "mtk-smi: Get rid of need_larbid". 4) Fix bus_sel value. v3: https://lists.linuxfoundation.org/pipermail/iommu/2018-November/031121.html 1) rebase on v4.20-rc1. 2) In the dt-binding, add a minor string "mt7623" which also use gen1 since Matthias added it in v4.20. 3) About v7s: a) for paddr_to_pte, change the param from "arm_v7s_io_pgtable" to "arm_pgtable_cfg", according to Robin suggestion. b) Don't use CONFIG_PHYS_ADDR_T_64BIT. c) add a little comment(pgtable address still don't over 4GB) in the commit message of the patch "Extend MediaTek 4GB Mode". 4) add "iommu/mediatek: Constify iommu_ops" into this patchset. this may be helpful for review and merge. https://lists.linuxfoundation.org/pipermail/iommu/2018-October/030637.html v2: https://lists.linuxfoundation.org/pipermail/iommu/2018-September/030164.html 1) Fix typo in the commit message of dt-binding. 2) Change larb2/larb3 to the special larbs. 3) Refactor the larb-id remapped array(larbid_remapped), then we don't need add the new function(mtk_iommu_get_larbid). 4) Add a new patch for v7s two helpers(paddr_to_iopte and iopte_to_paddr). 5) Change some comment for MTK 4GB mode. v1: base on
Re: [PATCH 6/6] MAINTAINERS: Add linux-actions mailing list for Actions Semi
Am 01.01.19 um 04:26 schrieb Manivannan Sadhasivam: > On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote: >> On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote: >>> diff --git a/MAINTAINERS b/MAINTAINERS >> [] >>> @@ -1240,6 +1240,7 @@ ARM/ACTIONS SEMI ARCHITECTURE >>> M: Andreas Färber >>> R: Manivannan Sadhasivam >>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >>> +L: linux-acti...@lists.infradead.org (moderated for non-subscribers) >>> S: Maintained >>> N: owl >> >> The N: entry matches too many non-owl entries like: >> >> Documentation/parport-lowlevel.txt >> drivers/misc/ibmasm/lowlevel.c >> drivers/misc/ibmasm/lowlevel.h >> fs/udf/lowle >> vel.c >> net/ipv6/ip6_flowlabel.c >> sound/soc/samsung/lowland.c >> >> Maybe there should be two entries >> >> N: /owl >> N: -owl >> > > Thanks for letting us know. Yes, we need to change it. How about below? > > N: owl- > N: -owl No underscores anywhere? Cheers, Andreas > > Will do it as a follow-up patch if agreed! > > Regards, > Mani > >> -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 6/6] MAINTAINERS: Add linux-actions mailing list for Actions Semi
Hi Joe, On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote: > On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote: > > Add the linux-actions mailing list for Actions Semi SoC architecture. > > Unrelated to adding this L: entry > > > diff --git a/MAINTAINERS b/MAINTAINERS > [] > > @@ -1240,6 +1240,7 @@ ARM/ACTIONS SEMI ARCHITECTURE > > M: Andreas Färber > > R: Manivannan Sadhasivam > > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > > +L: linux-acti...@lists.infradead.org (moderated for non-subscribers) > > S: Maintained > > N: owl > > The N: entry matches too many non-owl entries like: > > Documentation/parport-lowlevel.txt > drivers/misc/ibmasm/lowlevel.c > drivers/misc/ibmasm/lowlevel.h > fs/udf/lowle > vel.c > net/ipv6/ip6_flowlabel.c > sound/soc/samsung/lowland.c > > Maybe there should be two entries > > N:/owl > N:-owl > Thanks for letting us know. Yes, we need to change it. How about below? N: owl- N: -owl Will do it as a follow-up patch if agreed! Regards, Mani >
Re: [PATCH] tty/n_hdlc: fix sleep in !TASK_RUNNING state warning
On Dec 31, 2018, at 7:11 PM, Paul Fulghum wrote:
NAK to this patch. It causes lost wakeups in both read and write paths.
The write path does not need changing.
The read path can be fixed by setting current to TASK_RUNNING at the top of the
if (rbuf) block so the warning is not triggered by copy_to_user(). If this
block runs the condition is satisfied and it breaks out of the polling loop
where it is already being set to TASK_RUNNING and removed from the wait queue.
This particular path just needs to account for the copy_to_user which occurs
before breaking out.
I’ll make a patch to do this when I have the ability to test it in a day or two.
> On Dec 29, 2018, at 3:48 AM, Tetsuo Handa
> wrote:
>
> syzbot is hitting __might_sleep() warning [1], for commit 1035b63d3c6fc34a
> ("n_hdlc: fix read and write locking") changed to set TASK_INTERRUPTIBLE
> state before calling copy_to_user(). Let's set TASK_INTERRUPTIBLE state
> immediately before calling schedule().
>
> [1]
> https://syzkaller.appspot.com/bug?id=17d5de7f1fcab794cb8c40032f893f52de899324
>
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Cc: Paul Fulghum
> Cc: Arnd Bergmann
> Cc: Alan Cox
> ---
> drivers/tty/n_hdlc.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/n_hdlc.c b/drivers/tty/n_hdlc.c
> index dabb391..7835489 100644
> --- a/drivers/tty/n_hdlc.c
> +++ b/drivers/tty/n_hdlc.c
> @@ -589,8 +589,6 @@ static ssize_t n_hdlc_tty_read(struct tty_struct *tty,
> struct file *file,
> if (tty_hung_up_p(file))
> break;
>
> - set_current_state(TASK_INTERRUPTIBLE);
> -
> rbuf = n_hdlc_buf_get(_hdlc->rx_buf_list);
> if (rbuf) {
> if (rbuf->count > nr) {
> @@ -617,6 +615,7 @@ static ssize_t n_hdlc_tty_read(struct tty_struct *tty,
> struct file *file,
> break;
> }
>
> + set_current_state(TASK_INTERRUPTIBLE);
> schedule();
>
> if (signal_pending(current)) {
> @@ -673,8 +672,6 @@ static ssize_t n_hdlc_tty_write(struct tty_struct *tty,
> struct file *file,
> add_wait_queue(>write_wait, );
>
> for (;;) {
> - set_current_state(TASK_INTERRUPTIBLE);
> -
> tbuf = n_hdlc_buf_get(_hdlc->tx_free_buf_list);
> if (tbuf)
> break;
> @@ -683,6 +680,8 @@ static ssize_t n_hdlc_tty_write(struct tty_struct *tty,
> struct file *file,
> error = -EAGAIN;
> break;
> }
> +
> + set_current_state(TASK_INTERRUPTIBLE);
> schedule();
>
> n_hdlc = tty2n_hdlc (tty);
> --
> 1.8.3.1
>
>
--
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(512) 345-7791 x102 (Voice)
(512) 343-9046 (Fax)
Central Time Zone (GMT -5h)
www.microgate.com
Re: [PATCH v7 00/11] Add initial RDA8810PL SoC and Orange Pi boards support
Hi Olof, On Mon, Dec 31, 2018 at 01:13:42PM -0800, Olof Johansson wrote: > On Tue, Dec 18, 2018 at 08:32:27PM +0530, Manivannan Sadhasivam wrote: > > Hello Maintainers, > > > > This patch series adds initial RDA8810PL SoC and Orange Pi boards (2G IoT > > and > > i96) support. RDA8810PL is an ARM Cortex A5 based SoC with Vivante's GC860 > > GPU. The SoC has been added as a new ARM sub architecture with myself as the > > maintainer. > > > > More information about the boards can be found in below links: > > > > 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/ > > 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/ > > > > All patches are reviewed by the corresponding subsystem maintainers. The > > clocksource and irqchip patches are reviewed and merged while the serial > > driver got review from Greg but I'm not sure who will apply it. > > > > So as per my discussion with Arnd, sending the individual patches instead > > of a Pull request so that the rest of the patches can go through the > > ARM SoC tree. > > > > Please consider applying it. > > Hi, > > I've applied this series to our next/late branch. It's a branch we'll try to > get merged by the end of the merge window, but it's not a guarantee that we'll > be able to get it done. If not, the material will be moved to the next release > instead. > Okay, thanks for the update! Regards, Mani > > Thanks! > > > -Olof
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 12/30/18 12:39 PM, Michael Straube wrote:
Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
is causing hardfreeze whenever the driver tries to connect to my wifi
network. That makes the driver unusable on my system. Reverting the
commit fixes the issue and the driver works properly.
Dec 29 19:21:17 gentoo kernel: BUG: scheduling while atomic:
swapper/6/0/0x0100
Michael,
I have verified the freezes that you see. Although I have not been able to
capture the console dump, I think we are likely seeing the same problem.
I do have a work-around in that I have not gotten any freezes when I force
module lib80211_crypt_ccmp to be loaded before I load module r8188eu. This clue
was used in finding what seems to be a good fix.
I do not know anything about demand loading of modules using
try_then_request_module(); however, I noticed that the macro actually calls
__request_module(), which has the following comment:
* Load a module using the user mode module loader. The function returns
* zero on success or a negative errno code or positive exit code from
* "modprobe" on failure. Note that a successful module load does not mean
* the module did not then unload and exit on an error of its own. Callers
* must check that the service they requested is now available not blindly
* invoke it.
I note that it says "user mode module loader". Routine rtw_aes_decrypt() is
likely inside some sort of locking, which leads to the "scheduling while atomic"
bug that you see. As a result, I suspect that the module is not loaded, and that
leads to the NULL dereference when the module is accessed. Please try the
one-line patch attached, which forces lib80211 to load when r8188eu is loaded.
With this patch, I have been connected to an AES-encrypted AP for nearly 3 hours
with no problems.
Larry
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index f7407632e80b..052656a22821 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1291,7 +1291,7 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8
*precvframe)
struct sk_buff *skb = ((struct recv_frame
*)precvframe)->pkt;
void *crypto_private = NULL;
u8 *key, *pframe = skb->data;
- struct lib80211_crypto_ops *crypto_ops =
try_then_request_module(lib80211_get_crypto_ops("CCMP"), "lib80211_crypt_ccmp");
+ struct lib80211_crypto_ops *crypto_ops =
lib80211_get_crypto_ops("CCMP");
struct security_priv *psecuritypriv =
>securitypriv;
char iv[8], icv[8];
Re: [GIT PULL 1/4] ARM: SoC platform updates
The pull request you sent on Mon, 31 Dec 2018 13:46:37 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0922275ef157ba8ac93e7e7857087eb0442d5397 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL 2/4] ARM: SoC driver updates
The pull request you sent on Mon, 31 Dec 2018 13:46:38 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git > tags/armsoc-drivers has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d36377c6eb071e3d0751e9e0e3c19198c58d9a5d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL 4/4] ARM: SoC defconfig updates
The pull request you sent on Mon, 31 Dec 2018 13:46:40 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git > tags/armsoc-defconfig has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e1ef035d272ef4dbfdda98e58699698305138856 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL 3/4] ARM: Device-tree updates
The pull request you sent on Mon, 31 Dec 2018 13:46:39 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b7badd1d7aa61087010803affa19bb83fb5a0af1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 4:29 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > > wrote:
> > >
> > > > +static ssize_t ppc_nvram_get_size(void)
> > > > +{
> > > > + if (ppc_md.nvram_size)
> > > > + return ppc_md.nvram_size();
> > > > + return -ENODEV;
> > > > +}
> > >
> > > > +const struct nvram_ops arch_nvram_ops = {
> > > > + .read = ppc_nvram_read,
> > > > + .write = ppc_nvram_write,
> > > > + .get_size = ppc_nvram_get_size,
> > > > + .sync = ppc_nvram_sync,
> > > > +};
> > >
> > > Coming back to this after my comment on the m68k side, I notice that
> > > there is now a double indirection through function pointers. Have
> > > you considered completely removing the operations from ppc_md
> > > instead by having multiple copies of nvram_ops?
> > >
> >
> > I considered a few alternatives. I figured that it was refactoring
> > that could be deferred, as it would be confined to arch/powerpc. I was
> > more interested in the cross-platform API.
>
> Fair enough.
>
> > > With the current method, it does seem odd to have a single
> > > per-architecture instance of the exported structure containing
> > > function pointers. This doesn't give us the flexibility of having
> > > multiple copies in the kernel the way that ppc_md does, but it adds
> > > overhead compared to simply exporting the functions directly.
> > >
> >
> > You're right, there is overhead here.
> >
> > With a bit of auditing, wrappers like the one you quoted (which merely
> > checks whether or not a ppc_md method is implemented) could surely be
> > avoided.
> >
> > The arch_nvram_ops methods are supposed to optional (that is, they are
> > allowed to be NULL).
> >
> > We could call exactly the same function pointers though either ppc_md
> > or arch_nvram_ops. That would avoid the double indirection.
>
> I think you can have a 'const' structure in the __ro_after_init section,
> so without changing anything else, powerpc could just copy the function
> pointers from ppc_md into the arch_nvram_ops at early init time, which
> should ideally simplify your implementation as well.
>
This "early init time" could be hard to pin down... It has to be after
ppc_md methods are initialized but before the nvram_ops methods get used
(e.g. by the framebuffer console). Seems a bit fragile (?)
Your suggestion to completely remove the ppc_md.nvram* methods might be a
better way. It just means functions get assigned to nvram_ops pointers
instead of ppc_md pointers.
The patch is simple enough, but it assumes that arch_nvram_ops is not
const. The struct machdep_calls ppc_md is not const, so should we worry
about dropping the const for the struct nvram_ops arch_nvram_ops?
--
> Arnd
>
Re: [PATCH net-next] net: hns3: Config NIC port speed same as that of optical module
On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote: > From: Peng Li > > Port 0/1 of HiP08 supports 10G and 25G. This patch adds a > change to configure NIC port speed same as that of optical > module(SFP/QFSP). Driver gets the optical module speed and > sets NIC port speed accordingly. Hi, I'm getting the following errors in dmesg about every 1s on a D06: [ 766.761823] hns3 :bd:00.0: get sfp speed failed -5 [ 767.785823] hns3 :bd:00.0: get sfp speed failed -5 [ 768.809820] hns3 :bd:00.0: get sfp speed failed -5 [ 769.833818] hns3 :bd:00.0: get sfp speed failed -5 Reverting this patch fixes the issue. -dann
Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 12:43 AM Finn Thain
> wrote:
>
> >
> > Is there some benefit, or is that just personal taste?
> >
> > Avoiding changes to call sites avoids code review, but I think 1) the
> > thinkpad_acpi changes have already been reviewed and 2) the fbdev changes
> > need review anyway.
> >
> > Your suggesion would add several new entities and one extra layer of
> > indirection.
> >
> > I think indirection harms readability because now the reader now has to go
> > and look up the meaning of the new entities.
> >
> > It's not the case that we need to choose between definitions of
> > nvram_read_byte() at compile time, or stub them out:
> >
> > #ifdef CONFIG_FOO
> > static inline unsigned char nvram_read_byte(int addr)
> > {
> > return arch_nvram_ops.read_byte(addr);
> > }
> > #else
> > static inline unsigned char nvram_read_byte(int addr) { }
> > #endif
> >
> > And I don't anticipate a need for a macro here either:
> >
> > #define nvram_read_byte(a) random_nvram_read_byte_impl(a)
> >
> > I think I've used the simplest solution.
>
> Having the indirection would help if the inline function can
> encapsulate the NULL pointer check, like
>
> static inline unsigned char nvram_read_byte(loff_t addr)
> {
>char data;
>
>if (!IS_ENABLED(CONFIG_NVRAM))
> return 0xff;
>
>if (arch_nvram_ops.read_byte)
> return arch_nvram_ops.read_byte(addr);
>
>if (arch_nvram_ops.read)
> return arch_nvram_ops.read(char, 1, );
>
> return 0xff;
> }
>
The semantics of .read_byte and .read are subtly different. For CONFIG_X86
and CONFIG_ATARI, .read implies checksum validation and .read_byte does
not.
In particular, in the thinkpad_acpi case, checksum validation isn't used,
but in the atari_scsi case, it is.
So I like to see drivers explicitly call the method they want. I didn't
want to obscure this distinction in a helper.
--
sound/pci/hda/patch_ca0132.c:8416:3: error: implicit declaration of function 'pci_iounmap'; did you mean 'pcim_iounmap'?
Hi Takashi,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f12e840c819bab42621685558a01d3f46ab9a226
commit: d99501b8575dc1248bacf1b58d2241cb4b265d49 ALSA: hda/ca0132 - Call
pci_iounmap() instead of iounmap()
date: 7 weeks ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d99501b8575dc1248bacf1b58d2241cb4b265d49
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
sound/pci/hda/patch_ca0132.c: In function 'ca0132_free':
>> sound/pci/hda/patch_ca0132.c:8416:3: error: implicit declaration of function
>> 'pci_iounmap'; did you mean 'pcim_iounmap'?
>> [-Werror=implicit-function-declaration]
pci_iounmap(codec->bus->pci, spec->mem_base);
^~~
pcim_iounmap
sound/pci/hda/patch_ca0132.c: In function 'patch_ca0132':
sound/pci/hda/patch_ca0132.c:8799:20: error: implicit declaration of
function 'pci_iomap'; did you mean 'pcim_iomap'?
[-Werror=implicit-function-declaration]
spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
^
pcim_iomap
sound/pci/hda/patch_ca0132.c:8799:18: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
^
cc1: some warnings being treated as errors
vim +8416 sound/pci/hda/patch_ca0132.c
8386
8387 static void ca0132_free(struct hda_codec *codec)
8388 {
8389 struct ca0132_spec *spec = codec->spec;
8390
8391 cancel_delayed_work_sync(>unsol_hp_work);
8392 snd_hda_power_up(codec);
8393 switch (spec->quirk) {
8394 case QUIRK_SBZ:
8395 sbz_exit_chip(codec);
8396 break;
8397 case QUIRK_ZXR:
8398 zxr_exit_chip(codec);
8399 break;
8400 case QUIRK_R3D:
8401 r3d_exit_chip(codec);
8402 break;
8403 case QUIRK_AE5:
8404 ae5_exit_chip(codec);
8405 break;
8406 case QUIRK_R3DI:
8407 r3di_gpio_shutdown(codec);
8408 break;
8409 }
8410
8411 snd_hda_sequence_write(codec, spec->base_exit_verbs);
8412 ca0132_exit_chip(codec);
8413
8414 snd_hda_power_down(codec);
8415 if (spec->mem_base)
> 8416 pci_iounmap(codec->bus->pci, spec->mem_base);
8417 kfree(spec->spec_init_verbs);
8418 kfree(codec->spec);
8419 }
8420
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v4 08/11] ASoC: Intel: atom: Make PCI dependency explicit
On Tue, Jan 1, 2019 at 12:42 AM Pierre-Louis Bossart wrote: > > > On 12/31/18 2:35 PM, Sinan Kaya wrote: > > On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart > > wrote: > >> > >> On 12/31/18 1:35 PM, Sinan Kaya wrote: > >>> On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote: > On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote: > > On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote: > >> I don't have the cover letter or anything for this series, what's going > >> on with dependencies? > > Here is the executive summary: > > I have a changeset that separates ACPI from PCI on 4.21. CONFIG_ACPI > > used to select PCI. This is no longer true. > > You can build an ACPI system without any PCI devices. > So there's no dependency and I can just apply this? > >>> The plan is to apply this patchset via ACPI tree. Need an Acked-by per > >>> patch. > >> Anytime we change the Kconfig settings for audio, we get all kinds of > >> problems with randconfig and 0day/kbuild due to depend/select issues. > >> I'd like to give this a spin first, can you share a link to the entire > >> series? Thanks! > > Sure, > > > > You can find them here > > > > https://lore.kernel.org/patchwork/patch/1028330/ > > > > Click related. > > Something must be missing, I get compilation errors when PCI is not > defined? And I see tons of references to pci stuff in drivers/acpi. > > drivers/acpi/reboot.c: In function ‘acpi_reboot’: > drivers/acpi/reboot.c:37:10: error: implicit declaration of function > ‘pci_find_bus’; did you mean ‘pci_find_next_bus’? > [-Werror=implicit-function-declaration] > bus0 = pci_find_bus(0, 0); >^~~~ >pci_find_next_bus > drivers/acpi/reboot.c:37:8: warning: assignment makes pointer from > integer without a cast [-Wint-conversion] > bus0 = pci_find_bus(0, 0); > ^ > drivers/acpi/reboot.c:45:3: error: implicit declaration of function > ‘pci_bus_write_config_byte’; did you mean ‘pci_write_config_byte’? > [-Werror=implicit-function-declaration] > pci_bus_write_config_byte(bus0, devfn, > ^ > pci_write_config_byte > > Please check out this tag next-20181224 and apply the patches afterwards.
Re: [PATCH v8 18/25] powerpc: Implement nvram sync ioctl
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 8:25 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > > --- a/drivers/char/nvram.c
> > > > +++ b/drivers/char/nvram.c
> > > > @@ -48,6 +48,10 @@
> > > > #include
> > > > #include
> > > >
> > > > +#ifdef CONFIG_PPC
> > > > +#include
> > > > +#include
> > > > +#endif
> > > >
> > > > static DEFINE_MUTEX(nvram_mutex);
> > > > static DEFINE_SPINLOCK(nvram_state_lock);
> > > > @@ -331,6 +335,37 @@ static long nvram_misc_ioctl(struct file *file,
> > > > unsigned int cmd,
> > > > long ret = -ENOTTY;
> > > >
> > > > switch (cmd) {
> > > > +#ifdef CONFIG_PPC
> > > > + case OBSOLETE_PMAC_NVRAM_GET_OFFSET:
> > > > + pr_warn("nvram: Using obsolete PMAC_NVRAM_GET_OFFSET
> > > > ioctl\n");
> > > > + /* fall through */
> > > > + case IOC_NVRAM_GET_OFFSET:
> > > > + ret = -EINVAL;
> > > > +#ifdef CONFIG_PPC_PMAC
> > >
> > > I think it would make be nicer here to keep the ppc bits in arch/ppc,
> > > and instead add a .ioctl() callback to nvram_ops.
> > >
> >
> > The problem with having an nvram_ops.ioctl() method is the code in the
> > !PPC branch. That code would get duplicated because it's needed by
> > both X86 and M68K, to implement the checksum ioctls.
>
> I was thinking you'd just have a common ioctl function that falls back
> to the .ioctl callback for any unhandled commands like
>
> switch (cmd) {
> case NVRAM_INIT:
> ...
> break;
> case ...:
> break;
> default:
> if (ops->ioctl)
> return ops->ioctl(...);
> return -EINVAL;
> }
>
> Would that work?
>
There are no ioctls common to all architectures. So your example becomes,
static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
if (ops->ioctl)
return ops->ioctl(file, cmd, arg);
return -ENOTTY;
}
And then my objection is the same: m68k and x86 now have to duplicate
their common ops->ioctl() implementation.
Here's a compromise that avoids some code duplication.
switch (cmd) {
#if defined(CONFIG_X86) || defined(CONFIG_M68K)
case NVRAM_INIT:
...
break;
case NVRAM_SETCKS:
...
break;
#endif
default:
if (ops->ioctl)
return ops->ioctl(...);
return -EINVAL;
}
But PPC64 and PPC32 also need to share their ops->ioctl() implementation.
It's not clear to me where that code would go.
Personally, I prefer the present patch series, or something similar, with
it's symmetry between nvram.c and nvram.h:
static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
long ret = -ENOTTY;
switch (cmd) {
#if defined(CONFIG_PPC)
case OBSOLETE_PMAC_NVRAM_GET_OFFSET:
...
case IOC_NVRAM_GET_OFFSET:
...
break;
case IOC_NVRAM_SYNC:
...
break;
#elif defined(CONFIG_X86) || defined(CONFIG_M68K)
case NVRAM_INIT:
...
break;
case NVRAM_SETCKS:
...
break;
#endif
}
return ret;
}
... versus the struct definition in nvram.h,
struct nvram_ops {
ssize_t (*read)(char *, size_t, loff_t *);
ssize_t (*write)(char *, size_t, loff_t *);
unsigned char (*read_byte)(int);
void(*write_byte)(unsigned char, int);
ssize_t (*get_size)(void);
#if defined(CONFIG_PPC)
long(*sync)(void);
int (*get_partition)(int);
#elif defined(CONFIG_X86) || defined(CONFIG_M68K)
long(*set_checksum)(void);
long(*initialize)(void);
#endif
};
Which of these alternatives do you prefer? Is there a better way?
--
>Arnd
>
Re: [PATCH v3 2/2] mm: rid swapoff of quadratic complexity
On Mon, 3 Dec 2018, Vineeth Remanan Pillai wrote: > This patch was initially posted by Kelley(kelley...@gmail.com). > Reposting the patch with all review comments addressed and with minor > modifications and optimizations. Tests were rerun and commit message > updated with new results. > > The function try_to_unuse() is of quadratic complexity, with a lot of > wasted effort. It unuses swap entries one by one, potentially iterating > over all the page tables for all the processes in the system for each > one. > > This new proposed implementation of try_to_unuse simplifies its > complexity to linear. It iterates over the system's mms once, unusing > all the affected entries as it walks each set of page tables. It also > makes similar changes to shmem_unuse. Hi Vineeth, please fold in fixes below before reposting your "mm,swap: rid swapoff of quadratic complexity" patch - or ask for more detail if unclear. I could split it up, of course, but since they should all (except perhaps one) just be merged into the base patch before going any further, it'll save me time to keep them together here and just explain:- shmem_unuse_swap_entries(): If a user fault races with swapoff, it's very normal for shmem_swapin_page() to return -EEXIST, and the old code was careful not to pass back any error but -ENOMEM; whereas on mmotm, /usr/sbin/swapoff often failed silently because it got that EEXIST. shmem_unuse(): A couple of crashing bugs there: a list_del_init without holding the mutex, and too much faith in the "safe" in list_for_each_entry_safe(): it does assume that the mutex has been held throughout, you (very nicely!) drop it, but that does require "next" to be re-evaluated. shmem_writepage(): Not a bug fix, this is the "except perhaps one": minor optimization, could be left out, but if shmem_unuse() is going through the list in the forward direction, and may completely unswap a file and del it from the list, then pages from that file can be swapped out to *other* swap areas after that, and it be reinserted in the list: better to reinsert it behind shmem_unuse()'s cursor than in front of it, which would entail a second pointless pass over that file. try_to_unuse(): Moved up the assignment of "oldi = i" (and changed the test to "oldi <= i"), so as not to get trapped in that find_next_to_unuse() loop when find_get_page() does not find it. try_to_unuse(): But the main problem was passing entry.val to find_get_page() there: that used to be correct, but since f6ab1f7f6b2d we need to pass just the offset - as it stood, it could only find the pages when swapping off area 0 (a similar issue was fixed in shmem_replace_page() recently). That (together with the late oldi assignment) was why my swapoffs were hanging on SWAP_HAS_CACHE swap_map entries. With those changes, it all seems to work rather well, and is a nice simplification of the source, in addition to removing the quadratic complexity. To my great surprise, the KSM pages are already handled fairly well - the ksm_might_need_to_copy() that has long been in unuse_pte() turns out to do (almost) a good enough job already, so most users of KSM and swapoff would never see any problem. And I'd been afraid of swapin readahead causing spurious -ENOMEMs, but have seen nothing of that in practice (though something else in mmotm does appear to use up more memory than before). My remaining criticisms would be: As Huang Ying pointed out in other mail, there is a danger of livelock (or rather, hitting the MAX_RETRIES limit) when a multiply mapped page (most especially a KSM page, whose mappings are not likely to be nearby in the mmlist) is swapped out then partially swapped off then some ptes swapped back out. As indeed the "Under global memory pressure" comment admits. I have hit the MAX_RETRIES 3 limit several times in load testing, not investigated but I presume due to such a multiply mapped page, so at present we do have a regression there. A very simple answer would be to remove the retries limiting - perhaps you just added that to get around the find_get_page() failure before it was understood? That does then tend towards the livelock alternative, but you've kept the signal_pending() check, so there's still the same way out as the old technique had (but greater likelihood of needing it with the new technique). The right fix will be to do an rmap walk to unuse all the swap entries of a single anon_vma while holding page lock (with KSM needing that page force-deleted from swap cache before moving on); but none of us have written that code yet, maybe just removing the retries limit good enough. Two dislikes on the code structure, probably one solution: the "goto retry", up two levels from inside the lower loop, is easy to misunderstand; and the oldi business is ugly - find_next_to_unuse() was written to wrap around continuously to suit the old loop, but now it's left with its "++i >= max" code to achieve that, then your "i <= oldi" code to detect when it did, to
Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> > On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > > Definitely! Same, I won't emit a patch just for this, Paul already queued
> > > it.
> >
> > Yeah, not that big a deal :)
> >
> > Reviewed-by: Joey Pabalinas
>
> But as long as I am rebasing to add the Reviewed-by, might as well
> update the others.
>
> The English rules for capitalization and lists are baroque and completely
> unsuited to word processors ("If any list item is longer than one line,
> capitalize all the items."), but in this case each item has multiple
> sentences, so it makes sense to capitalize.
>
> Please see below for the updated commit, and thank you all!
Interesting, I had no idea it was actually that odd, hah.
> And Happy New Year!!! ;-)
Glad to help, and happy new year to you as well :)
--
Cheers,
Joey Pabalinas
signature.asc
Description: PGP signature
Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc
On Mon, Dec 31, 2018 at 12:08:54PM -0800, Paul E. McKenney wrote:
> The English rules for capitalization and lists are baroque and completely
> unsuited to word processors ("If any list item is longer than one line,
> capitalize all the items."), but in this case each item has multiple
> sentences, so it makes sense to capitalize.
>
> Please see below for the updated commit, and thank you all!
OK, this looks fine to me, thank you Paul!
> And Happy New Year!!! ;-)
Oh and same to you ;-)
willy
[PATCH] x86/retpoline: change RETPOLINE into CONFIG_RETPOLINE
A recent enhancement intentionally fails the kernel build if the
compiler does not support retpolines and CONFIG_RETPOLINE is set.
However, the patch that introduced it did not change RETPOLINE macro
references into CONFIG_RETPOLINE ones. As a result, indirect branches
that are used by init functions are not kept (i.e., they use
retpolines), and modules that do not use retpolines are marked as
retpoline-safe.
Fix it be changing RETPOLINE into CONFIG_RETPOLINE.
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler
support")
Cc: Peter Zijlstra
Cc: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: David Woodhouse
Cc: Andy Lutomirski
Cc: Masahiro Yamada
Cc: sta...@vger.kernel.org
Signed-off-by: Nadav Amit
---
arch/x86/kernel/cpu/bugs.c | 2 +-
include/linux/compiler-gcc.h | 2 +-
include/linux/module.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8654b8b0c848..1de0f4170178 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -215,7 +215,7 @@ static enum spectre_v2_mitigation spectre_v2_enabled
__ro_after_init =
static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
SPECTRE_V2_USER_NONE;
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
static bool spectre_v2_bad_module;
bool retpoline_module_ok(bool has_retpoline)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 2010493e1040..977ddf2774f9 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,7 +68,7 @@
*/
#define uninitialized_var(x) x = x
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
diff --git a/include/linux/module.h b/include/linux/module.h
index fce6b4335e36..0c575f51fe57 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -817,7 +817,7 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
static inline void module_bug_cleanup(struct module *mod) {}
#endif /* CONFIG_GENERIC_BUG */
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
extern bool retpoline_module_ok(bool has_retpoline);
#else
static inline bool retpoline_module_ok(bool has_retpoline)
--
2.17.1
Re: [virtio-dev] RE: [PATCH v1 0/2] Virtio: fix some vq allocation issues
On Mon, 31 Dec 2018 06:03:51 + "Wang, Wei W" wrote: > On Sunday, December 30, 2018 2:06 PM, Halil Pasic wrote: > > > > I guess you are the first one trying to read virtio config from within > > interrupt > > context. AFAICT this never worked. > > I'm not sure about "never worked". It seems to work well with virtio-pci. > But looking forward to hearing a solid reason why reading config inside > the handler is forbidden (if that's true). By "never worked" I meant "never worked with virtio-ccw". Sorry about the misunderstanding. Seems I've also failed to convey that I don't know if reading config inside the handler is forbidden or not. So please don't expect me providing the solid reasons you are looking forward to. > > > About what happens. The apidoc of ccw_device_start() says it needs to be > > called with the ccw device lock held, so ccw_io_helper() tries to take it > > (since > > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and > > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel > > lock. That means when one tries to get virtio config form within a cio > > interrupt context we deadlock, because we try to take a lock we already > > have. > > > > That said, I don't think this limitation is by design (i.e. intended). > > Maybe Connie can help us with that question. AFAIK we have nothing > > documented regarding this (neither that can nor can't). > > > > Obviously, there are multiple ways around this problem, and at the moment > > I can't tell which would be my preferred one. > > Yes, it's also not difficult to tweak the virtio-balloon code to avoid that > issue. > But if that's just an issue with ccw itself, I think it's better to tweak ccw > and > remain virtio-balloon unchanged. > As I said, at the moment I don't have a preference regarding the fix, partly because I'm not sure if "reading config inside the handler" is OK or not. Maybe Connie or Michael can help us here. I'm however sure that commit 86a5597 "virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT" breaks virtio-balloon with the ccw transport (i.e. effectively breaks virtio-balloon on s390): it used to work before and does not work after. AFAICT tweaking the balloon code may be simpler than tweaking the virtio-ccw (transport code). ccw_io_helper() relies on getting an interrupt when the issued IO is done. If virtio-ccw is buggy, it needs to be fixed, but I'm not sure it is. Regards, Halil
Re: [PATCH 1/2] dt-bindings: reset: Add document for Broadcom STB reset controller
On 2018-12-20 5:34 p.m., Florian Fainelli wrote:
Add a binding document for the Broadcom STB reset controller, also known
as SW_INIT-style reset controller.
Signed-off-by: Florian Fainelli
---
.../devicetree/bindings/reset/brcm,reset.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/brcm,reset.txt
diff --git a/Documentation/devicetree/bindings/reset/brcm,reset.txt
b/Documentation/devicetree/bindings/reset/brcm,reset.txt
new file mode 100644
index ..6e5341b4f891
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,reset.txt
This is brcmstb-reset specific. File should be brcm, brcmstb-reset.txt
@@ -0,0 +1,27 @@
+Broadcom STB SW_INIT-style reset controller
+===
+
+Broadcom STB SoCs have a SW_INIT-style reset controller with separate
+SET/CLEAR/STATUS registers and possibly multiple banks, each of 32 bit
+reset lines.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: should be brcm,brcmstb-reset
+- reg: register base and length
+- #reset-cells: must be set to 1
+
+Example:
+
+ reset: reset-controller@8404318 {
+ compatible = "brcm,brcmstb-reset";
+ reg = <0x8404318 0x30>;
+ #reset-cells = <1>;
+ };
+
+ _switch {
+ resets = <>;
+ reset-names = "switch";
+ };
Re: [PATCH v3 lora-next 5/5] net: lora: sx125x sx1301: allow radio to register as a clk provider
Am 31.12.18 um 18:50 schrieb Mark Brown: > On Sun, Dec 30, 2018 at 11:55:46AM +0100, Andreas Färber wrote: >> Given that observed symptoms were CPU stalls, workqueue hangs and RCU >> problems, requiring a power-cycle to recover, I wonder whether we are >> running into some atomic/locking issue with clk_enable()? Is it valid at >> all to use SPI/regmap for clk_enable()? If it is, is there a known issue >> specific to spi-sun6i (A64) in 4.20.0? >> I already tried setting .disable_locking = true in both regmap_configs. >> Any suggestions how to further debug? > > You can't use SPI for clk_enable(), clk_enable() needs to be doable in > atomic context since we need to wait for the bus operations to complete > (you can start SPI transfers in atomic context but you still need to > wait for them to complete). Any clocks that are only accessible via a > slow bus like I2C or SPI need to do the enable/disable in the > prepare/unprepare operations which aren't done in atomic context. > > regmap can be used in atomic contexts, though you need to configure it > to use spinlocks instead of mutexes and ensure that no register cache > allocations happen during I/O (eg, by providing defaults for all > registers or by not using a cache). We have .cache_type = REGCACHE_NONE on both bus and spi regmap_configs. I moved the regmap_field_write() from .enable to .prepare and set .fast_io = true on both regmap_configs to force using spinlocks, but same hang as in .enable before... And same if I set .disable_locking = true on both. Given that it works with one SPI driver and not with the other, independent of the locking options applied, I assume my symptoms are not a regmap-layer issue. Is it allowed during a .prepare operation to call the mentioned clk_get_rate(), which ends up calling clk_prepare_lock()? According to my debug output in spi-sun6i.c our hanging regmap_field_write() ends up calling sun6i_transfer_one() three times, the first two look okay, but the third one doesn't make it past the clk_get_rate() or following if block. [But for now some fireworks...] Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v8 00/25] Re-use nvram module
On Sun, 30 Dec 2018, I wrote: > > The rationale for the ops struct was that it offers introspection. > > [...] those platforms which need checksum validation always set > byte-at-a-time methods to NULL. > > [...] The NULL methods in the ops struct allow the nvram.c misc device > to avoid inefficient byte-at-a-time accessors where possible, just as > arch/powerpc/kernel/nvram_64.c presently does. > Hopefully my message makes more sense with the tangential irrelevancies removed. I will document these considerations in nvram.h for the next revision. --
Re: [PATCH RESEND] KEYS: fix parsing invalid pkey info string
Hi David and Linus, On Mon, Dec 17, 2018 at 12:02:01PM -0800, Linus Torvalds wrote: > On Mon, Dec 17, 2018 at 11:51 AM James Bottomley > wrote: > > > > If this is to replace Eric's patch, didn't you want to set token_mask > > to (1< > No, let's not add any extra code that is trying to be subtle. Subtle > interactions was where the bug came from. > > The code already checks the actual Opt_xyz for errors in a switch > statement. The token_mask should be _purely_ about duplicate options > (or conflicting ones). > > Talking about the conflicting ones: Opt_hash checks that > Opt_policydigest isn't set. But Opt_policydigest doesn't check that > Opt_hash isn't set, so you can mix the two if you just do it in the > right order. > > But that's a separate bug, and doesn't seem to be a huge deal. > > But it *is* an example of how bogus all of this stuff is. Clearly > people weren't really paying attention when writing any of this code. > > Linus KEYCTL_PKEY_QUERY is still failing basic fuzzing even after Linus' fix that changed Opt_err from -1 to 0. The crash is still in keyctl_pkey_params_parse(): token = match_token(p, param_keys, args); if (__test_and_set_bit(token, _mask)) return -EINVAL; q = args[0].from; if (!q[0]) return -EINVAL; Now it crashes on '!q[0]' because 'args[0].from' is uninitialized when token == Opt_err. args[0] is only initialized when the parsed token had a pattern that set it. David, where are the tests for these new keyctls? - Eric
Re: [PATCH] nvmem: bcm-ocotp: Add ACPI support to BCM OCOTP
On 2018-12-26 7:39 p.m., Srinath Mannam wrote:
Add ACPI support to bcm ocotp driver
This patch is based on Linux-4.20-rc7.
Signed-off-by: Srinath Mannam
Acked-by: Scott Branden
---
drivers/nvmem/bcm-ocotp.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 4159b3f..a809751 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -11,13 +11,14 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
#include
#include
#include
-#include
+#include
#include
/*
@@ -78,9 +79,9 @@ static struct otpc_map otp_map_v2 = {
};
struct otpc_priv {
- struct device *dev;
- void __iomem*base;
- struct otpc_map *map;
+ struct device *dev;
+ void __iomem *base;
+ const struct otpc_map *map;
struct nvmem_config *config;
};
@@ -237,16 +238,22 @@ static struct nvmem_config bcm_otpc_nvmem_config = {
};
static const struct of_device_id bcm_otpc_dt_ids[] = {
- { .compatible = "brcm,ocotp" },
- { .compatible = "brcm,ocotp-v2" },
+ { .compatible = "brcm,ocotp", .data = _map },
+ { .compatible = "brcm,ocotp-v2", .data = _map_v2 },
{ },
};
MODULE_DEVICE_TABLE(of, bcm_otpc_dt_ids);
+static const struct acpi_device_id bcm_otpc_acpi_ids[] = {
+ { .id = "BRCM0700", .driver_data = (kernel_ulong_t)_map },
+ { .id = "BRCM0701", .driver_data = (kernel_ulong_t)_map_v2 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, bcm_otpc_acpi_ids);
+
static int bcm_otpc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *dn = dev->of_node;
struct resource *res;
struct otpc_priv *priv;
struct nvmem_device *nvmem;
@@ -257,14 +264,9 @@ static int bcm_otpc_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- if (of_device_is_compatible(dev->of_node, "brcm,ocotp"))
- priv->map = _map;
- else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
- priv->map = _map_v2;
- else {
- dev_err(dev, "%s otpc config map not defined\n", __func__);
- return -EINVAL;
- }
+ priv->map = device_get_match_data(dev);
+ if (!priv->map)
+ return -ENODEV;
/* Get OTP base address register. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -281,7 +283,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
reset_start_bit(priv->base);
/* Read size of memory in words. */
- err = of_property_read_u32(dn, "brcm,ocotp-size", _words);
+ err = device_property_read_u32(dev, "brcm,ocotp-size", _words);
if (err) {
dev_err(dev, "size parameter not specified\n");
return -EINVAL;
@@ -294,7 +296,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
bcm_otpc_nvmem_config.dev = dev;
bcm_otpc_nvmem_config.priv = priv;
- if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2")) {
+ if (priv->map == _map_v2) {
bcm_otpc_nvmem_config.word_size = 8;
bcm_otpc_nvmem_config.stride = 8;
}
@@ -315,6 +317,7 @@ static struct platform_driver bcm_otpc_driver = {
.driver = {
.name = "brcm-otpc",
.of_match_table = bcm_otpc_dt_ids,
+ .acpi_match_table = ACPI_PTR(bcm_otpc_acpi_ids),
},
};
module_platform_driver(bcm_otpc_driver);
Re: [GIT PULL] tracing: Update for 4.21
On Mon, 31 Dec 2018 11:50:18 -0800 Linus Torvalds wrote: > > OK, I'll modify my script not to make that diff. > > For small "fixes" pulls, the diffs are nice, and you actually see the > details of the fixes. But for big things, the full diff is usually > only a distraction. > > I think the x86 maintainers have a script where it adds the diff if > it's less than a hundred lines or something like that.. > I can look into adding a size limit check, or perhaps it may be good enough to just remove the diff for merge window pull requests, as those tend to be the big ones. -- Steve
general protection fault in ax25_send_frame
Hello, syzbot found the following crash on: HEAD commit:90cadbbf341d Merge git://git.kernel.org/pub/scm/linux/kern.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=17127500c0 kernel config: https://syzkaller.appspot.com/x/.config?x=f9a32c9a4aef9af7 dashboard link: https://syzkaller.appspot.com/bug?extid=e0b81535a27b8be39502 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e0b81535a27b8be39...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access kobject: 'loop3' (a0e7275a): kobject_uevent_env general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 18625 Comm: blkid Not tainted 4.20.0-rc7+ #361 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ax25_send_frame+0xe2/0x570 net/ax25/ax25_out.c:59 kobject: 'loop3' (a0e7275a): fill_kobj_path: path = '/devices/virtual/block/loop3' Code: 34 91 00 00 48 85 c0 0f 85 c2 03 00 00 e8 d6 bd 7e fa 48 8d bb 38 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 ea 03 00 00 48 8b 83 38 03 00 00 48 85 c0 48 89 RSP: 0018:8880ae707518 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 11100a4e3951 RDX: 0067 RSI: 86ff9d4a RDI: 0338 RBP: 8880ae707558 R08: 88805271ca88 R09: 0002 R10: R11: 88805271c1c0 R12: 88809aec1a88 R13: 8be98280 R14: 0104 R15: FS: () GS:8880ae70() knlGS: kobject: 'loop2' (16318dbe): kobject_uevent_env CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff26e69ed8 CR3: 97648000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: rose_send_frame+0xda/0x280 net/rose/rose_link.c:109 rose_transmit_clear_request+0x1de/0x2a0 net/rose/rose_link.c:258 rose_rx_call_request+0x4ea/0x1c90 net/rose/af_rose.c:999 rose_loopback_timer+0x26a/0x3f0 net/rose/rose_loopback.c:100 call_timer_fn+0x272/0x920 kernel/time/timer.c:1326 kobject: 'loop2' (16318dbe): fill_kobj_path: path = '/devices/virtual/block/loop2' expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7e5/0xc70 kernel/time/timer.c:1682 kobject: 'loop5' (d24778f2): kobject_uevent_env kobject: 'loop5' (d24778f2): fill_kobj_path: path = '/devices/virtual/block/loop5' run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1695 __do_softirq+0x30c/0xb2e kernel/softirq.c:292 kobject: 'loop3' (a0e7275a): kobject_uevent_env invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x17f/0x1c0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061 kobject: 'loop3' (a0e7275a): fill_kobj_path: path = '/devices/virtual/block/loop3' apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 RIP: 0010:write_comp_data+0x1/0x70 kernel/kcov.c:116 Code: e5 90 43 00 e9 a6 fc ff ff 4c 89 f7 e8 38 90 43 00 e9 6f fc ff ff e8 9e b7 c9 ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 <48> 89 e5 65 4c 8b 04 25 40 ee 01 00 65 8b 05 0c 93 83 7e a9 00 01 RSP: 0018:888090d1f088 EFLAGS: 0246 ORIG_RAX: ff13 kobject: 'loop2' (16318dbe): kobject_uevent_env RAX: RBX: 7f538b24f000 RCX: 81b177ab RDX: RSI: RDI: 0005 RBP: 888090d1f098 R08: 88805271c1c0 R09: f9452236 R10: f9452236 R11: ea2911b3 R12: 0025 R13: ea2911c8 R14: dc00 R15: ea2911c0 kobject: 'loop2' (16318dbe): fill_kobj_path: path = '/devices/virtual/block/loop2' zap_pte_range mm/memory.c:1082 [inline] zap_pmd_range mm/memory.c:1193 [inline] zap_pud_range mm/memory.c:1222 [inline] zap_p4d_range mm/memory.c:1243 [inline] unmap_page_range+0xc4b/0x25b0 mm/memory.c:1264 kobject: 'loop0' (f27d2df2): kobject_uevent_env kobject: 'loop0' (f27d2df2): fill_kobj_path: path = '/devices/virtual/block/loop0' unmap_single_vma+0x19b/0x310 mm/memory.c:1309 unmap_vmas+0x125/0x200 mm/memory.c:1339 exit_mmap+0x2be/0x590 mm/mmap.c:3145 kobject: 'loop3' (a0e7275a): kobject_uevent_env __mmput kernel/fork.c:1045 [inline] mmput+0x247/0x610 kernel/fork.c:1066 kobject: 'loop3' (a0e7275a): fill_kobj_path: path = '/devices/virtual/block/loop3' exit_mm kernel/exit.c:545 [inline] do_exit+0xe74/0x26d0 kernel/exit.c:854 kobject: 'loop5' (d24778f2): kobject_uevent_env kobject: 'loop5' (d24778f2): fill_kobj_path:
[GIT PULL] v4.21 Updates for OpenRISC
Hi Linus, Please consider for pull, The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd: Linux 4.20-rc7 (2018-12-16 15:46:55 -0800) are available in the Git repository at: git://github.com/openrisc/linux.git tags/for-linus for you to fetch changes up to 57ce8ba0fd3a95bf29ed741df1c52bd591bf43ff: openrisc: Fix broken paths to arch/or32 (2018-12-20 00:04:39 +0900) OpenRISC updates for 4.21 Just one change for 4.21: - Update comments for name change or32 -> or1k from Geert Uytterhoeven Geert Uytterhoeven (1): openrisc: Fix broken paths to arch/or32 arch/openrisc/kernel/entry.S | 2 +- arch/openrisc/kernel/head.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver
Hi, * Tony Lindgren [181228 22:28]: > With droid4-pending-mdm-v4.20 branch in the following state: > > - UARTs idled > - LCD blanked (well no drivers yet droid4-sms-read.rb) > - MUSB and EHCI USB modules unloaded > - OHCI loaded with all the children in autosuspend via sysfs > - WLAN connected > - busybox acpid stopped (yup, it keeps polling something???) > - MDM6600 online with AT+CFUN=1 on /dev/motmdm1 > - MDM6600 notifications disabled with AT+SCRN=0 on /motmdm1 > - droid4-sms-read.rb running So I tracked down what I thought is a busybox acpid issue, I was wrong. There's nothing wrong with busybox acpid, sorry for blaming a wrong culprit. We have acpid keep the device open for /dev/input/by-path/platform-48072000.i2c-event open, which seems to keep atmel_mxt_ts and i2c busy. Things idle fine after I rmmod atmel_mxt_ts after blanking the screen. Regards, Tony
Re: [PATCH v5 0/3] Stingray thermal driver support
On 04/12/2018 19:17, Srinath Mannam wrote: > Hi, > > Could you please provide your feedback to this patch series? Rui or Eduardo can we get either one of you to review the thermal driver parts of this patch series? Why do we constantly have to chase people to respond in this specific subsystem? > > Regards, > Srinath. > On Thu, Nov 8, 2018 at 3:45 AM Florian Fainelli wrote: >> >> >> >> On 10/16/2018 8:11 AM, Srinath Mannam wrote: >>> These patches adds the stingray thermal driver and its >>> corresponding DT nodes with documentation. >> >> Can we get feedback from the thermal maintains whether this is >> acceptable or not? >> >>> >>> Changes from v4 >>> - Addressed Rob Herring comments on DT parameters and >>> thermal driver architecture. >>> - Removed brcm,max-crit-temp DT parameter >>> - Changed driver to thermal sensor registration model. >>> - Added trip DT properties. >>> >>> Changes from v3 >>> - Addressed Daniel lezcano comments. >>> - Elaborated commit description of thermal driver patch. >>> - Added brcm,max-crit-temp DT parameter. >>> >>> Changes from v2: >>> - All stingray TMON DT nodes are combine together into single. >>> Temperature registers are combined into one mem resource. >>> brcm,tmon-mask parameter has available TMONs mask value. >>> - All available TMONs are initialized together in single >>> instance of driver probe call. >>> >>> Changes from v1: >>> - Fixed auto build sparce warning. >>> >>> Pramod Kumar (3): >>> dt-bindings: thermal: Add binding document for SR thermal >>> thermal: broadcom: Add Stingray thermal driver >>> arm64: dts: stingray: Add Stingray Thermal DT support. >>> >>> .../bindings/thermal/brcm,sr-thermal.txt | 105 >>> .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 89 + >>> drivers/thermal/Kconfig| 3 +- >>> drivers/thermal/broadcom/Kconfig | 9 ++ >>> drivers/thermal/broadcom/Makefile | 1 + >>> drivers/thermal/broadcom/sr-thermal.c | 138 >>> + >>> 6 files changed, 344 insertions(+), 1 deletion(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt >>> create mode 100644 drivers/thermal/broadcom/sr-thermal.c >>> >> >> -- >> Florian -- Florian
Re: [GIT PULL] Documentation for 5.0
On Sat, 29 Dec 2018 11:24:34 -0800 Linus Torvalds wrote: > New signing key? And one that you forgot to push out to keyservers? Sort of...some time ago, I tried to be a good kid and made a separate signing subkey like Konstantin told me to. Then I couldn't ever get the nitrokey thing to work and then got distracted; I guess I never uploaded that key. I'm not really sure why gpg decided to start using it now. It's uploaded now, anyway. TLDR: I kind of suck at this gpg thing. Sorry for the confusion. jon
[GIT PULL 1/4] ARM: SoC platform updates
SoC updates, mostly refactorings and cleanups of old legacy platforms, but also a few more things: New SoC support this release: - NXP/Freescale i.MX7ULP (1x Cortex-A7, Cortex-M4, graphics, etc) - Allwinner F1C100, older platform with an ARM926-EJS (ARMv5) core Cleanups of various platforms: - OMAP1 ams-delta does some GPIO cleanups - Davinci removes of at24 platform data - Samsung cleans up old wakeup, PM debug and secondary core boot code - Renesas moves around config options and PM code to drivers/soc for sharing with 64-bit and more consistency - i.MX, Broadcom and SoCFPGA all have tweaks to lowlevel debug console setups - SoCFPGA adds explicit selection of ARM errata and removes some unused code This tag also contains a few patches that I had queued up as fixes for 4.20 but didn't send in before the release. Conflicts: arch/arm/mach-omap1/board-ams-delta.c: Change/remove. Remove the code that's in conflict (the leds/gpio init functions) arch/arm/mach-socfpga/Kconfig: Add/change. Keep new set of errata and PCI_DOMAINS_GENERIC, drop PCI_DOMAINS. The following changes since commit f12e840c819bab42621685558a01d3f46ab9a226: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc for you to fetch changes up to cac1fc8fb561ac766468394d49c3dd11a2b8cb44: Merge branch 'fixes' into next/soc A.s. Dong (1): ARM: imx: add initial support for imx7ulp Aaro Koskinen (4): ARM: OMAP1/2: fix SoC name printing ARM: OMAP1: devices: configure omap1_spi100k only on OMAP7xx ARM: OMAP1: add MMC configuration for Palm Tungsten E ARM: OMAP1: fix USB configuration for device-only setups Arnd Bergmann (8): ARM: imx: fix dependencies on imx7ulp ARM: mmp: fix timer_init calls ARM: mmp: fix pxa168_device_usb_phy use on aspenite ARM: pxa: avoid section mismatch warning ARM: ks8695: fix section mismatch warning ARM: tegra: avoid section mismatch warning ARM: omap2: avoid section mismatch warning Merge tag 'renesas-fixes2-for-v4.20' of git://git.kernel.org/.../horms/renesas into fixes Bartlomiej Zolnierkiewicz (2): ARM: exynos: Remove no longer needed s3c_pm_check_*() calls ARM: samsung: Limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms Bartosz Golaszewski (7): ARM: davinci: dm365-evm: use cell nvmem lookup for mac address ARM: davinci: dm644x-evm: use cell nvmem lookup for mac address ARM: davinci: dm646x-evm: use cell nvmem lookup for mac address ARM: davinci: da830-evm: use cell nvmem lookup for mac address ARM: davinci: mityomapl138: use cell nvmem lookup for mac address ARM: davinci: dm850-evm: use cell nvmem lookup for mac address ARM: davinci: da850-evm: remove unnecessary include Carlo Caione (1): MAINTAINERS: Remove myself from the list Clément Péron (2): ARM: debug: enable UART1 for socfpga Cyclone5 ARM: socfpga: Clean unused functions Corentin Labbe (1): MAINTAINERS: add drivers/soc/amlogic/ to amlogic list Dinh Nguyen (1): ARM: socfpga: Turn on ARM errata for L2 cache Felix Brack (1): ARM: dts: am335x-pdu001: Fix polarity of card detection input Florian Fainelli (2): ARM: BCM63XX: Enable reset controller support Merge tag 'tags/bcm2835-soc-next-2018-11-27' into soc/next Geert Uytterhoeven (9): ARM: shmobile: Restrict SCU support to SoCs that have it ARM: shmobile: Restrict TWD support to SoCs that have it ARM: shmobile: sh73a0: Remove obsolete inclusion of ARM: shmobile: Hide ARCH_RZN1 to improve consistency arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/ ARM: shmobile: Move SoC Kconfig symbols to drivers/soc/renesas/ ARM: OMAP2+: timer: Remove obsolete inclusion of ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/ Gerald Baeza (1): ARM: stm32: debug: add low-level debug support Janusz Krzysztofik (6): ARM: OMAP1: ams-delta: make board header file local to mach-omap1 ARM: OMAP1: ams-delta: Provide GPIO lookup table for LED device ARM: OMAP1: ams-delta: Drop board specific global GPIO numbers ARM: OMAP1: ams-delta: Drop unused symbols from the board header ARM: OMAP1: ams-delta: Move AMS_DELTA_LATCH2_NGPIO to the board file ARM: OMAP1: ams-delta: Fix audio permanently muted Justin Chen (1): ARM: brcmstb: Add entry for 7255 Krzysztof Kozlowski (2): ARM: s5pv210: Remove legacy setting of external wakeup interrupts ARM: exynos: Remove legacy setting of external wakeup interrupts Laurent Pinchart (1): arm64: dts:
[GIT PULL 2/4] ARM: SoC driver updates
Misc driver updates for platforms, many of them power related.
- Rockchip adds power domain support for rk3066 and rk3188
- Amlogic adds a power measurement driver
- Allwinner adds SRAM support for three platforms (F1C100, H5, A64 C1)
- Wakeup and ti-sysc (platform bus) fixes for OMAP/DRA7
- Broadcom fixes suspend/resume with Thumb2 kernels, and improves
stability of a handful of firmware/platform interfaces
- PXA completes their conversion to dmaengine framework
- Renesas does a bunch of PM cleanups across many platforms
- Tegra adds support for suspend/resume on T186/T194, which includes
some driver cleanups and addition of wake events
- Tegra also adds a driver for memory controller (EMC) on Tegra2
- i.MX tweaks power domain bindings, and adds support for i.MX8MQ in GPC
- Atmel adds identifiers and LPDDR2 support for a new SoC, SAM9X60
+ misc cleanups across several platforms
The following changes since commit b0e8b6ef5408a5b97c4fa8c835599e67ff4a0e3d:
Merge tag 'armsoc-soc' into HEAD
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/armsoc-drivers
for you to fetch changes up to a6f119a06960ef1dc30570401e43b71f9ebdd2c2:
Merge tag 'omap-for-v4.21/driver-part2-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
next/drivers
A.s. Dong (1):
firmware: imx: add SCU power domain driver
Alok Chauhan (1):
soc: qcom: Add irq clear handling during SE init
Arnd Bergmann (1):
soc: qcom/llcc: add MODULE_LICENSE tag
Arun Kumar Neelakantam (1):
soc: qcom: qmi_interface: Limit txn ids to U16_MAX
Bjorn Andersson (1):
soc: qcom: smd-rpm: Add QCS404 compatible
Bo Yan (1):
soc/tegra: fuse: Remove duplicated function declaration
Corentin Labbe (1):
soc: amlogic: meson-clk-measure: Add missing REGMAP_MMIO dependency
Dmitry Osipenko (2):
memory: tegra: Introduce Tegra20 EMC driver
soc/tegra: pmc: Drop locking from tegra_powergate_is_powered()
Florian Fainelli (2):
soc: bcm: brcmstb: Fix re-entry point with a THUMB2_KERNEL
Merge tag 'tags/bcm2835-drivers-next-2018-11-27' into drivers/next
Geert Uytterhoeven (9):
soc: renesas: r8a77965-sysc: Remove non-existent A3IR power domain
soc: renesas: r8a77970-sysc: Remove non-existent CR7 power domain
soc: renesas: r8a77970-sysc: Correct names of A2DP/A2CN power domains
soc: renesas: r8a77980-sysc: Correct names of A2DP[01] power domains
soc: renesas: r8a77980-sysc: Correct A3VIP[012] power domain hierarchy
soc: renesas: r8a77990-sysc: Fix initialization order of 3DG-{A,B}
soc: renesas: rcar-sysc: Remove rcar_sysc_power_{down,up}() helpers
soc: renesas: rcar-sysc: Merge PM Domain registration and linking
soc: renesas: rcar-sysc: Fix power domain control after system resume
Heiko Stuebner (6):
dt-bindings: add power-domain header for RK3188 SoCs
dt-bindings: add power-domain header for RK3066 SoCs
dt-bindings: add compatibles for rk3066/rk3188 power controllers
Merge branch 'v4.21-shared/pdids' into v4.21-armsoc/drivers
soc: rockchip: power-domain: add rk3188 powerdomains
soc: rockchip: power-domain: add rk3066 powerdomains
Houlong Wei (1):
soc: mediatek: Add Mediatek CMDQ helper
James Hughes (1):
firmware: raspberrypi: Fix firmware calls with large buffers
Jon Hunter (1):
soc/tegra: pmc: Don't power-up XUSB power-domains
Jordan Crouse (1):
soc: qcom: llcc-slice: Add error checks for API functions
Keerthy (1):
soc: ti: wkup_m3: Add PRCM int16 as the wake up source
Leonard Crestez (1):
soc: imx: gpc: Increase GPC_CLK_MAX to 7
Lucas Stach (3):
soc: imx: gpcv2: prefix i.MX7 specific defines
soc: imx: gpcv2: move register access table to domain data
soc: imx: gpcv2: add support for i.MX8MQ SoC
Maxime Jourdan (1):
drivers: soc: Allow building the amlogic drivers without ARCH_MESON
Mesih Kilinc (1):
dt-bindings: sram: Add Allwinner suniv F1C100s
Neil Armstrong (2):
dt-bindings: amlogic: Add Internal Clock Measurer bindings
soc: amlogic: Add Meson Clock Measure driver
Nicolas Ferre (1):
ARM: at91: add support in soc driver for LPDDR2 SiP
Niklas Cassel (1):
soc: qcom: Drop help text for QCOM_QMI_HELPERS
Olof Johansson (16):
Merge tag 'v4.21-rockchip-drivers-1' of
git://git.kernel.org/.../mmind/linux-rockchip into next/drivers
Merge tag 'amlogic-drivers' of
https://git.kernel.org/.../khilman/linux-amlogic into next/drivers
Merge tag 'omap-for-v4.21/driver-signed' of
git://git.kernel.org/.../tmlind/linux-omap into next/drivers
Merge tag 'arm-soc/for-4.21/drivers' of
https://github.com/Broadcom/stblinux into next/drivers
Merge tag 'qcom-drivers-for-4.21' of
[GIT PULL 0/4] ARM: SoC changes for v4.21
Hi Linus, Here's the batch of changes for arm-soc for this merge window. It's arriving later than I had planned for, the holidays messed up schedules and time availability a lot at my end this year. As for the material itself, it's pretty straight forward. The only branch with conflicts is the SoC one, I mention in that email how to resolve them. Most of the new material is in the DT branch (as always), and that pull request also contains the overview of new platforms, etc. In addition to this we have a branch with some late-merged material that I'm letting sit for a few days and might send in towards the end of the merge window if things have been going smoothly. Thanks, -Olof
[GIT PULL 3/4] ARM: Device-tree updates
As usual, this is where the bulk of our changes end up landing each merge window. The individual updates are too many to enumerate, many many platforms have seen additions of device descriptions such that they are functionally more complete (in fact, this is often the bulk of updates we see). Instead I've mostly focused on highlighting the new platforms below as they are introduced. Sometimes the introduction is of mostly a fragment, that later gets filled in on later releases, and in some cases it's near-complete platform support. The latter is more common for derivative platforms that already has similar support in-tree. Two SoCs are slight outliers from the usual range of additions. Allwinner support for F1C100s, a quite old SoC (ARMv5-based) shipping in the Lychee Pi Nano platform. At the other end is NXP Layerscape LX2160A, a 16-core 2.2GHz Cortex-A72 SoC with a large amount of I/O aimed at infrastructure/networking. TI updates stick out in the diff stats too, in particular because they have moved the description of their L4 on-chip interconnect to devicetree, which opens up for removal of even more of their platform-specific 'hwmod' description tables over the next few releases. SoCs: - Qualcomm QCS404 (4x Cortex-A53) - Allwinner T3 (rebranded R40) and f1c100s (armv5) - NXP i.MX7ULP (1x Cortex-A7 + 1x Cortex-M4) - NXP LS1028A (2x Cortex-A72), LX2160A (16x Cortex-A72) New platforms: - Rockchip: Gru Scarlet (RK3188 Tablet) - Amlogic: Phicomm N1 (S905D), Libretech S805-AC - Broadcom: Linksys EA6500 v2 Wi-Fi router (BCM4708) - Qualcomm: QCS404 base platform and EVB - Qualcomm: Remove of Arrow SD600 - PXA: First PXA3xx DT board: Raumfeld - Aspeed: Facebook Backpack-CMM BMC - Renesas iWave G20D-Q7 (RZ/G1N) - Allwinner t3-cqa3t-bv3 (T3/R40) and Lichee Pi Nano (F1C100s) - Allwinner Emlid Neutis N5, Mapleboard MP130 - Marvell Macchiatobin Single Shot (Armada 8040, no 10GbE) - i.MX: mtrion emCON-MX6, imx6ul-pico-pi, imx7d-sdb-reva - VF610: Liebherr's BK4 device, ZII SCU4 AIB board - i.MX7D PICO Hobbit baseboard - i.MX7ULP EVK board - NXP LX2160AQDS and LX2160ARDB boards Other: - Coresight binding updates across the board - CPU cooling maps updates across the board The following changes since commit e97aa8e759e6b01d37ba8bafff59aa63bed24f8d: Merge tag 'armsoc-drivers' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt for you to fetch changes up to 3f47de2c6b6068cf7d5221f8f307969e7e4f1fc5: Merge tag 'samsung-dt-4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/dt A.s. Dong (4): dt-bindings: fsl: add compatible for imx7ulp evk dt-bindings: fsl: add imx7ulp pm related components bindings ARM: dts: imx: add common imx7ulp dtsi support ARM: dts: imx: add imx7ulp evk support Adam Ford (1): ARM: dts: am3517-evm: Enable earlycon stdout path Aisheng Dong (7): ARM: dts: imx6sx-sdb: add flexcan support ARM: dts: imx6sx-sabreauto: add flexcan support ARM: dts: imx6qdl-sabreauto: add flexcan support ARM: dts: imx6sx: Add flexcan stop mode wakeup support ARM: dts: imx6qdl: Add flexcan stop mode wakeup support ARM: dts: imx6ul: Add flexcan stop mode wakeup support ARM: dts: imx7s: Add flexcan stop mode wakeup support Aleksandr Aleksandrov (2): dt-bindings: vendor-prefix: new vendor - Emlid arm64: dts: allwinner: new board - Emlid Neutis N5 Alex Gonzalez (4): ARM: dts: imx6ul: ccimx6ulsom: Add support for wireless SOM variant ARM: dts: imx6ul: ccimx6ulsom: Fix indentation on iomuxc nodes ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller Alexandre Belloni (7): ARM: dts: at91: sama5d4: switch to new clock bindings ARM: dts: at91: sama5d2: switch to new clock binding ARM: dts: at91: at91sam9260: switch to new clock bindings ARM: dts: at91: at91sam9261: switch to new clock bindings ARM: dts: at91: at91sam9263: switch to new clock bindings ARM: dts: at91: at91sam9x5: switch to new clock bindings ARM: dts: at91: at91sam9rl: switch to new clock bindings Amit Kucheria (8): MAINTAINERS: Add entry for Qualcomm TSENS thermal drivers ARM: dts: msm8974: thermal: split address space into two ARM: dts: msm8974: thermal: Add "qcom,sensors" property arm64: dts: msm8916: thermal: split address space into two arm64: dts: msm8916: thermal: Add "qcom,sensors" property arm64: dts: msm8916: Add gpu thermal zone arm64: dts: msm8916: Add camera thermal zone arm64: dts: sdm845: enable tsens thermal zones Anand Moon (5): ARM: dts: exynos: Add UHS-I bus speed support to Odroid XU3/XU4/HC1 ARM: dts: exynos: Fix
[GIT PULL 4/4] ARM: SoC defconfig updates
Most changes here are to enable new drivers and platforms in the various configs that affect them. Most of these have been covered and described in the other branches, we mostly keep defconfig separate to avoid conflicts between SoC/dt/driver updates that they otherwise would be grouped with. One thing worth mentioning here is that OMAP changes from using their own UART driver, to 8250, for the multi_v7_defconfig shared config on 32-bit. This means that the console is now named ttyS* instead of ttyO*. This change was already done for omap2_defconfig a while back, so most users of these configs have either already updated, or can easily follow the same patterns as they did at that time. This makes platform support slightly easier for distros, since they no longer need to keep track of a separate console prefix for these platforms. The following changes since commit f7f6260f0489617b49176f1b30e2cdd5c43e0918: Merge tag 'armsoc-dt' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-defconfig for you to fetch changes up to 82c7b351be3fad005ba38a26f7f1ab7f0841e505: Revert "arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO" A.s. Dong (1): ARM: imx_v6_v7_defconfig: add imx7ulp support Adam Ford (1): ARM: omap2plus_defconfig: Add tlv320aic23 as module Alex Gonzalez (1): ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX Andreas Müller (2): ARM: imx_v6_v7_defconfig: Enable BT_BNEP ARM: imx_v6_v7_defconfig: Enable USB_ANNOUNCE_NEW_DEVICES Bjorn Andersson (4): arm64: defconfig: Enable QCS404 configs arm64: defconfig: Enable some qcom remoteproc configs arm64: defconfig: Enable core Qualcomm SDM845 options arm64: defconfig: Enable GCC and PINCTRL for MSM8998 Fabio Estevam (1): ARM: imx_v6_v7_defconfig: Select the PXP driver Fabrice Gasnier (1): ARM: multi_v7_defconfig: enable STM32 analog & timer drivers Fabrizio Castro (1): ARM: shmobile: defconfig: Enable SII902X Horia Geantă (1): Revert "arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO" Jagan Teki (4): arm64: defconfig: Enable MFD_AXP20X_I2C arm64: defconfig: Enable DRM_SUN8I_MIXER arm64: defconfig: Enable DRM_SUN8I_DW_HDMI arm64: defconfig: Enable PWM_SUN4I Jan Tuerk (1): ARM: imx_v6_v7_defconfig: Enable DA9063 PMIC support Leonard Crestez (1): ARM: imx_v6_v7_defconfig: Enable CRYPTO_DEV_MXS_DCP Linus Walleij (2): ARM: defconfig: Update the vexpress defconfig ARM: defconfig: Enable the PL111 DRM driver on vexpress Marc Gonzalez (3): arm64: defconfig: Regenerate for v4.20 arm64: defconfig: Replace PINCTRL_MT7622 with PINCTRL_MTK_MOORE arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO Marek Szyprowski (5): ARM: exynos_defconfig: Add MAX8998 RTC and charger drivers ARM: exynos_defconfig: Add MAX8952 regulator driver ARM: exynos_defconfig: Add TOSHIBA TC358764 bridge driver ARM: multi_v7_defconfig: Add MAX8952 regulator driver ARM: multi_v7_defconfig: Add TOSHIBA TC358764 bridge driver Olof Johansson (7): Merge tag 'vexpress-defconfig-arm-soc' of git://git.kernel.org/.../linusw/linux-integrator into next/defconfig Merge tag 'omap-for-v4.21/defconfig-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/defconfig Merge tag 'qcom-arm64-defconfig-for-4.21' of git://git.kernel.org/.../agross/linux into next/defconfig Merge tag 'renesas-arm-defconfig-for-v4.21' of https://git.kernel.org/.../horms/renesas into next/defconfig Merge tag 'sunxi-config64-for-4.21' of https://git.kernel.org/.../sunxi/linux into next/defconfig Merge tag 'samsung-defconfig-4.21' of https://git.kernel.org/.../krzk/linux into next/defconfig Merge tag 'imx-defconfig-4.21' of git://git.kernel.org/.../shawnguo/linux into next/defconfig Otavio Salvador (1): ARM: imx_v6_v7_defconfig: Remove explicit ARM_UNWIND disable Tony Lindgren (2): Merge branch 'omap-for-v4.20/defconfig' into omap-for-v4.21/defconfig ARM: multi_v7_defconfig: Enable 8250-omap serial driver and use it by default arch/arm/configs/exynos_defconfig| 4 + arch/arm/configs/imx_v6_v7_defconfig | 10 ++- arch/arm/configs/multi_v7_defconfig | 13 +++ arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/configs/shmobile_defconfig | 1 + arch/arm/configs/vexpress_defconfig | 24 ++ arch/arm64/configs/defconfig | 128 -- 7 files changed, 105 insertions(+), 76 deletions(-)
Re: [PATCH v4 08/11] ASoC: Intel: atom: Make PCI dependency explicit
On 12/31/18 2:35 PM, Sinan Kaya wrote: On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart wrote: On 12/31/18 1:35 PM, Sinan Kaya wrote: On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote: On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote: On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote: I don't have the cover letter or anything for this series, what's going on with dependencies? Here is the executive summary: I have a changeset that separates ACPI from PCI on 4.21. CONFIG_ACPI used to select PCI. This is no longer true. You can build an ACPI system without any PCI devices. So there's no dependency and I can just apply this? The plan is to apply this patchset via ACPI tree. Need an Acked-by per patch. Anytime we change the Kconfig settings for audio, we get all kinds of problems with randconfig and 0day/kbuild due to depend/select issues. I'd like to give this a spin first, can you share a link to the entire series? Thanks! Sure, You can find them here https://lore.kernel.org/patchwork/patch/1028330/ Click related. Something must be missing, I get compilation errors when PCI is not defined? And I see tons of references to pci stuff in drivers/acpi. drivers/acpi/reboot.c: In function ‘acpi_reboot’: drivers/acpi/reboot.c:37:10: error: implicit declaration of function ‘pci_find_bus’; did you mean ‘pci_find_next_bus’? [-Werror=implicit-function-declaration] bus0 = pci_find_bus(0, 0); ^~~~ pci_find_next_bus drivers/acpi/reboot.c:37:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion] bus0 = pci_find_bus(0, 0); ^ drivers/acpi/reboot.c:45:3: error: implicit declaration of function ‘pci_bus_write_config_byte’; did you mean ‘pci_write_config_byte’? [-Werror=implicit-function-declaration] pci_bus_write_config_byte(bus0, devfn, ^ pci_write_config_byte
Re: [GIT PULL] tee subsys for v4.21
On Wed, Dec 12, 2018 at 01:31:21PM +0100, Jens Wiklander wrote: > Hello arm-soc maintainers, > > Please pull this small OP-TEE driver enhancement. A friendly log message > is added to inform that dynamic shared memory is used when initiazing > the OP-TEE driver. > > Thanks, > Jens > > The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d: > > Linux 4.20-rc6 (2018-12-09 15:31:00 -0800) > > are available in the Git repository at: > > https://git.linaro.org/people/jens.wiklander/linux-tee.git > tags/tee-subsys-optee-for-4.21 > > for you to fetch changes up to 3c15ddb97c77f34ba009910becd5921f169770a2: > > tee: optee: log message if dynamic shm is enabled (2018-12-11 14:38:40 > +0100) Same as the other branch, queued this in next/late for now. Will send at end of week. -Olof
Re: [GIT PULL 2/2] arm64: dts: exynos: Second round for v4.21
On Tue, Dec 18, 2018 at 09:10:03PM +0100, Krzysztof Kozlowski wrote: > Hi, > > On top of previous pull request. > > Best regards, > Krzysztof > > > The following changes since commit 9deffb5ee78e41e2a5d6c448874a24caec6467d0: > > arm64: dts: exynos: Add all CPUs in cooling maps (2018-11-18 15:18:42 +0100) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt64-4.21-2 > > for you to fetch changes up to 74ebbdda7cecf789661c208faccbeef10a7f05da: > > arm64: dts: exynos: Add Bluetooth chip to TM2(e) boards (2018-12-17 > 20:23:32 +0100) Merged into next/late. Thanks, -Olof
Re: [PATCH v7 00/11] Add initial RDA8810PL SoC and Orange Pi boards support
On Tue, Dec 18, 2018 at 08:32:27PM +0530, Manivannan Sadhasivam wrote: > Hello Maintainers, > > This patch series adds initial RDA8810PL SoC and Orange Pi boards (2G IoT and > i96) support. RDA8810PL is an ARM Cortex A5 based SoC with Vivante's GC860 > GPU. The SoC has been added as a new ARM sub architecture with myself as the > maintainer. > > More information about the boards can be found in below links: > > 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/ > 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/ > > All patches are reviewed by the corresponding subsystem maintainers. The > clocksource and irqchip patches are reviewed and merged while the serial > driver got review from Greg but I'm not sure who will apply it. > > So as per my discussion with Arnd, sending the individual patches instead > of a Pull request so that the rest of the patches can go through the > ARM SoC tree. > > Please consider applying it. Hi, I've applied this series to our next/late branch. It's a branch we'll try to get merged by the end of the merge window, but it's not a guarantee that we'll be able to get it done. If not, the material will be moved to the next release instead. Thanks! -Olof
Re: [GIT PULL] tee driver fix for v4.21
On Thu, Dec 13, 2018 at 08:29:06AM +0100, Jens Wiklander wrote: > On Wed, Dec 12, 2018 at 11:16 PM Olof Johansson wrote: > > > > On Wed, Dec 12, 2018 at 01:28:00PM +0100, Jens Wiklander wrote: > > > Hello arm-soc maintainers, > > > > > > Please pull this tee driver fix for a possible double list_del() in the > > > OP-TEE driver while uninitializing. > > > > > > Thanks, > > > Jens > > > > > > The following changes since commit > > > 40e020c129cfc991e8ab4736d2665351ffd1468d: > > > > > > Linux 4.20-rc6 (2018-12-09 15:31:00 -0800) > > > > > > are available in the Git repository at: > > > > > > https://git.linaro.org/people/jens.wiklander/linux-tee.git > > > tags/tee-subsys-fix-for-4.21 > > > > > > for you to fetch changes up to b2d102bd0146d9eb1fa630ca0cd19a15ef2f74c8: > > > > > > tee: optee: avoid possible double list_del() (2018-12-11 14:38:21 +0100) > > > > > > > > > Avoid possible double list_del in supplicant comms > > > > > > A fix for the OP-TEE driver to avoid possible double list_del during > > > tee-supplicant communication while the system is shutting down. > > > > Do you want this for 4.20 or 4.21? Seems like .20 material to me but the tag > > name is 4.21. > > It's just that we're so late in the 4.20 cycle. If you're OK with > taking it now I'm happy with that. I dropped the ball on this before the holidays, I've queued it up in a next/late branch now so we'll send it in towards the end of the merge window. -Olof
Re: [GIT PULL 1/2] ARM: dts: exynos: Second round for v4.21
On Tue, Dec 18, 2018 at 09:10:02PM +0100, Krzysztof Kozlowski wrote: > Hi, > > On top of previous pull request. > > Best regards, > Krzysztof > > > The following changes since commit 57b13b8b34002ce8f1d822ea05f0a84e5bc3a64a: > > ARM: dts: exynos: remove display-port node from Arndale (2018-12-06 > 19:47:15 +0100) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt-4.21-2 > > for you to fetch changes up to 8ac686d7dfed721102860ff2571e6b9f529ae81a: > > ARM: dts: exynos: Specify I2S assigned clocks in proper node (2018-12-13 > 21:56:07 +0100) > > > Samsung DTS ARM changes for v4.21, part 2 > > 1. Add missing CPUs in cooling maps for Odroid X2 (missed in previous >round of fixups). > 2. Fix clock configuration in audio subsystem on Odroid XU3/XU4. Merged into next/late. Will try to merge this window, best-effort. -Olof
Re: [GIT PULL] STi SoC update for v4.21 round 1
On Thu, Dec 20, 2018 at 01:54:20PM +, Patrice CHOTARD wrote: > Hi Arnd, Olof, Kevin > > Please find STi SoC update for v4.21 round 1: > > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git > tags/sti-soc-for-v4.21-round1 > > for you to fetch changes up to 704cfd7f5f71c6bc6cdfaa63a16ed0f72882b1a1: > > ARM: sti: remove pen_release and boot_lock (2018-12-20 14:32:15 +0100) > > > > Highlights: > --- > - Following pen_release and boot_lock cleanup initiated by > Russell King, .smp_prepare_cpus and .smp_boot_secondary STi callbacks > must be reworked to keep secondary CPU's bringup. Merged into next/late, will submit for upstream towards end of merge window to get a bit of soak time. -Olof
Re: tpm_tis TPM2.0 not detected on cold boot
On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote: > > difference is that on a cold boot, the TPM takes longer to initialize. > > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager > does > not solve the problem. So the problem is NOT that the TPM takes longer to > initialize. Even adding a delay of 20 seconds before TPM init does not solve > that while that should be more than enough time. The purpose of commenting out the TPM2 selftest was to minimize the TPM initialization delay, so that the TPM is ready before IMA. After James' patch that wasn't needed anymore. Looking back at this thread, I see you're using systemd-boot, not grub2. When you commented out the systemd-boot timeout, IMA found the TPM. The question is why isn't the TPM ready with the timeout before IMA (like above)? Has systemd-boot done the selftest? Mimi
Re: [RFC v2 1/6] x86: introduce kernel restartable sequence
> On Dec 31, 2018, at 12:08 PM, Andy Lutomirski wrote:
>
> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>> It is sometimes beneficial to have a restartable sequence - very few
>> instructions which if they are preempted jump to a predefined point.
>>
>> To provide such functionality on x86-64, we use an empty REX-prefix
>> (opcode 0x40) as an indication for instruction in such a sequence. Before
>> calling the schedule IRQ routine, if the "magic" prefix is found, we
>> call a routine to adjust the instruction pointer. It is expected that
>> this opcode is not in common use.
>>
>> The following patch will make use of this function. Since there are no
>> other users (yet?), the patch does not bother to create a general
>> infrastructure and API that others can use for such sequences. Yet, it
>> should not be hard to make such extension later.
>
> The following patch does not use it. Can you update this?
I will. Sorry for not updating the commit-log. The GCC plugin, and various
requests (that I am not sure I fully agree with) really caused me to spit
some blood.
>> +asmlinkage __visible void restart_kernel_rseq(struct pt_regs *regs)
>> +{
>> + if (user_mode(regs) || *(u8 *)regs->ip != KERNEL_RESTARTABLE_PREFIX)
>> + return;
>
> else?
>
> I suspect something is missing here. Or I'm very confused.
Indeed, the code should call optpoline_restart_rseq() (or some other name,
once I fix the naming). I will fix it.
Re: [RFC v2 5/6] x86: learning and patching indirect branch targets
> On Dec 31, 2018, at 12:05 PM, Andy Lutomirski wrote: > > On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote: >> During runtime, we collect the targets of indirect branch targets and >> patch them in. Patching is done asynchronously, by modifying each of the >> relpoline code-paths separately while diverting code execution to the >> other path during patching. Preemption is disabled while the code runs, >> and we wait for preemption to occur on each core to ensure no core is >> executing the patched code. >> >> To make use of relpolines, a worker goes over the experienced indirect >> calls targets and sorts them according to frequency. The target that >> was encountered most times is patched in. >> >> Periodically, the indirect branches are set back into learning mode to >> see whether the targets have changed. The current policy might be too >> aggressive. > > Can you put, in a comment somewhere, a clear description of the actual > optpoline assembly sequence? I'm finding this code very hard to > follow as is. Something like: > > /* > * An optpoline is: > * > * cmp something, something else > * je somewhere > * [repeats of the above] > * RETPOLINE (i.e. call some thunk) > */ > Sure. I will add it. The GCC plugin code [3/6] holds commented assembly code, but I will add it to the commit log as well. > And please make it correct. > > Your comment says that preemption is disabled, but it's not obvious to > me where this happens. > > Also, you define REX_B and don't use it. Are there other cases of that? Yes, I was sloppy. The preemption is not disabled, and instead I used your proposed approach of restartable sequences. REX_B is used as KERNEL_RESTARTABLE_PREFIX in [3/6], [5/6] and [6/6]. I will rename it.
Re: [PATCH RESEND v8 4/4] clk: meson: add sub MMC clock controller driver
Hi Yixun, Thank you for the patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on next-20181224] [cannot apply to v4.20] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jianxin-Pan/clk-meson-add-a-sub-EMMC-clock-controller-support/20181222-060947 base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next config: i386-randconfig-x079-12301332 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "clk_regmap_mux_ops" [drivers/clk/meson/mmc-clkc.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [GIT PULL] sound updates for 4.21
Hi, On 12/31/18 9:10 PM, Pierre-Louis Bossart wrote: On 12/31/18 12:15 PM, Takashi Iwai wrote: On Mon, 31 Dec 2018 11:24:41 +0100, Pierre-Louis Bossart wrote: On 12/31/18 2:11 AM, Takashi Iwai wrote: On Mon, 31 Dec 2018 00:17:58 +0100, Pierre-Louis Bossart wrote: BTW, one thing I'd really like to avoid is to rearrange the probe procedure of the legacy HDA driver (so that we can get codec_mask during pci probe() call). The async probe is the result of the many struggles with the various and complex configurations. Moving the codec probe to the beginning isn't trivial and quite risky to break something else. Agree, mucking with the probe isn't something we should look into, especially with this Skylake driver being eventually deprecated once SOF is at feature parity. This set of autodetection patches for 4.21 was really targeting CFL/WHL+ devices, where the DSP usage is mandatory when directly-attached digital microphones are used. For Skylake and kabylake using the legacy by default is just fine. OK, then how about applying the PCI class check only for such ones like the patch below? The macro isn't sexy and can be replaced with another way, but you have an idea. The two patches which added the PCI class checks were supposed to be a simple bullet-proof way of detecting the DSP presence and solving a problem of coexistence between two drivers. At this point if we start adding quirks and still have unclear issues with HDMI support which isn't different for CFL+, it may be wiser to revert them to let the 4.21 merge window progress? It's frustrating but I'd rather solve this problem the right way than with multiple iterations rushed because of the merge window timing. Fair enough, let's revert them for now. I'm going to submit the revert patch. Thanks Takashi. If everyone who has been impacted by this issue can send me privately the result of the following two commands it'd help us figure out which machines expose the DSP - we may ask for additional information, e.g. NHLT tables. We clearly need to widen the validation scope since there is obviously a disconnect between what 3rd party BIOS expose and the technical consensus within Intel audio teams. Thanks in advance for your time. -Pierre On my Apollo Lake laptop which is also affected by this: lspci -s 0:1f.3 -vn 00:0e.0 0403: 8086:5a98 (rev 0b) (prog-if 80) Subsystem: 10ec:111a Flags: bus master, fast devsel, latency 0, IRQ 128 Memory at 91218000 (64-bit, non-prefetchable) [size=16K] Memory at 9100 (64-bit, non-prefetchable) [size=1M] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel, snd_soc_skl more /sys/bus/pci/devices/\:00\:1f.3/class (should return 0x040100 or 0x040380, if the value is 0x040300 then the DSP is not exposed) 0x040380 Regards, Hans
WARNING: ODEBUG bug in netdev_freemem
Hello,
syzbot found the following crash on:
HEAD commit:fc2fd5f0f1aa Merge branch 'x86-platform-for-linus' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=172a9e5340
kernel config: https://syzkaller.appspot.com/x/.config?x=9a98287508be3ff9
dashboard link: https://syzkaller.appspot.com/bug?extid=979ffc89b87309b1b94b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+979ffc89b87309b1b...@syzkaller.appspotmail.com
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
[ cut here ]
ODEBUG: free active (active state 0) object type: timer_list hint:
delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:4916
WARNING: CPU: 1 PID: 26336 at lib/debugobjects.c:328
debug_print_object+0x16a/0x210 lib/debugobjects.c:325
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 26336 Comm: kworker/u4:3 Not tainted 4.20.0+ #391
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:325
Code: 80 88 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 92 00 00 00 48 8b 14 dd
a0 f1 80 88 4c 89 fe 48 c7 c7 40 e7 80 88 e8 76 ea b8 fd <0f> 0b 83 05 01
3b a7 06 01 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f
RSP: 0018:888026fdee48 EFLAGS: 00010086
RAX: RBX: 0003 RCX:
RDX: RSI: 8165c255 RDI: 0005
RBP: 888026fdee88 R08: 888027f762c0 R09: ed1015ce3ef8
R10: ed1015ce3ef8 R11: 8880ae71f7c7 R12: 0001
R13: 897a5ce0 R14: 816c1a80 R15: 8880ebe0
__debug_check_no_obj_freed lib/debugobjects.c:785 [inline]
debug_check_no_obj_freed+0x3ae/0x58d lib/debugobjects.c:817
kfree+0xbd/0x230 mm/slab.c:3816
kvfree+0x61/0x70 mm/util.c:445
netdev_freemem+0x4c/0x60 net/core/dev.c:8903
netdev_release+0x121/0x180 net/core/net-sysfs.c:1640
device_release+0x7e/0x210 drivers/base/core.c:912
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:70 [inline]
kobject_put.cold.9+0x287/0x2e4 lib/kobject.c:708
netdev_run_todo+0x715/0xa60 net/core/dev.c:8808
rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:117
default_device_exit_batch+0x43f/0x540 net/core/dev.c:9589
ops_exit_list.isra.5+0x105/0x160 net/core/net_namespace.c:156
cleanup_net+0x555/0xb10 net/core/net_namespace.c:551
process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
==
WARNING: possible circular locking dependency detected
4.20.0+ #391 Not tainted
--
kworker/u4:3/26336 is trying to acquire lock:
d2979eea ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:136
but task is already holding lock:
2d00477d (_hash[i].lock){-.-.}, at: __debug_check_no_obj_freed
lib/debugobjects.c:776 [inline]
2d00477d (_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x17a/0x58d lib/debugobjects.c:817
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (_hash[i].lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
__debug_object_init+0x127/0x1290 lib/debugobjects.c:383
debug_object_init+0x16/0x20 lib/debugobjects.c:431
debug_hrtimer_init kernel/time/hrtimer.c:401 [inline]
debug_init kernel/time/hrtimer.c:449 [inline]
hrtimer_init+0x97/0x490 kernel/time/hrtimer.c:1299
init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1057
__sched_fork+0x2ae/0x590 kernel/sched/core.c:2166
init_idle+0x75/0x6d0 kernel/sched/core.c:5374
sched_init+0xb33/0xc07 kernel/sched/core.c:6063
start_kernel+0x448/0x8ae init/main.c:608
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:470
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
secondary_startup_64+0xa4/0xb0
Re: [PATCH] pci: dwc: add a check for resetting gpio
Hi Kangjie,
Thanks for the patch.
On Tue, Dec 25, 2018 at 08:22:36PM -0600, Kangjie Lu wrote:
> devm_gpio_request_one() could fail. The fix checks its status and issues
> an error if it fails.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/pci/controller/dwc/pci-exynos.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-exynos.c
> b/drivers/pci/controller/dwc/pci-exynos.c
> index cee5f2f590e2..e3a045e215d2 100644
> --- a/drivers/pci/controller/dwc/pci-exynos.c
> +++ b/drivers/pci/controller/dwc/pci-exynos.c
> @@ -226,9 +226,12 @@ static void exynos_pcie_assert_reset(struct exynos_pcie
> *ep)
> struct dw_pcie *pci = ep->pci;
> struct device *dev = pci->dev;
>
> - if (ep->reset_gpio >= 0)
> - devm_gpio_request_one(dev, ep->reset_gpio,
> - GPIOF_OUT_INIT_HIGH, "RESET");
> + if (ep->reset_gpio >= 0) {
> + if (devm_gpio_request_one(dev, ep->reset_gpio,
> + GPIOF_OUT_INIT_HIGH, "RESET"))
> + dev_err(dev, "Failed requesting reset gpio %d\n",
> + ep->reset_gpio);
> + }
Even before your patch, this code doesn't make sense to me.
devm_gpio_request_one() is a setup function and should be called in
the probe path. The "assert_reset" path should do something like
gpio_set_value(). See other callers, e.g.,
imx6_pcie_probe()
histb_pcie_probe()
mvebu_pcie_parse_port()
I'm skeptical that exynos_pcie_assert_reset() ever worked as intended,
so let's straighten that out before worrying about checking the return
code from devm_gpio_request_one().
The result should be two patches: (1) fix the devm_gpio_request_one()
usage, and (2) check the devm_gpio_request_one() return value.
> }
Quest is Business
Greetings, My name is Mr Ramy Said Abdelkhalek, an Egyptian Citizen and a Financial BROKER , I wish to know if you are open for private investor's discussion to invest with you or your company, iam ready to invest or loan fund with a stipulated capital tune of $1.8 Billion and above into any company that needs Investments or fund Loaning for EXPANSION only. I will like to invest the funds into existing company or a new company abroad. email me on my private ramysaidabdelkha...@yahoo.com Regards
Re: [PATCH v4 08/11] ASoC: Intel: atom: Make PCI dependency explicit
On Mon, Dec 31, 2018 at 11:29 PM Pierre-Louis Bossart wrote: > > > On 12/31/18 1:35 PM, Sinan Kaya wrote: > > On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote: > >> On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote: > >>> On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote: > I don't have the cover letter or anything for this series, what's going > on with dependencies? > >>> Here is the executive summary: > >>> I have a changeset that separates ACPI from PCI on 4.21. CONFIG_ACPI > >>> used to select PCI. This is no longer true. > >>> You can build an ACPI system without any PCI devices. > >> So there's no dependency and I can just apply this? > > The plan is to apply this patchset via ACPI tree. Need an Acked-by per > > patch. > Anytime we change the Kconfig settings for audio, we get all kinds of > problems with randconfig and 0day/kbuild due to depend/select issues. > I'd like to give this a spin first, can you share a link to the entire > series? Thanks! Sure, You can find them here https://lore.kernel.org/patchwork/patch/1028330/ Click related.
Re: [PATCH v4 08/11] ASoC: Intel: atom: Make PCI dependency explicit
On 12/31/18 1:35 PM, Sinan Kaya wrote: On Mon, Dec 31, 2018 at 10:30 PM Mark Brown wrote: On Mon, Dec 31, 2018 at 08:52:52PM +0300, Sinan Kaya wrote: On Mon, Dec 31, 2018 at 8:47 PM Mark Brown wrote: I don't have the cover letter or anything for this series, what's going on with dependencies? Here is the executive summary: I have a changeset that separates ACPI from PCI on 4.21. CONFIG_ACPI used to select PCI. This is no longer true. You can build an ACPI system without any PCI devices. So there's no dependency and I can just apply this? The plan is to apply this patchset via ACPI tree. Need an Acked-by per patch. Anytime we change the Kconfig settings for audio, we get all kinds of problems with randconfig and 0day/kbuild due to depend/select issues. I'd like to give this a spin first, can you share a link to the entire series? Thanks!
Re: [PATCH RESEND v8 4/4] clk: meson: add sub MMC clock controller driver
Hi Yixun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20181224]
[cannot apply to v4.20]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jianxin-Pan/clk-meson-add-a-sub-EMMC-clock-controller-support/20181222-060947
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-randconfig-s0-12301806 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/clk/meson/mmc-clkc.o: In function `mmc_clkc_register_mux':
>> drivers/clk/meson/mmc-clkc.c:182: undefined reference to `clk_regmap_mux_ops'
vim +182 drivers/clk/meson/mmc-clkc.c
158
159 static struct clk_regmap *mmc_clkc_register_mux(struct device *dev,
160 struct regmap *map)
161 {
162 const char *parent_names[MUX_CLK_NUM_PARENTS];
163 struct clk_init_data init;
164 struct clk_regmap *mux;
165 struct clk *clk;
166 int i;
167
168 for (i = 0; i < MUX_CLK_NUM_PARENTS; i++) {
169 char name[8];
170
171 snprintf(name, sizeof(name), "clkin%d", i);
172 clk = devm_clk_get(dev, name);
173 if (IS_ERR(clk)) {
174 if (clk != ERR_PTR(-EPROBE_DEFER))
175 dev_err(dev, "Missing clock %s\n",
name);
176 return ERR_CAST(clk);
177 }
178
179 parent_names[i] = __clk_get_name(clk);
180 }
181
> 182 init.ops = _regmap_mux_ops;
183 init.flags = CLK_SET_RATE_PARENT;
184 init.parent_names = parent_names;
185 init.num_parents = MUX_CLK_NUM_PARENTS;
186
187 mux = mmc_clkc_register_clk(dev, map, , "mux",
_clkc_mux_data);
188 if (IS_ERR(mux))
189 dev_err(dev, "Mux clock registration failed\n");
190
191 return mux;
192 }
193
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [GIT PULL] sound updates for 4.21
On 12/31/18 12:15 PM, Takashi Iwai wrote: On Mon, 31 Dec 2018 11:24:41 +0100, Pierre-Louis Bossart wrote: On 12/31/18 2:11 AM, Takashi Iwai wrote: On Mon, 31 Dec 2018 00:17:58 +0100, Pierre-Louis Bossart wrote: BTW, one thing I'd really like to avoid is to rearrange the probe procedure of the legacy HDA driver (so that we can get codec_mask during pci probe() call). The async probe is the result of the many struggles with the various and complex configurations. Moving the codec probe to the beginning isn't trivial and quite risky to break something else. Agree, mucking with the probe isn't something we should look into, especially with this Skylake driver being eventually deprecated once SOF is at feature parity. This set of autodetection patches for 4.21 was really targeting CFL/WHL+ devices, where the DSP usage is mandatory when directly-attached digital microphones are used. For Skylake and kabylake using the legacy by default is just fine. OK, then how about applying the PCI class check only for such ones like the patch below? The macro isn't sexy and can be replaced with another way, but you have an idea. The two patches which added the PCI class checks were supposed to be a simple bullet-proof way of detecting the DSP presence and solving a problem of coexistence between two drivers. At this point if we start adding quirks and still have unclear issues with HDMI support which isn't different for CFL+, it may be wiser to revert them to let the 4.21 merge window progress? It's frustrating but I'd rather solve this problem the right way than with multiple iterations rushed because of the merge window timing. Fair enough, let's revert them for now. I'm going to submit the revert patch. Thanks Takashi. If everyone who has been impacted by this issue can send me privately the result of the following two commands it'd help us figure out which machines expose the DSP - we may ask for additional information, e.g. NHLT tables. We clearly need to widen the validation scope since there is obviously a disconnect between what 3rd party BIOS expose and the technical consensus within Intel audio teams. Thanks in advance for your time. -Pierre lspci -s 0:1f.3 -vn more /sys/bus/pci/devices/\:00\:1f.3/class (should return 0x040100 or 0x040380, if the value is 0x040300 then the DSP is not exposed) (replace 1f.3 with 0e.0 for ApolloLake/GeminiLake)
Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc
On Sat, Dec 29, 2018 at 09:40:20PM -1000, Joey Pabalinas wrote:
> On Sun, Dec 30, 2018 at 08:08:46AM +0100, Willy Tarreau wrote:
> > Definitely! Same, I won't emit a patch just for this, Paul already queued
> > it.
>
> Yeah, not that big a deal :)
>
> Reviewed-by: Joey Pabalinas
But as long as I am rebasing to add the Reviewed-by, might as well
update the others.
The English rules for capitalization and lists are baroque and completely
unsuited to word processors ("If any list item is longer than one line,
capitalize all the items."), but in this case each item has multiple
sentences, so it makes sense to capitalize.
Please see below for the updated commit, and thank you all!
And Happy New Year!!! ;-)
Thanx, Paul
commit c12cd600666874ef43f2c555391dce47fe60fcd9
Author: Willy Tarreau
Date: Sat Dec 29 19:02:18 2018 +0100
rcutorture/nolibc: Add a bit of documentation to explain how to use nolibc
Ingo rightfully asked for a bit more documentation in the nolibc header,
so this patch adds some explanation about its purpose, how it's made, and
how to use it.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Randy Dunlap
Signed-off-by: Willy Tarreau
Signed-off-by: Paul E. McKenney
Reviewed-by: Joey Pabalinas
Reviewed-by: Randy Dunlap
diff --git a/tools/testing/selftests/rcutorture/bin/nolibc.h
b/tools/testing/selftests/rcutorture/bin/nolibc.h
index cfbbbad4bca4..1708e9f9f8aa 100644
--- a/tools/testing/selftests/rcutorture/bin/nolibc.h
+++ b/tools/testing/selftests/rcutorture/bin/nolibc.h
@@ -3,7 +3,85 @@
* Copyright (C) 2017-2018 Willy Tarreau
*/
-/* some archs (at least aarch64) don't expose the regular syscalls anymore by
+/*
+ * This file is designed to be used as a libc alternative for minimal programs
+ * with very limited requirements. It consists of a small number of syscall and
+ * type definitions, and the minimal startup code needed to call main().
+ * All syscalls are declared as static functions so that they can be optimized
+ * away by the compiler when not used.
+ *
+ * Syscalls are split into 3 levels:
+ * - The lower level is the arch-specific syscall() definition, consisting in
+ * assembly code in compound expressions. These are called my_syscall0() to
+ * my_syscall6() depending on the number of arguments. The MIPS
+ * implementation is limited to 5 arguments. All input arguments are cast
+ * to a long stored in a register. These expressions always return the
+ * syscall's return value as a signed long value which is often either a
+ * pointer or the negated errno value.
+ *
+ * - The second level is mostly architecture-independent. It is made of
+ * static functions called sys_() which rely on my_syscallN()
+ * depending on the syscall definition. These functions are responsible
+ * for exposing the appropriate types for the syscall arguments (int,
+ * pointers, etc) and for setting the appropriate return type (often int).
+ * A few of them are architecture-specific because the syscalls are not all
+ * mapped exactly the same among architectures. For example, some archs do
+ * not implement select() and need pselect6() instead, so the sys_select()
+ * function will have to abstract this.
+ *
+ * - The third level is the libc call definition. It exposes the lower raw
+ * sys_() calls in a way that looks like what a libc usually does,
+ * takes care of specific input values, and of setting errno upon error.
+ * There can be minor variations compared to standard libc calls. For
+ * example the open() call always takes 3 args here.
+ *
+ * The errno variable is declared static and unused. This way it can be
+ * optimized away if not used. However this means that a program made of
+ * multiple C files may observe different errno values (one per C file). For
+ * the type of programs this project targets it usually is not a problem. The
+ * resulting program may even be reduced by defining the NOLIBC_IGNORE_ERRNO
+ * macro, in which case the errno value will never be assigned.
+ *
+ * Some stdint-like integer types are defined. These are valid on all currently
+ * supported architectures, because signs are enforced, ints are assumed to be
+ * 32 bits, longs the size of a pointer and long long 64 bits. If more
+ * architectures have to be supported, this may need to be adapted.
+ *
+ * Some macro definitions like the O_* values passed to open(), and some
+ * structures like the sys_stat struct depend on the architecture.
+ *
+ * The definitions start with the architecture-specific parts, which are picked
+ * based on what the compiler knows about the target architecture, and are
+ * completed with the generic code. Since it is the compiler which sets the
+ * target architecture, cross-compiling normally works out of the box
Re: [RFC v2 1/6] x86: introduce kernel restartable sequence
On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>
> It is sometimes beneficial to have a restartable sequence - very few
> instructions which if they are preempted jump to a predefined point.
>
> To provide such functionality on x86-64, we use an empty REX-prefix
> (opcode 0x40) as an indication for instruction in such a sequence. Before
> calling the schedule IRQ routine, if the "magic" prefix is found, we
> call a routine to adjust the instruction pointer. It is expected that
> this opcode is not in common use.
>
> The following patch will make use of this function. Since there are no
> other users (yet?), the patch does not bother to create a general
> infrastructure and API that others can use for such sequences. Yet, it
> should not be hard to make such extension later.
The following patch does not use it. Can you update this?
> +asmlinkage __visible void restart_kernel_rseq(struct pt_regs *regs)
> +{
> + if (user_mode(regs) || *(u8 *)regs->ip != KERNEL_RESTARTABLE_PREFIX)
> + return;
else?
I suspect something is missing here. Or I'm very confused.
> +}
Re: [RFC v2 5/6] x86: learning and patching indirect branch targets
On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote: > > During runtime, we collect the targets of indirect branch targets and > patch them in. Patching is done asynchronously, by modifying each of the > relpoline code-paths separately while diverting code execution to the > other path during patching. Preemption is disabled while the code runs, > and we wait for preemption to occur on each core to ensure no core is > executing the patched code. > > To make use of relpolines, a worker goes over the experienced indirect > calls targets and sorts them according to frequency. The target that > was encountered most times is patched in. > > Periodically, the indirect branches are set back into learning mode to > see whether the targets have changed. The current policy might be too > aggressive. > Can you put, in a comment somewhere, a clear description of the actual optpoline assembly sequence? I'm finding this code very hard to follow as is. Something like: /* * An optpoline is: * * cmp something, something else * je somewhere * [repeats of the above] * RETPOLINE (i.e. call some thunk) */ And please make it correct. Your comment says that preemption is disabled, but it's not obvious to me where this happens. Also, you define REX_B and don't use it. Are there other cases of that?
