[PATCH kernel] powerpc/iommu: Add simple iommu_ops to report capabilities
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in the Type1 VFIO driver. Recent development though has added a coherency capability check to the generic part of VFIO and essentially disabled VFIO on PPC64. This adds a simple iommu_ops stub which reports support for cache coherency. Because bus_set_iommu() triggers IOMMU probing of PCI devices, this provides minimum code for the probing to not crash. The previous discussion is here: https://patchwork.ozlabs.org/project/kvm-ppc/patch/20220701061751.1955857-1-...@ozlabs.ru/ Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices") Signed-off-by: Alexey Kardashevskiy --- I have not looked into the domains for ages, what is missing here? With this on top of 5.19-rc1 VFIO works again on my POWER9 box. Thanks, --- arch/powerpc/include/asm/iommu.h | 2 + arch/powerpc/kernel/iommu.c | 70 arch/powerpc/kernel/pci_64.c | 3 ++ 3 files changed, 75 insertions(+) diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h index 7e29c73e3dd4..4bdae0ee29d0 100644 --- a/arch/powerpc/include/asm/iommu.h +++ b/arch/powerpc/include/asm/iommu.h @@ -215,6 +215,8 @@ extern long iommu_tce_xchg_no_kill(struct mm_struct *mm, enum dma_data_direction *direction); extern void iommu_tce_kill(struct iommu_table *tbl, unsigned long entry, unsigned long pages); + +extern const struct iommu_ops spapr_tce_iommu_ops; #else static inline void iommu_register_group(struct iommu_table_group *table_group, int pci_domain_number, diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index 7e56ddb3e0b9..2205b448f7d5 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -1176,4 +1176,74 @@ void iommu_del_device(struct device *dev) iommu_group_remove_device(dev); } EXPORT_SYMBOL_GPL(iommu_del_device); + +/* + * A simple iommu_ops to allow less cruft in generic VFIO code. + */ +static bool spapr_tce_iommu_capable(enum iommu_cap cap) +{ + switch (cap) { + case IOMMU_CAP_CACHE_COHERENCY: + return true; + default: + break; + } + + return false; +} + +static struct iommu_domain *spapr_tce_iommu_domain_alloc(unsigned int type) +{ + struct iommu_domain *domain = kzalloc(sizeof(*domain), GFP_KERNEL); + + if (!domain) + return NULL; + + domain->geometry.aperture_start = 0; + domain->geometry.aperture_end = ~0ULL; + domain->geometry.force_aperture = true; + + return domain; +} + +static struct iommu_device *spapr_tce_iommu_probe_device(struct device *dev) +{ + struct iommu_device *iommu_dev = kzalloc(sizeof(struct iommu_device), GFP_KERNEL); + + iommu_dev->dev = dev; + iommu_dev->ops = &spapr_tce_iommu_ops; + + return iommu_dev; +} + +static void spapr_tce_iommu_release_device(struct device *dev) +{ +} + +static int spapr_tce_iommu_attach_dev(struct iommu_domain *dom, + struct device *dev) +{ + return 0; +} + +static struct iommu_group *spapr_tce_iommu_device_group(struct device *dev) +{ + struct iommu_group *grp = dev->iommu_group; + + if (!grp) + grp = ERR_PTR(-ENODEV); + return grp; +} + +const struct iommu_ops spapr_tce_iommu_ops = { + .capable = spapr_tce_iommu_capable, + .domain_alloc = spapr_tce_iommu_domain_alloc, + .probe_device = spapr_tce_iommu_probe_device, + .release_device = spapr_tce_iommu_release_device, + .device_group = spapr_tce_iommu_device_group, + .default_domain_ops = &(const struct iommu_domain_ops) { + .attach_dev = spapr_tce_iommu_attach_dev, + } +}; + #endif /* CONFIG_IOMMU_API */ diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c index 19b03ddf5631..04bc0c52e45c 100644 --- a/arch/powerpc/kernel/pci_64.c +++ b/arch/powerpc/kernel/pci_64.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -27,6 +28,7 @@ #include #include #include +#include /* pci_io_base -- the base address from which io bars are offsets. * This is the lowest I/O base address (so bar values are always positive), @@ -69,6 +71,7 @@ static int __init pcibios_init(void) ppc_md.pcibios_fixup(); printk(KERN_DEBUG "PCI: Probing PCI hardware done\n"); + bus_set_iommu(&pci_bus_type, &spapr_tce_iommu_ops); return 0; } -- 2.30.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2] iommu/arm-smmu-qcom: Add debug support for TLB sync timeouts
On 6/23/2022 11:32 AM, Sai Prakash Ranjan wrote: On 5/26/2022 9:44 AM, Sai Prakash Ranjan wrote: TLB sync timeouts can be due to various reasons such as TBU power down or pending TCU/TBU invalidation/sync and so on. Debugging these often require dumping of some implementation defined registers to know the status of TBU/TCU operations and some of these registers are not accessible in non-secure world such as from kernel and requires SMC calls to read them in the secure world. So, add this debug support to dump implementation defined registers for TLB sync timeout issues. Signed-off-by: Sai Prakash Ranjan --- Changes in v2: * Use scm call consistently so that it works on older chipsets where some of these regs are secure registers. * Add device specific data to get the implementation defined register offsets. --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 161 ++--- drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 + drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 + 3 files changed, 146 insertions(+), 18 deletions(-) Any comments on this patch? Gentle Ping !! Thanks, Sai ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 03/14] iommu: Move bus setup to IOMMU device registration
Hi Robin, On 2022/4/30 02:06, Robin Murphy wrote: On 29/04/2022 9:50 am, Robin Murphy wrote: On 2022-04-29 07:57, Baolu Lu wrote: Hi Robin, On 2022/4/28 21:18, Robin Murphy wrote: Move the bus setup to iommu_device_register(). This should allow bus_iommu_probe() to be correctly replayed for multiple IOMMU instances, and leaves bus_set_iommu() as a glorified no-op to be cleaned up next. I re-fetched the latest patches on https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/bus and rolled back the head to "iommu: Cleanup bus_set_iommu". The test machine still hangs during boot. I went through the code. It seems that the .probe_device for Intel IOMMU driver can't handle the probe replay well. It always assumes that the device has never been probed. Hmm, but probe_iommu_group() is supposed to prevent the __iommu_probe_device() call even happening if the device *has* already been probed before :/ I've still got an old Intel box spare in the office so I'll rig that up and see if I can see what might be going on here... OK, on a Xeon with two DMAR units, this seems to boot OK with or without patch #1, so it doesn't seem to be a general problem with replaying in iommu_device_register(), or with platform devices. Not sure where to go from here... :/ The kernel boot panic message: [6.639432] BUG: kernel NULL pointer dereference, address: 0028 [6.743829] #PF: supervisor read access in kernel mode [6.743829] #PF: error_code(0x) - not-present page [6.743829] PGD 0 [6.743829] Oops: [#1] PREEMPT SMP NOPTI [6.743829] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G I 5.19.0-rc3+ #182 [6.743829] RIP: 0010:__iommu_probe_device+0x115/0x200 [6.743829] Code: 89 ff e8 3e e1 ff ff 48 85 c0 0f 85 47 ff ff ff 41 bd f4 ff ff ff eb 83 48 8b 83 d8 02 00 00 48 89 df 48 8b 40 38 48 8b 40 10 <48> 8b 40 28 ff d0 0f 1f 00 48 89 c1 48 85 c0 0f 84 b7 00 00 00 48 [6.743829] RSP: :ff30605c00063d40 EFLAGS: 00010246 [6.743829] RAX: RBX: ff128b9c5fdc90d0 RCX: [6.743829] RDX: 8001 RSI: 0246 RDI: ff128b9c5fdc90d0 [6.743829] RBP: b60c34e0 R08: b68664d0 R09: ff128b9501d4ce40 [6.743829] R10: b6267096 R11: ff128b950014c267 R12: ff30605c00063de0 [6.743829] R13: 001b9d28 R14: ff128b95001b9d28 R15: ff128b9c5fdc93a8 [6.743829] FS: () GS:ff128b9c5fc0() knlGS: [6.743829] CS: 0010 DS: ES: CR0: 80050033 [6.743829] CR2: 0028 CR3: 000149210001 CR4: 00771ef0 [6.743829] DR0: DR1: DR2: [6.743829] DR3: DR6: 07f0 DR7: 0400 [6.743829] PKRU: 5554 [6.743829] Call Trace: [6.743829] [6.743829] ? _raw_spin_lock_irqsave+0x17/0x40 [6.743829] ? __iommu_probe_device+0x200/0x200 [6.743829] probe_iommu_group+0x2d/0x40 [6.743829] bus_for_each_dev+0x74/0xc0 [6.743829] bus_iommu_probe+0x48/0x2d0 [6.743829] iommu_device_register+0xde/0x120 [6.743829] intel_iommu_init+0x35f/0x5f2 [6.743829] ? iommu_setup+0x27d/0x27d [6.743829] ? rdinit_setup+0x2c/0x2c [6.743829] pci_iommu_init+0xe/0x32 [6.743829] do_one_initcall+0x41/0x200 [6.743829] kernel_init_freeable+0x1de/0x228 [6.743829] ? rest_init+0xc0/0xc0 [6.743829] kernel_init+0x16/0x120 [6.743829] ret_from_fork+0x1f/0x30 [6.743829] [6.743829] Modules linked in: [6.743829] CR2: 0028 [6.743829] ---[ end trace ]--- [6.743829] RIP: 0010:__iommu_probe_device+0x115/0x200 [6.743829] Code: 89 ff e8 3e e1 ff ff 48 85 c0 0f 85 47 ff ff ff 41 bd f4 ff ff ff eb 83 48 8b 83 d8 02 00 00 48 89 df 48 8b 40 38 48 8b 40 10 <48> 8b 40 28 ff d0 0f 1f 00 48 89 c1 48 85 c0 0f 84 b7 00 00 00 48 [6.743829] RSP: :ff30605c00063d40 EFLAGS: 00010246 [6.743829] RAX: RBX: ff128b9c5fdc90d0 RCX: [6.743829] RDX: 8001 RSI: 0246 RDI: ff128b9c5fdc90d0 [6.743829] RBP: b60c34e0 R08: b68664d0 R09: ff128b9501d4ce40 [6.743829] R10: b6267096 R11: ff128b950014c267 R12: ff30605c00063de0 [6.743829] R13: 001b9d28 R14: ff128b95001b9d28 R15: ff128b9c5fdc93a8 [6.743829] FS: () GS:ff128b9c5fc0() knlGS: [6.743829] CS: 0010 DS: ES: CR0: 80050033 [6.743829] CR2: 0028 CR3: 000149210001 CR4: 00771ef0 [6.743829] DR0: DR1: DR2: [6.743829] DR3: DR6: 07f0 DR7: 0400 [6.743829] PKRU: 5554 [6.743829] Kernel panic - not syncing: Fatal exception [6.743829] ---[ end Kernel panic - not syncing: Fat
Re: [PATCH v6 04/10] gpu: host1x: Add context device management code
Hi Mikko, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on tegra/for-next linus/master v5.19-rc5] [cannot apply to tegra-drm/drm/tegra/for-next next-20220704] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/Mikko-Perttunen/Host1x-context-isolation-support/20220621-231339 base: git://anongit.freedesktop.org/drm/drm drm-next config: arm-randconfig-r005-20220703 (https://download.01.org/0day-ci/archive/20220705/202207051045.jwevr4tw-...@intel.com/config) compiler: arm-linux-gnueabi-gcc (GCC) 11.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/2501beeae7469b805f9f624049fd56643cf6e18e git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Mikko-Perttunen/Host1x-context-isolation-support/20220621-231339 git checkout 2501beeae7469b805f9f624049fd56643cf6e18e # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/gpu/host1x/context.c: In function 'host1x_memory_context_list_init': >> drivers/gpu/host1x/context.c:80:40: error: 'struct iommu_fwspec' has no >> member named 'ids' 80 | ctx->stream_id = fwspec->ids[0] & 0x; |^~ vim +80 drivers/gpu/host1x/context.c 15 16 int host1x_memory_context_list_init(struct host1x *host1x) 17 { 18 struct host1x_memory_context_list *cdl = &host1x->context_list; 19 struct device_node *node = host1x->dev->of_node; 20 struct host1x_memory_context *ctx; 21 unsigned int i; 22 int err; 23 24 cdl->devs = NULL; 25 cdl->len = 0; 26 mutex_init(&cdl->lock); 27 28 err = of_property_count_u32_elems(node, "iommu-map"); 29 if (err < 0) 30 return 0; 31 32 cdl->devs = kcalloc(err, sizeof(*cdl->devs), GFP_KERNEL); 33 if (!cdl->devs) 34 return -ENOMEM; 35 cdl->len = err / 4; 36 37 for (i = 0; i < cdl->len; i++) { 38 struct iommu_fwspec *fwspec; 39 40 ctx = &cdl->devs[i]; 41 42 ctx->host = host1x; 43 44 device_initialize(&ctx->dev); 45 46 /* 47 * Due to an issue with T194 NVENC, only 38 bits can be used. 48 * Anyway, 256GiB of IOVA ought to be enough for anyone. 49 */ 50 ctx->dma_mask = DMA_BIT_MASK(38); 51 ctx->dev.dma_mask = &ctx->dma_mask; 52 ctx->dev.coherent_dma_mask = ctx->dma_mask; 53 dev_set_name(&ctx->dev, "host1x-ctx.%d", i); 54 ctx->dev.bus = &host1x_context_device_bus_type; 55 ctx->dev.parent = host1x->dev; 56 57 dma_set_max_seg_size(&ctx->dev, UINT_MAX); 58 59 err = device_add(&ctx->dev); 60 if (err) { 61 dev_err(host1x->dev, "could not add context device %d: %d\n", i, err); 62 goto del_devices; 63 } 64 65 err = of_dma_configure_id(&ctx->dev, node, true, &i); 66 if (err) { 67 dev_err(host1x->dev, "IOMMU configuration failed for context device %d: %d\n", 68 i, err); 69 device_del(&ctx->dev); 70 goto del_devices; 71 } 72 73 fwspec = dev_iommu_fwspec_get(&ctx->dev); 74 if (!fwspec) { 75 dev_err(host1x->dev, "Context device %d has no IOMMU!\n", i); 76 device_del(&ctx->dev); 77 goto de
Re: [PATCH v12 2/2] iommu/mediatek: Allow page table PA up to 35bit
On Thu, 2022-06-30 at 17:29 +0800, yf.w...@mediatek.com wrote: > From: Yunfei Wang > > Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So > add > the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level > 2 > pgtable support at most 35bit PA. > > Signed-off-by: Ning Li > Signed-off-by: Yunfei Wang Reviewed-by: Yong Wu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: (EXT) Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
On Mon, Jul 4, 2022 at 12:07 AM Alexander Stein wrote: > > Am Freitag, 1. Juli 2022, 09:02:22 CEST schrieb Saravana Kannan: > > On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein > > > > wrote: > > > Hi Saravana, > > > > > > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan: > > > > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein > > > > > > > > wrote: > > > > > Hi, > > > > > > > > > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren: > > > > > > Hi, > > > > > > > > > > > > * Saravana Kannan [700101 02:00]: > > > > > > > Now that fw_devlink=on by default and fw_devlink supports > > > > > > > "power-domains" property, the execution will never get to the > > > > > > > point > > > > > > > where driver_deferred_probe_check_state() is called before the > > > > > > > supplier > > > > > > > has probed successfully or before deferred probe timeout has > > > > > > > expired. > > > > > > > > > > > > > > So, delete the call and replace it with -ENODEV. > > > > > > > > > > > > Looks like this causes omaps to not boot in Linux next. With this > > > > > > simple-pm-bus fails to probe initially as the power-domain is not > > > > > > yet available. On platform_probe() genpd_get_from_provider() returns > > > > > > -ENOENT. > > > > > > > > > > > > Seems like other stuff is potentially broken too, any ideas on > > > > > > how to fix this? > > > > > > > > > > I think I'm hit by this as well, although I do not get a lockup. > > > > > In my case I'm using > > > > > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and probing of > > > > > 3832.blk-ctrl fails as the power-domain is not (yet) registed. > > > > > > > > Ok, took a look. > > > > > > > > The problem is that there are two drivers for the same device and they > > > > both initialize this device. > > > > > > > > gpc: gpc@303a { > > > > > > > > compatible = "fsl,imx8mq-gpc"; > > > > > > > > } > > > > > > > > $ git grep -l "fsl,imx7d-gpc" -- drivers/ > > > > drivers/irqchip/irq-imx-gpcv2.c > > > > drivers/soc/imx/gpcv2.c > > > > > > > > IMHO, this is a bad/broken design. > > > > > > > > So what's happening is that fw_devlink will block the probe of > > > > 3832.blk-ctrl until 303a.gpc is initialized. And it stops > > > > blocking the probe of 3832.blk-ctrl as soon as the first driver > > > > initializes the device. In this case, it's the irqchip driver. > > > > > > > > I'd recommend combining these drivers into one. Something like the > > > > patch I'm attaching (sorry for the attachment, copy-paste is mangling > > > > the tabs). Can you give it a shot please? > > > > > > I tried this patch and it delayed the driver initialization (those of UART > > > as > > > well BTW). Unfortunately the driver fails the same way: > > Thanks for testing the patch! > > > > > > [1.125253] imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV: failed > > > > to > > > > > > attach power domain "bus" > > > > > > More than that it even introduced some more errors: > > > > [0.008160] irq: no irq domain found for gpc@303a ! > > > > So the idea behind my change was that as long as the irqchip isn't the > > root of the irqdomain (might be using the terms incorrectly) like the > > gic, you can make it a platform driver. And I was trying to hack up a > > patch that's the equivalent of platform_irqchip_probe() (which just > > ends up eventually calling the callback you use in IRQCHIP_DECLARE(). > > I probably made some mistake in the quick hack that I'm sure if > > fixable. > > > > > > [0.013251] Failed to map interrupt for > > > > /soc@0/bus@3040/timer@306a > > > > However, this timer driver also uses TIMER_OF_DECLARE() which can't > > handle failure to get the IRQ (because it's can't -EPROBE_DEFER). So, > > this means, the timer driver inturn needs to be converted to a > > platform driver if it's supposed to work with the IRQCHIP_DECLARE() > > being converted to a platform driver. > > > > But that's a can of worms not worth opening. But then I remembered > > this simpler workaround will work and it is pretty much a variant of > > the workaround that's already in the gpc's irqchip driver to allow two > > drivers to probe the same device (people really should stop doing > > that). > > > > Can you drop my previous hack patch and try this instead please? I'm > > 99% sure this will work. > > > > diff --git a/drivers/irqchip/irq-imx-gpcv2.c > > b/drivers/irqchip/irq-imx-gpcv2.c index b9c22f764b4d..8a0e82067924 100644 > > --- a/drivers/irqchip/irq-imx-gpcv2.c > > +++ b/drivers/irqchip/irq-imx-gpcv2.c > > @@ -283,6 +283,7 @@ static int __init imx_gpcv2_irqchip_init(struct > > device_node *node, > > * later the GPC power domain driver will not be skipped. > > */ > > of_node_clear_flag(node, OF_POPULATED); > > + fwnode_dev_initialized(domain->fwnode, false); > > return 0; > > } > > Just to be sure here, I tried this patch on top of next-20220701 but > unfortunately this doesn't
[linux-next:master] BUILD REGRESSION b6f1f2fa2bddd69ff46a190b8120bd440fd50563
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: b6f1f2fa2bddd69ff46a190b8120bd440fd50563 Add linux-next specific files for 20220704 Error/Warning: (recently discovered and may have been fixed) drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous prototype for 'pci_read' [-Wmissing-prototypes] drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous prototype for 'pci_write' [-Wmissing-prototypes] Unverified Error/Warning (likely false positive, please contact us if interested): block/partitions/efi.c:223:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 block/sed-opal.c:427:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 crypto/asymmetric_keys/pkcs7_verify.c:311:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/ata/libata-core.c:2802:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/ata/libata-eh.c:2842:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/ata/sata_dwc_460ex.c:691:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/base/power/runtime.c:1573:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/block/rbd.c:6142:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/bluetooth/hci_ll.c:588:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/bluetooth/hci_qca.c:2137:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/cdrom/cdrom.c:1041:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/char/ipmi/ipmi_ssif.c:1918:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/char/pcmcia/cm4000_cs.c:922:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/char/tpm/tpm_tis_core.c:1122:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/clk/bcm/clk-iproc-armpll.c:139:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/clk/bcm/clk-iproc-armpll.c:228:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/clk/clk-bd718x7.c:50:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/clk/clk-lochnagar.c:187:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/crypto/ccree/cc_request_mgr.c:206:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/crypto/qce/sha.c:73:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/crypto/qce/skcipher.c:61:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/cxl/core/hdm.c:38:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/cxl/core/pci.c:67:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/dma-buf/dma-buf.c:1100:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/bus.c:166:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/sensors.c:673:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/voltage.c:363:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/fpga/dfl-fme-mgr.c:163:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gnss/usb.c:68:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:175:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1006:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_resource.c:1035:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:955:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:3895:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu8_hwmgr.c:754:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:195:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0.c:362:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:695:1: internal compiler erro
Re: [PATCH -next] dma-mapping: Fix build error unused-value
On Thu, Jun 30, 2022 at 04:31:16PM +0200, Christoph Hellwig wrote: > Thanks, this looks good with a minor nit below: > > Reviewed-by: Christoph Hellwig > > Mathieu, can you pick this up through your tree as that is where the > offending commit was merged through? > > > Fixes: e61c451476e6("dma-mapping: Add dma_release_coherent_memory to DMA > > API") > I fixed the missing space and applied this patch. Thanks, Mathieu > missing space before the opening brace here. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 01/21] lib/scatterlist: add flag for indicating P2PDMA segments in an SGL
On 2022-06-15 17:12, Logan Gunthorpe wrote: Make use of the third free LSB in scatterlist's page_link on 64bit systems. The extra bit will be used by dma_[un]map_sg_p2pdma() to determine when a given SGL segments dma_address points to a PCI bus address. dma_unmap_sg_p2pdma() will need to perform different cleanup when a segment is marked as a bus address. The new bit will only be used when CONFIG_PCI_P2PDMA is set; this means PCI P2PDMA will require CONFIG_64BIT. This should be acceptable as the majority of P2PDMA use cases are restricted to newer root complexes and roughly require the extra address space for memory BARs used in the transactions. Another thought that's hit me slightly late; depending on CONFIG_64BIT also means that we've got a whole 4 bytes of padding in struct scatterlist to play with, so at that point maybe it's worth considering carrying new extra DMA mapping properties in their own field(s). For instance it would also be really helpful to flag whether a segment is bounce-buffered or not. Robin. Signed-off-by: Logan Gunthorpe Reviewed-by: Chaitanya Kulkarni --- drivers/pci/Kconfig | 5 + include/linux/scatterlist.h | 44 - 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 133c73207782..5cc7cba1941f 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -164,6 +164,11 @@ config PCI_PASID config PCI_P2PDMA bool "PCI peer-to-peer transfer support" depends on ZONE_DEVICE + # + # The need for the scatterlist DMA bus address flag means PCI P2PDMA + # requires 64bit + # + depends on 64BIT select GENERIC_ALLOCATOR help Enableѕ drivers to do PCI peer-to-peer transactions to and from diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index 7ff9d6386c12..6561ca8aead8 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h @@ -64,12 +64,24 @@ struct sg_append_table { #define SG_CHAIN 0x01UL #define SG_END0x02UL +/* + * bit 2 is the third free bit in the page_link on 64bit systems which + * is used by dma_unmap_sg() to determine if the dma_address is a + * bus address when doing P2PDMA. + */ +#ifdef CONFIG_PCI_P2PDMA +#define SG_DMA_BUS_ADDRESS 0x04UL +static_assert(__alignof__(struct page) >= 8); +#else +#define SG_DMA_BUS_ADDRESS 0x00UL +#endif + /* * We overload the LSB of the page pointer to indicate whether it's * a valid sg entry, or whether it points to the start of a new scatterlist. * Those low bits are there for everyone! (thanks mason :-) */ -#define SG_PAGE_LINK_MASK (SG_CHAIN | SG_END) +#define SG_PAGE_LINK_MASK (SG_CHAIN | SG_END | SG_DMA_BUS_ADDRESS) static inline unsigned int __sg_flags(struct scatterlist *sg) { @@ -91,6 +103,11 @@ static inline bool sg_is_last(struct scatterlist *sg) return __sg_flags(sg) & SG_END; } +static inline bool sg_is_dma_bus_address(struct scatterlist *sg) +{ + return __sg_flags(sg) & SG_DMA_BUS_ADDRESS; +} + /** * sg_assign_page - Assign a given page to an SG entry * @sg: SG entry @@ -245,6 +262,31 @@ static inline void sg_unmark_end(struct scatterlist *sg) sg->page_link &= ~SG_END; } +/** + * sg_dma_mark_bus address - Mark the scatterlist entry as a bus address + * @sg: SG entryScatterlist + * + * Description: + * Marks the passed in sg entry to indicate that the dma_address is + * a bus address and doesn't need to be unmapped. + **/ +static inline void sg_dma_mark_bus_address(struct scatterlist *sg) +{ + sg->page_link |= SG_DMA_BUS_ADDRESS; +} + +/** + * sg_unmark_pci_p2pdma - Unmark the scatterlist entry as a bus address + * @sg: SG entryScatterlist + * + * Description: + * Clears the bus address mark. + **/ +static inline void sg_dma_unmark_bus_address(struct scatterlist *sg) +{ + sg->page_link &= ~SG_DMA_BUS_ADDRESS; +} + /** * sg_phys - Return physical address of an sg entry * @sg:SG entry ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 4/4] vfio: Require that devices support DMA cache coherence
Hi, We encounter a issue with the patch: our platform is ARM64, and we run DPDK with smmu disable on VM (without iommu=smmuv3 etc), so we use noiommu mode with enable_unsafe_noiommu_mode=1 to passthrough the device to VM with following steps (those steps are on VM) : insmod vfio.ko enable_unsafe_noiommu_mode=1 insmod vfio_virqfd.ko insmod vfio-pci-core.ko insmdo vfio-pci.ko insmod vfio_iommu_type1.ko echo vfio-pci > /sys/bus/pci/devices/:00:02.0/driver_override echo :00:02.0 > /sys/bus/pci/drivers_probe -- failed I find that vfio-pci device is not probed because of the additional check. It works well without this patch. Do we need to skip the check if enable_unsafe_noiommu_mode=1? Best regards, Xiang Chen 在 2022/4/11 23:16, Jason Gunthorpe 写道: IOMMU_CACHE means that normal DMAs do not require any additional coherency mechanism and is the basic uAPI that VFIO exposes to userspace. For instance VFIO applications like DPDK will not work if additional coherency operations are required. Therefore check IOMMU_CAP_CACHE_COHERENCY like vdpa & usnic do before allowing an IOMMU backed VFIO device to be created. Reviewed-by: Kevin Tian Acked-by: Alex Williamson Acked-by: Robin Murphy Signed-off-by: Jason Gunthorpe --- drivers/vfio/vfio.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c index a4555014bd1e72..9edad767cfdad3 100644 --- a/drivers/vfio/vfio.c +++ b/drivers/vfio/vfio.c @@ -815,6 +815,13 @@ static int __vfio_register_dev(struct vfio_device *device, int vfio_register_group_dev(struct vfio_device *device) { + /* +* VFIO always sets IOMMU_CACHE because we offer no way for userspace to +* restore cache coherency. +*/ + if (!iommu_capable(device->dev->bus, IOMMU_CAP_CACHE_COHERENCY)) + return -EINVAL; + return __vfio_register_dev(device, vfio_group_find_or_alloc(device->dev)); } ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 4/4] vfio: Require that devices support DMA cache coherence
On Mon, Jul 04, 2022 at 09:21:26PM +0800, chenxiang (M) wrote: > Hi, > > We encounter a issue with the patch: our platform is ARM64, and we run DPDK > with smmu disable on VM (without iommu=smmuv3 etc), > > so we use noiommu mode with enable_unsafe_noiommu_mode=1 to passthrough the > device to VM with following steps (those steps are on VM) : > > insmod vfio.ko enable_unsafe_noiommu_mode=1 > insmod vfio_virqfd.ko > insmod vfio-pci-core.ko > insmdo vfio-pci.ko > insmod vfio_iommu_type1.ko > > echo vfio-pci > /sys/bus/pci/devices/:00:02.0/driver_override > echo :00:02.0 > /sys/bus/pci/drivers_probe -- failed > > I find that vfio-pci device is not probed because of the additional check. > It works well without this patch. > > Do we need to skip the check if enable_unsafe_noiommu_mode=1? Yes, that is definately an unintended mistake. Thanks, Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 16/16] arm64: dts: mt8195: Add display node for vdosys0
On 04/07/2022 12:00, Tinghan Shen wrote: > From: "Jason-JH.Lin" > > Add display node for vdosys0 of mt8195. > > Signed-off-by: Jason-JH.Lin > Signed-off-by: Tinghan Shen > --- > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 109 +++ > 1 file changed, 109 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi > b/arch/arm64/boot/dts/mediatek/mt8195.dtsi > index 724c6ca837b6..faea8ef33e5a 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi > @@ -1961,6 +1961,7 @@ > vdosys0: syscon@1c01a000 { > compatible = "mediatek,mt8195-mmsys", "syscon"; > reg = <0 0x1c01a000 0 0x1000>; > + mboxes = <&gce0 0 CMDQ_THR_PRIO_4>; > #clock-cells = <1>; > }; > > @@ -1976,6 +1977,114 @@ > power-domains = <&spm MT8195_POWER_DOMAIN_VENC_CORE1>; > }; > > + ovl0: ovl@1c00 { > + compatible = "mediatek,mt8195-disp-ovl", > + "mediatek,mt8183-disp-ovl"; > + reg = <0 0x1c00 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; > + iommus = <&iommu_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x 0x1000>; > + }; > + > + rdma0: rdma@1c002000 { > + compatible = "mediatek,mt8195-disp-rdma"; > + reg = <0 0x1c002000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_RDMA0>; > + iommus = <&iommu_vdo M4U_PORT_L0_DISP_RDMA0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x2000 0x1000>; > + }; > + > + color0: color@1c003000 { > + compatible = "mediatek,mt8195-disp-color", > + "mediatek,mt8173-disp-color"; > + reg = <0 0x1c003000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_COLOR0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x3000 0x1000>; > + }; > + > + ccorr0: ccorr@1c004000 { > + compatible = "mediatek,mt8195-disp-ccorr", > + "mediatek,mt8192-disp-ccorr"; > + reg = <0 0x1c004000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_CCORR0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x4000 0x1000>; > + }; > + > + aal0: aal@1c005000 { > + compatible = "mediatek,mt8195-disp-aal", > + "mediatek,mt8183-disp-aal"; > + reg = <0 0x1c005000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_AAL0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x5000 0x1000>; > + }; > + > + gamma0: gamma@1c006000 { > + compatible = "mediatek,mt8195-disp-gamma", > + "mediatek,mt8183-disp-gamma"; > + reg = <0 0x1c006000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_GAMMA0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x6000 0x1000>; > + }; > + > + dither0: dither@1c007000 { > + compatible = "mediatek,mt8195-disp-dither", > + "mediatek,mt8183-disp-dither"; > + reg = <0 0x1c007000 0 0x1000>; > + interrupts = ; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; > + clocks = <&vdosys0 CLK_VDO0_DISP_DITHER0>; > + mediatek,gce-client-reg = > + <&gce0 SUBSYS_1c00 0x7000 0x1000>; > + }; > + > + dsc0: dsc@1c009000 { > + c
Re: [PATCH v1 08/16] arm64: dts: mt8195: Add power domains controller
On 04/07/2022 12:00, Tinghan Shen wrote: > Add power domains controller node for mt8195. > > Signed-off-by: Weiyi Lu > Signed-off-by: Tinghan Shen > --- > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 327 +++ > 1 file changed, 327 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi > b/arch/arm64/boot/dts/mediatek/mt8195.dtsi > index 8d59a7da3271..d52e140d9271 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > / { > compatible = "mediatek,mt8195"; > @@ -338,6 +339,332 @@ > #interrupt-cells = <2>; > }; > > + scpsys: syscon@10006000 { > + compatible = "syscon", "simple-mfd"; These compatibles cannot be alone. > + reg = <0 0x10006000 0 0x1000>; > + #power-domain-cells = <1>; If it is simple MFD, then probably it is not a power domain provider. Decide. Best regards, Krzysztof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
On 04/07/2022 12:00, Tinghan Shen wrote: > The max clock items for the dts node with compatible > 'mediatek,mt8195-smi-sub-common' should be 3. > > However, the dtbs_check of such node will get following message, > arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: > ['apb', 'smi', 'gals0'] is too long > From schema: > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > > Remove the last 'else' checking to fix this error. Missing fixes tag. > > Signed-off-by: Tinghan Shen > --- > .../memory-controllers/mediatek,smi-common.yaml| 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > > b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > index a98b359bf909..e5f553e2e12a 100644 > --- > a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > +++ > b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > @@ -143,7 +143,15 @@ allOf: > - const: gals0 > - const: gals1 > > -else: # for gen2 HW that don't have gals > + - if: # for gen2 HW that don't have gals > + properties: > +compatible: > + enum: > +- mediatek,mt2712-smi-common > +- mediatek,mt8167-smi-common > +- mediatek,mt8173-smi-common > + Without looking at the code, it's impossible to understand what you are doing here. The commit msg says one, but you are doing something else. Write commit msg explaining what you want to achieve and what you are doing. Best regards, Krzysztof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 3/3] iommu/vt-d: Show region type in arch_rmrr_sanity_check()
On Mon 2022-07-04 11:39 +0100, Robin Murphy wrote: > On 2022-06-11 21:48, Aaron Tomlin wrote: > > This patch will attempt to describe the region type in the event > > that a given RMRR entry is not within a reserved region. > > Hmm, is this useful information for the user? You'd hope the firmware vendor > knows the memory map already, but either way, is it particularly likely that > anyone would be noticing and caring about this warning in a context where > they couldn't just scroll further up the log and cross-reference the full > memory map listing? If so, it might be worth clarifying what that use-case > is, since as it stands there doesn't seem to be much justification for the > "why" here. Hi Robin, Thanks for looking at this. Honestly, the only justification for the modification/or proposed changes is to have more insight when this statement is provided in total isolation and the RAM map listing (as per e820__print_table()) is no longer available to reference. > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > > index 95b994cf80cd..165e9a444bb9 100644 > > --- a/arch/x86/kernel/e820.c > > +++ b/arch/x86/kernel/e820.c > > @@ -1073,7 +1073,7 @@ void __init e820__finish_early_params(void) > > const char *__init e820_type_to_string(struct e820_entry *entry) > > { > > - switch (entry->type) { > > + switch (entry && entry->type) { > > Have you tested this for anything other than E820_TYPE_RAM? I think > sufficiently up-to-date compilers should warn you here anyway. I have not. Kind regards, -- Aaron Tomlin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 15/16] arm64: dts: mt8195: Add gce node
From: "Jason-JH.Lin" Add gce node and gce alias to mt8195 device tree. Signed-off-by: Jason-JH.Lin Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index cb2b79dc08d1..724c6ca837b6 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -6,6 +6,7 @@ /dts-v1/; #include +#include #include #include #include @@ -19,6 +20,11 @@ #address-cells = <2>; #size-cells = <2>; + aliases { + gce0 = &gce0; + gce1 = &gce1; + }; + cpus { #address-cells = <1>; #size-cells = <0>; @@ -739,6 +745,22 @@ #iommu-cells = <1>; }; + gce0: mailbox@1032 { + compatible = "mediatek,mt8195-gce"; + reg = <0 0x1032 0 0x4000>; + interrupts = ; + #mbox-cells = <2>; + clocks = <&infracfg_ao CLK_INFRA_AO_GCE>; + }; + + gce1: mailbox@1033 { + compatible = "mediatek,mt8195-gce"; + reg = <0 0x1033 0 0x4000>; + interrupts = ; + #mbox-cells = <2>; + clocks = <&infracfg_ao CLK_INFRA_AO_GCE2>; + }; + scp: scp@1050 { compatible = "mediatek,mt8195-scp"; reg = <0 0x1050 0 0x10>, -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 13/16] arm64: dts: mt8195: Specify audio reset controller
From: Trevor Wu Specify audio reset controller for audio hardware resetting. Signed-off-by: Trevor Wu Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 0e5614108c12..618fb2fa195a 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -681,6 +681,7 @@ "mediatek,mt6589-wdt"; mediatek,disable-extrst; reg = <0 0x10007000 0 0x100>; + #reset-cells = <1>; }; apmixedsys: syscon@1000c000 { @@ -783,6 +784,8 @@ mediatek,topckgen = <&topckgen>; power-domains = <&spm MT8195_POWER_DOMAIN_AUDIO>; interrupts = ; + resets = <&watchdog 14>; + reset-names = "audiosys"; clocks = <&clk26m>, <&apmixedsys CLK_APMIXED_APLL1>, <&apmixedsys CLK_APMIXED_APLL2>, -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 12/16] arm64: dts: mt8195: Add adsp node and adsp mailbox nodes
From: YC Hung Add adsp node and adsp mailbox nodes for mt8195. Signed-off-by: YC Hung Signed-off-by: Allen-KH Cheng Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 37 1 file changed, 37 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 1776f5dcde03..0e5614108c12 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -740,6 +740,43 @@ #clock-cells = <1>; }; + adsp: adsp@10803000 { + compatible = "mediatek,mt8195-dsp"; + reg = <0 0x10803000 0 0x1000>, + <0 0x1084 0 0x4>; + reg-names = "cfg", "sram"; + clocks = <&topckgen CLK_TOP_ADSP>, +<&clk26m>, +<&topckgen CLK_TOP_AUDIO_LOCAL_BUS>, +<&topckgen CLK_TOP_MAINPLL_D7_D2>, +<&scp_adsp CLK_SCP_ADSP_AUDIODSP>, +<&topckgen CLK_TOP_AUDIO_H>; + clock-names = "adsp_sel", +"clk26m_ck", +"audio_local_bus", +"mainpll_d7_d2", +"scp_adsp_audiodsp", +"audio_h"; + power-domains = <&spm MT8195_POWER_DOMAIN_ADSP>; + mbox-names = "rx", "tx"; + mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>; + status = "disabled"; + }; + + adsp_mailbox0: mailbox@10816000 { + compatible = "mediatek,mt8195-adsp-mbox"; + #mbox-cells = <0>; + reg = <0 0x10816000 0 0x1000>; + interrupts = ; + }; + + adsp_mailbox1: mailbox@10817000 { + compatible = "mediatek,mt8195-adsp-mbox"; + #mbox-cells = <0>; + reg = <0 0x10817000 0 0x1000>; + interrupts = ; + }; + afe: mt8195-afe-pcm@1089 { compatible = "mediatek,mt8195-audio"; reg = <0 0x1089 0 0x1>; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 16/16] arm64: dts: mt8195: Add display node for vdosys0
From: "Jason-JH.Lin" Add display node for vdosys0 of mt8195. Signed-off-by: Jason-JH.Lin Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 109 +++ 1 file changed, 109 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 724c6ca837b6..faea8ef33e5a 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -1961,6 +1961,7 @@ vdosys0: syscon@1c01a000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x1c01a000 0 0x1000>; + mboxes = <&gce0 0 CMDQ_THR_PRIO_4>; #clock-cells = <1>; }; @@ -1976,6 +1977,114 @@ power-domains = <&spm MT8195_POWER_DOMAIN_VENC_CORE1>; }; + ovl0: ovl@1c00 { + compatible = "mediatek,mt8195-disp-ovl", +"mediatek,mt8183-disp-ovl"; + reg = <0 0x1c00 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; + iommus = <&iommu_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x 0x1000>; + }; + + rdma0: rdma@1c002000 { + compatible = "mediatek,mt8195-disp-rdma"; + reg = <0 0x1c002000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_RDMA0>; + iommus = <&iommu_vdo M4U_PORT_L0_DISP_RDMA0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x2000 0x1000>; + }; + + color0: color@1c003000 { + compatible = "mediatek,mt8195-disp-color", +"mediatek,mt8173-disp-color"; + reg = <0 0x1c003000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_COLOR0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x3000 0x1000>; + }; + + ccorr0: ccorr@1c004000 { + compatible = "mediatek,mt8195-disp-ccorr", +"mediatek,mt8192-disp-ccorr"; + reg = <0 0x1c004000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_CCORR0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x4000 0x1000>; + }; + + aal0: aal@1c005000 { + compatible = "mediatek,mt8195-disp-aal", +"mediatek,mt8183-disp-aal"; + reg = <0 0x1c005000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_AAL0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x5000 0x1000>; + }; + + gamma0: gamma@1c006000 { + compatible = "mediatek,mt8195-disp-gamma", +"mediatek,mt8183-disp-gamma"; + reg = <0 0x1c006000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_GAMMA0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x6000 0x1000>; + }; + + dither0: dither@1c007000 { + compatible = "mediatek,mt8195-disp-dither", +"mediatek,mt8183-disp-dither"; + reg = <0 0x1c007000 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_DITHER0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x7000 0x1000>; + }; + + dsc0: dsc@1c009000 { + compatible = "mediatek,mt8195-disp-dsc"; + reg = <0 0x1c009000 0 0x1000>
[PATCH v1 07/16] arm64: dts: mt8195: Add vdosys and vppsys clock nodes
Add display clock nodes. Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 24 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 900aaa16f862..8d59a7da3271 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -983,6 +983,12 @@ #clock-cells = <1>; }; + vppsys0: clock-controller@1400 { + compatible = "mediatek,mt8195-vppsys0"; + reg = <0 0x1400 0 0x1000>; + #clock-cells = <1>; + }; + wpesys: clock-controller@14e0 { compatible = "mediatek,mt8195-wpesys"; reg = <0 0x14e0 0 0x1000>; @@ -1001,6 +1007,12 @@ #clock-cells = <1>; }; + vppsys1: clock-controller@14f0 { + compatible = "mediatek,mt8195-vppsys1"; + reg = <0 0x14f0 0 0x1000>; + #clock-cells = <1>; + }; + imgsys: clock-controller@1500 { compatible = "mediatek,mt8195-imgsys"; reg = <0 0x1500 0 0x1000>; @@ -1108,5 +1120,17 @@ reg = <0 0x1b00 0 0x1000>; #clock-cells = <1>; }; + + vdosys0: syscon@1c01a000 { + compatible = "mediatek,mt8195-mmsys", "syscon"; + reg = <0 0x1c01a000 0 0x1000>; + #clock-cells = <1>; + }; + + vdosys1: syscon@1c10 { + compatible = "mediatek,mt8195-mmsys", "syscon"; + reg = <0 0x1c10 0 0x1000>; + #clock-cells = <1>; + }; }; }; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 14/16] arm64: dts: mt8195: Add iommu and smi nodes
Add iommu nodes and smi nodes for mt8195. Signed-off-by: Yong Wu Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 451 +++ 1 file changed, 451 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 618fb2fa195a..cb2b79dc08d1 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -725,6 +726,19 @@ assigned-clock-parents = <&topckgen CLK_TOP_ULPOSC1_D10>; }; + iommu_infra: infra-iommu@10315000 { + compatible = "mediatek,mt8195-iommu-infra"; + reg = <0 0x10315000 0 0x5000>; + interrupts = , +, +, +, +; + clocks = <&clk26m>; + clock-names = "bclk"; + #iommu-cells = <1>; + }; + scp: scp@1050 { compatible = "mediatek,mt8195-scp"; reg = <0 0x1050 0 0x10>, @@ -1439,6 +1453,64 @@ #clock-cells = <1>; }; + smi_sub_common_vpp0_vpp1_2x1: smi@1401 { + compatible = "mediatek,mt8195-smi-sub-common"; + reg = <0 0x1401 0 0x1000>; + clocks = <&vppsys0 CLK_VPP0_GALS_VPP1_WPE>, + <&vppsys0 CLK_VPP0_GALS_VPP1_WPE>, + <&vppsys0 CLK_VPP0_GALS_VPP1_WPE>; + clock-names = "apb", "smi", "gals0"; + mediatek,smi = <&smi_common_vpp>; + power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>; + }; + + smi_sub_common_vdec_vpp0_2x1: smi@14011000 { + compatible = "mediatek,mt8195-smi-sub-common"; + reg = <0 0x14011000 0 0x1000>; + clocks = <&vppsys0 CLK_VPP0_GALS_VDEC_VDEC_CORE1>, +<&vppsys0 CLK_VPP0_GALS_VDEC_VDEC_CORE1>, +<&vppsys0 CLK_VPP0_GALS_VDEC_VDEC_CORE1>; + clock-names = "apb", "smi", "gals0"; + mediatek,smi = <&smi_common_vpp>; + power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>; + }; + + smi_common_vpp: smi@14012000 { + compatible = "mediatek,mt8195-smi-common-vpp"; + reg = <0 0x14012000 0 0x1000>; + clocks = <&vppsys0 CLK_VPP0_SMI_COMMON_LARB4>, + <&vppsys0 CLK_VPP0_SMI_COMMON_LARB4>, + <&vppsys0 CLK_VPP0_SMI_RSI>, + <&vppsys0 CLK_VPP0_SMI_RSI>; + clock-names = "apb", "smi", "gals0", "gals1"; + power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>; + }; + + larb4: larb@14013000 { + compatible = "mediatek,mt8195-smi-larb"; + reg = <0 0x14013000 0 0x1000>; + mediatek,larb-id = <4>; + mediatek,smi = <&smi_sub_common_vpp0_vpp1_2x1>; + clocks = <&vppsys0 CLK_VPP0_GALS_VPP1_WPE>, + <&vppsys0 CLK_VPP0_SMI_COMMON_LARB4>; + clock-names = "apb", "smi"; + power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>; + }; + + iommu_vpp: iommu@14018000 { + compatible = "mediatek,mt8195-iommu-vpp"; + reg = <0 0x14018000 0 0x1000>; + mediatek,larbs = <&larb1 &larb3 &larb4 &larb6 &larb8 + &larb12 &larb14 &larb16 &larb18 + &larb20 &larb22 &larb23 &larb26 + &larb27>; + interrupts = ; + clocks = <&vppsys0 CLK_VPP0_SMI_IOMMU>; + clock-names = "bclk"; + #iommu-cells = <1>; + power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>; + }; + wpesys: clock-controller@14e0 { compatible = "mediatek,mt8195-wpesys"; reg = <0 0x14e0 0 0x1000>; @@ -1457,24 +1529,116 @@ #clock-cells = <1>; }; + larb7: larb@14e04000 { + compatible = "mediatek,mt8195-smi-larb"; + reg = <0 0x14e04000 0 0x1000>; + medi
[PATCH v1 11/16] arm64: dts: mt8195: Add audio related nodes
Add audio related nodes for mt8195. Signed-off-by: Trevor Wu Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 58 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 543bb719a445..1776f5dcde03 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -226,6 +226,17 @@ <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>; }; + dmic_codec: dmic-codec { + compatible = "dmic-codec"; + num-channels = <2>; + wakeup-delay-ms = <50>; + }; + + sound: mt8195-sound { + mediatek,platform = <&afe>; + status = "disabled"; + }; + clk26m: oscillator-26m { compatible = "fixed-clock"; #clock-cells = <0>; @@ -729,6 +740,53 @@ #clock-cells = <1>; }; + afe: mt8195-afe-pcm@1089 { + compatible = "mediatek,mt8195-audio"; + reg = <0 0x1089 0 0x1>; + mediatek,topckgen = <&topckgen>; + power-domains = <&spm MT8195_POWER_DOMAIN_AUDIO>; + interrupts = ; + clocks = <&clk26m>, + <&apmixedsys CLK_APMIXED_APLL1>, + <&apmixedsys CLK_APMIXED_APLL2>, + <&topckgen CLK_TOP_APLL12_DIV0>, + <&topckgen CLK_TOP_APLL12_DIV1>, + <&topckgen CLK_TOP_APLL12_DIV2>, + <&topckgen CLK_TOP_APLL12_DIV3>, + <&topckgen CLK_TOP_APLL12_DIV9>, + <&topckgen CLK_TOP_A1SYS_HP>, + <&topckgen CLK_TOP_AUD_INTBUS>, + <&topckgen CLK_TOP_AUDIO_H>, + <&topckgen CLK_TOP_AUDIO_LOCAL_BUS>, + <&topckgen CLK_TOP_DPTX_MCK>, + <&topckgen CLK_TOP_I2SO1_MCK>, + <&topckgen CLK_TOP_I2SO2_MCK>, + <&topckgen CLK_TOP_I2SI1_MCK>, + <&topckgen CLK_TOP_I2SI2_MCK>, + <&infracfg_ao CLK_INFRA_AO_AUDIO_26M_B>, + <&scp_adsp CLK_SCP_ADSP_AUDIODSP>; + clock-names = "clk26m", + "apll1_ck", + "apll2_ck", + "apll12_div0", + "apll12_div1", + "apll12_div2", + "apll12_div3", + "apll12_div9", + "a1sys_hp_sel", + "aud_intbus_sel", + "audio_h_sel", + "audio_local_bus_sel", + "dptx_m_sel", + "i2so1_m_sel", + "i2so2_m_sel", + "i2si1_m_sel", + "i2si2_m_sel", + "infra_ao_audio_26m_b", + "scp_adsp_audiodsp"; + status = "disabled"; + }; + uart0: serial@11001100 { compatible = "mediatek,mt8195-uart", "mediatek,mt6577-uart"; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
The max clock items for the dts node with compatible 'mediatek,mt8195-smi-sub-common' should be 3. However, the dtbs_check of such node will get following message, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: ['apb', 'smi', 'gals0'] is too long From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml Remove the last 'else' checking to fix this error. Signed-off-by: Tinghan Shen --- .../memory-controllers/mediatek,smi-common.yaml| 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a98b359bf909..e5f553e2e12a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -143,7 +143,15 @@ allOf: - const: gals0 - const: gals1 -else: # for gen2 HW that don't have gals + - if: # for gen2 HW that don't have gals + properties: +compatible: + enum: +- mediatek,mt2712-smi-common +- mediatek,mt8167-smi-common +- mediatek,mt8173-smi-common + +then: properties: clocks: minItems: 2 -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 08/16] arm64: dts: mt8195: Add power domains controller
Add power domains controller node for mt8195. Signed-off-by: Weiyi Lu Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 327 +++ 1 file changed, 327 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 8d59a7da3271..d52e140d9271 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -10,6 +10,7 @@ #include #include #include +#include / { compatible = "mediatek,mt8195"; @@ -338,6 +339,332 @@ #interrupt-cells = <2>; }; + scpsys: syscon@10006000 { + compatible = "syscon", "simple-mfd"; + reg = <0 0x10006000 0 0x1000>; + #power-domain-cells = <1>; + + /* System Power Manager */ + spm: power-controller { + compatible = "mediatek,mt8195-power-controller"; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + /* power domain of the SoC */ + mfg0: power-domain@MT8195_POWER_DOMAIN_MFG0 { + reg = ; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + power-domain@MT8195_POWER_DOMAIN_MFG1 { + reg = ; + clocks = <&apmixedsys CLK_APMIXED_MFGPLL>; + clock-names = "mfg"; + mediatek,infracfg = <&infracfg_ao>; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <1>; + + power-domain@MT8195_POWER_DOMAIN_MFG2 { + reg = ; + #power-domain-cells = <0>; + }; + + power-domain@MT8195_POWER_DOMAIN_MFG3 { + reg = ; + #power-domain-cells = <0>; + }; + + power-domain@MT8195_POWER_DOMAIN_MFG4 { + reg = ; + #power-domain-cells = <0>; + }; + + power-domain@MT8195_POWER_DOMAIN_MFG5 { + reg = ; + #power-domain-cells = <0>; + }; + + power-domain@MT8195_POWER_DOMAIN_MFG6 { + reg = ; + #power-domain-cells = <0>; + }; + }; + }; + + power-domain@MT8195_POWER_DOMAIN_VPPSYS0 { + reg = ; + clocks = <&topckgen CLK_TOP_VPP>, +<&topckgen CLK_TOP_CAM>, +<&topckgen CLK_TOP_CCU>, +<&topckgen CLK_TOP_IMG>, +<&topckgen CLK_TOP_VENC>, +<&topckgen CLK_TOP_VDEC>, +<&topckgen CLK_TOP_WPE_VPP>, +<&topckgen CLK_TOP_CFG_VPP0>, +<&vppsys0 CLK_VPP0_SMI_COMMON>, +<&vppsys0 CLK_VPP0_GALS_VDO0_LARB0>, +<&vppsys0 CLK_VPP0_GALS_VDO0_LARB1>, +<&vppsys0 CLK_VPP0_GALS_VENCSYS>, +<&vppsys0 CLK_VPP0_GALS_VENCSYS_CORE1>, +<&vppsys0 CLK_VPP0_GALS_INFRA>, +<&vp
[PATCH v1 04/16] arm64: dts: mt8195: Disable watchdog external reset signal
Disable external output reset signal in first round of watchdog reset to reserve wdt reset reason for debugging watchdog issue. Signed-off-by: Fengquan Chen Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 066c14989708..436687ba826f 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -327,6 +327,7 @@ watchdog: watchdog@10007000 { compatible = "mediatek,mt8195-wdt", "mediatek,mt6589-wdt"; + mediatek,disable-extrst; reg = <0 0x10007000 0 0x100>; }; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 06/16] arm64: dts: mt8195: Add cpufreq node
From: YT Lee Add cpufreq node for mt8195. Signed-off-by: YT Lee Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 8032b839dfe8..900aaa16f862 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -26,6 +26,7 @@ compatible = "arm,cortex-a55"; reg = <0x000>; enable-method = "psci"; + performance-domains = <&performance 0>; clock-frequency = <170100>; capacity-dmips-mhz = <578>; cpu-idle-states = <&cpu_off_l &cluster_off_l>; @@ -38,6 +39,7 @@ compatible = "arm,cortex-a55"; reg = <0x100>; enable-method = "psci"; + performance-domains = <&performance 0>; clock-frequency = <170100>; capacity-dmips-mhz = <578>; cpu-idle-states = <&cpu_off_l &cluster_off_l>; @@ -50,6 +52,7 @@ compatible = "arm,cortex-a55"; reg = <0x200>; enable-method = "psci"; + performance-domains = <&performance 0>; clock-frequency = <170100>; capacity-dmips-mhz = <578>; cpu-idle-states = <&cpu_off_l &cluster_off_l>; @@ -62,6 +65,7 @@ compatible = "arm,cortex-a55"; reg = <0x300>; enable-method = "psci"; + performance-domains = <&performance 0>; clock-frequency = <170100>; capacity-dmips-mhz = <578>; cpu-idle-states = <&cpu_off_l &cluster_off_l>; @@ -74,6 +78,7 @@ compatible = "arm,cortex-a78"; reg = <0x400>; enable-method = "psci"; + performance-domains = <&performance 1>; clock-frequency = <217100>; capacity-dmips-mhz = <1024>; cpu-idle-states = <&cpu_off_b &cluster_off_b>; @@ -86,6 +91,7 @@ compatible = "arm,cortex-a78"; reg = <0x500>; enable-method = "psci"; + performance-domains = <&performance 1>; clock-frequency = <217100>; capacity-dmips-mhz = <1024>; cpu-idle-states = <&cpu_off_b &cluster_off_b>; @@ -98,6 +104,7 @@ compatible = "arm,cortex-a78"; reg = <0x600>; enable-method = "psci"; + performance-domains = <&performance 1>; clock-frequency = <217100>; capacity-dmips-mhz = <1024>; cpu-idle-states = <&cpu_off_b &cluster_off_b>; @@ -110,6 +117,7 @@ compatible = "arm,cortex-a78"; reg = <0x700>; enable-method = "psci"; + performance-domains = <&performance 1>; clock-frequency = <217100>; capacity-dmips-mhz = <1024>; cpu-idle-states = <&cpu_off_b &cluster_off_b>; @@ -231,6 +239,12 @@ clock-output-names = "clk32k"; }; + performance: performance-controller@11bc10 { + compatible = "mediatek,cpufreq-hw"; + reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>; + #performance-domain-cells = <1>; + }; + pmu-a55 { compatible = "arm,cortex-a55-pmu"; interrupt-parent = <&gic>; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 00/16] Add driver nodes for MT8195 SoC
Add driver nodes for MT8195 SoC. Patchset 12 depends on https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=009b21f392759ca7be91bc4be9d9534f6cee2878 Jason-JH.Lin (2): arm64: dts: mt8195: Add gce node arm64: dts: mt8195: Add display node for vdosys0 Tinghan Shen (10): dt-bindings: iommu: mediatek: Increase max interrupt number dt-bindings: memory: mediatek: Update condition for mt8195 smi node dt-bindings: power: mediatek: Refine multiple level power domain nodes arm64: dts: mt8195: Disable watchdog external reset signal arm64: dts: mt8195: Add vdosys and vppsys clock nodes arm64: dts: mt8195: Add power domains controller arm64: dts: mt8195: Add spmi node arm64: dts: mt8195: Add scp node arm64: dts: mt8195: Add audio related nodes arm64: dts: mt8195: Add iommu and smi nodes Trevor Wu (1): arm64: dts: mt8195: Specify audio reset controller Tzung-Bi Shih (1): arm64: dts: mt8195: Disable I2C0 node YC Hung (1): arm64: dts: mt8195: Add adsp node and adsp mailbox nodes YT Lee (1): arm64: dts: mt8195: Add cpufreq node .../bindings/iommu/mediatek,iommu.yaml| 12 +- .../mediatek,smi-common.yaml | 10 +- .../power/mediatek,power-controller.yaml | 132 +- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1073 - 4 files changed, 1104 insertions(+), 123 deletions(-) -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 10/16] arm64: dts: mt8195: Add scp node
Add scp node for mt8195. Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 456612d9d508..543bb719a445 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -713,6 +713,16 @@ assigned-clock-parents = <&topckgen CLK_TOP_ULPOSC1_D10>; }; + scp: scp@1050 { + compatible = "mediatek,mt8195-scp"; + reg = <0 0x1050 0 0x10>, + <0 0x1072 0 0xe>, + <0 0x1070 0 0x8000>; + reg-names = "sram", "cfg", "l1tcm"; + interrupts = ; + status = "disabled"; + }; + scp_adsp: clock-controller@1072 { compatible = "mediatek,mt8195-scp_adsp"; reg = <0 0x1072 0 0x1000>; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 05/16] arm64: dts: mt8195: Disable I2C0 node
From: Tzung-Bi Shih The I2C0 node doesn't need to be enabled in dtsi. Signed-off-by: Tzung-Bi Shih Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 436687ba826f..8032b839dfe8 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -829,7 +829,7 @@ clock-names = "main", "dma"; #address-cells = <1>; #size-cells = <0>; - status = "okay"; + status = "disabled"; }; i2c1: i2c@11e01000 { -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 01/16] dt-bindings: iommu: mediatek: Increase max interrupt number
mt8195 infra iommu has max 5 interrupts. Signed-off-by: Tinghan Shen --- .../devicetree/bindings/iommu/mediatek,iommu.yaml| 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 2ae3bbad7f1a..27eb9f6aa3ce 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -91,7 +91,8 @@ properties: maxItems: 1 interrupts: -maxItems: 1 +minItems: 1 +maxItems: 5 clocks: items: @@ -175,9 +176,18 @@ allOf: const: mediatek,mt8195-iommu-infra then: + properties: +interrupts: + maxItems: 1 + required: - mediatek,larbs +else: + properties: +interrupts: + maxItems: 5 + additionalProperties: false examples: -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 09/16] arm64: dts: mt8195: Add spmi node
Add spmi node to mt8195. Signed-off-by: Henry Chen Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index d52e140d9271..456612d9d508 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -698,6 +698,21 @@ assigned-clock-parents = <&topckgen CLK_TOP_ULPOSC1_D10>; }; + spmi: spmi@10027000 { + compatible = "mediatek,mt8195-spmi"; + reg = <0 0x10027000 0 0x000e00>, + <0 0x10029000 0 0x000100>; + reg-names = "pmif", "spmimst"; + clocks = <&infracfg_ao CLK_INFRA_AO_PMIC_AP>, +<&infracfg_ao CLK_INFRA_AO_PMIC_TMR>, +<&topckgen CLK_TOP_SPMI_M_MST>; + clock-names = "pmif_sys_ck", + "pmif_tmr_ck", + "spmimst_clk_mux"; + assigned-clocks = <&topckgen CLK_TOP_PWRAP_ULPOSC>; + assigned-clock-parents = <&topckgen CLK_TOP_ULPOSC1_D10>; + }; + scp_adsp: clock-controller@1072 { compatible = "mediatek,mt8195-scp_adsp"; reg = <0 0x1072 0 0x1000>; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 03/16] dt-bindings: power: mediatek: Refine multiple level power domain nodes
Extract duplicated properties and support more levels of power domain nodes. This change fix following error when do dtbs_check, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: power-controller: power-domain@15:power-domain@16:power-domain@18: 'power-domain@19', 'power-domain@20', 'power-domain@21' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/power/mediatek,power-controller.yaml Signed-off-by: Tinghan Shen --- .../power/mediatek,power-controller.yaml | 132 ++ 1 file changed, 12 insertions(+), 120 deletions(-) diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index 135c6f722091..09a537a802b8 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -39,8 +39,17 @@ properties: '#size-cells': const: 0 +required: + - compatible + +additionalProperties: false + patternProperties: "^power-domain@[0-9a-f]+$": +$ref: "#/$defs/power-domain-node" + +$defs: + power-domain-node: type: object description: | Represents the power domains within the power controller node as documented @@ -98,127 +107,10 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/phandle description: phandle to the device containing the SMI register range. -patternProperties: - "^power-domain@[0-9a-f]+$": -type: object -description: | - Represents a power domain child within a power domain parent node. - -properties: - - '#power-domain-cells': -description: - Must be 0 for nodes representing a single PM domain and 1 for nodes - providing multiple PM domains. - - '#address-cells': -const: 1 - - '#size-cells': -const: 0 - - reg: -maxItems: 1 - - clocks: -description: | - A number of phandles to clocks that need to be enabled during domain - power-up sequencing. - - clock-names: -description: | - List of names of clocks, in order to match the power-up sequencing - for each power domain we need to group the clocks by name. BASIC - clocks need to be enabled before enabling the corresponding power - domain, and should not have a '-' in their name (i.e mm, mfg, venc). - SUSBYS clocks need to be enabled before releasing the bus protection, - and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). - - In order to follow properly the power-up sequencing, the clocks must - be specified by order, adding first the BASIC clocks followed by the - SUSBSYS clocks. - - domain-supply: -description: domain regulator supply. - - mediatek,infracfg: -$ref: /schemas/types.yaml#/definitions/phandle -description: phandle to the device containing the INFRACFG register range. - - mediatek,smi: -$ref: /schemas/types.yaml#/definitions/phandle -description: phandle to the device containing the SMI register range. - -patternProperties: - "^power-domain@[0-9a-f]+$": -type: object -description: | - Represents a power domain child within a power domain parent node. - -properties: + required: +- reg - '#power-domain-cells': -description: - Must be 0 for nodes representing a single PM domain and 1 for nodes - providing multiple PM domains. - - '#address-cells': -const: 1 - - '#size-cells': -const: 0 - - reg: -maxItems: 1 - - clocks: -description: | - A number of phandles to clocks that need to be enabled during domain - power-up sequencing. - - clock-names: -description: | - List of names of clocks, in order to match the power-up sequencing - for each power domain we need to group the clocks by name. BASIC - clocks need to be enabled before enabling the corresponding power - domain, and should not have a '-' in their name (i.e mm, mfg, venc). - SUSBYS clocks need to be enabled before releasing the bus protection, - and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). - - In order to follow properly the power-up sequencing, the clocks must - be specified by order, adding first the BASIC clocks followed by the -
Re: [PATCH v1 16/16] arm64: dts: mt8195: Add display node for vdosys0
Il 04/07/22 12:00, Tinghan Shen ha scritto: From: "Jason-JH.Lin" Add display node for vdosys0 of mt8195. Signed-off-by: Jason-JH.Lin Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 109 +++ 1 file changed, 109 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 724c6ca837b6..faea8ef33e5a 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -1961,6 +1961,7 @@ vdosys0: syscon@1c01a000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x1c01a000 0 0x1000>; + mboxes = <&gce0 0 CMDQ_THR_PRIO_4>; #clock-cells = <1>; }; @@ -1976,6 +1977,114 @@ power-domains = <&spm MT8195_POWER_DOMAIN_VENC_CORE1>; }; + ovl0: ovl@1c00 { + compatible = "mediatek,mt8195-disp-ovl", +"mediatek,mt8183-disp-ovl"; This fits in one line, please fix, here and all of the other instances of that. + reg = <0 0x1c00 0 0x1000>; + interrupts = ; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; + iommus = <&iommu_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>; + mediatek,gce-client-reg = +<&gce0 SUBSYS_1c00 0x 0x1000>; Same for gce-client-reg. Regards, Angelo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 06/16] arm64: dts: mt8195: Add cpufreq node
Il 04/07/22 12:00, Tinghan Shen ha scritto: From: YT Lee Add cpufreq node for mt8195. Signed-off-by: YT Lee Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 07/16] arm64: dts: mt8195: Add vdosys and vppsys clock nodes
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add display clock nodes. Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 08/16] arm64: dts: mt8195: Add power domains controller
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add power domains controller node for mt8195. Signed-off-by: Weiyi Lu Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 09/16] arm64: dts: mt8195: Add spmi node
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add spmi node to mt8195. Signed-off-by: Henry Chen Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 10/16] arm64: dts: mt8195: Add scp node
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add scp node for mt8195. Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 15/16] arm64: dts: mt8195: Add gce node
Il 04/07/22 12:00, Tinghan Shen ha scritto: From: "Jason-JH.Lin" Add gce node and gce alias to mt8195 device tree. Signed-off-by: Jason-JH.Lin Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 11/16] arm64: dts: mt8195: Add audio related nodes
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add audio related nodes for mt8195. Signed-off-by: Trevor Wu Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 14/16] arm64: dts: mt8195: Add iommu and smi nodes
Il 04/07/22 12:00, Tinghan Shen ha scritto: Add iommu nodes and smi nodes for mt8195. Signed-off-by: Yong Wu Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 13/16] arm64: dts: mt8195: Specify audio reset controller
Il 04/07/22 12:00, Tinghan Shen ha scritto: From: Trevor Wu Specify audio reset controller for audio hardware resetting. Signed-off-by: Trevor Wu Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 3/3] iommu/vt-d: Show region type in arch_rmrr_sanity_check()
On 2022-06-11 21:48, Aaron Tomlin wrote: This patch will attempt to describe the region type in the event that a given RMRR entry is not within a reserved region. Hmm, is this useful information for the user? You'd hope the firmware vendor knows the memory map already, but either way, is it particularly likely that anyone would be noticing and caring about this warning in a context where they couldn't just scroll further up the log and cross-reference the full memory map listing? If so, it might be worth clarifying what that use-case is, since as it stands there doesn't seem to be much justification for the "why" here. Signed-off-by: Aaron Tomlin --- arch/x86/include/asm/iommu.h | 9 ++--- arch/x86/kernel/e820.c | 5 +++-- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h index bf1ed2ddc74b..d21366644520 100644 --- a/arch/x86/include/asm/iommu.h +++ b/arch/x86/include/asm/iommu.h @@ -17,12 +17,15 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr) { u64 start = rmrr->base_address; u64 end = rmrr->end_address + 1; + struct e820_entry *entry; - if (e820__mapped_all(start, end, E820_TYPE_RESERVED)) + entry = __e820__mapped_all(start, end, 0); + + if (entry && entry->type == E820_TYPE_RESERVED) return 0; - pr_err(FW_BUG "No firmware reserved region can cover this RMRR [%#018Lx-%#018Lx], contact BIOS vendor for fixes\n", - start, end - 1); + pr_err(FW_BUG "No firmware reserved region can cover this RMRR [%s: %#018Lx-%#018Lx], contact BIOS vendor for fixes\n", + e820_type_to_string(entry), start, end - 1); return -EINVAL; } diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 95b994cf80cd..165e9a444bb9 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1073,7 +1073,7 @@ void __init e820__finish_early_params(void) const char *__init e820_type_to_string(struct e820_entry *entry) { - switch (entry->type) { + switch (entry && entry->type) { Have you tested this for anything other than E820_TYPE_RAM? I think sufficiently up-to-date compilers should warn you here anyway. Robin. case E820_TYPE_RESERVED_KERN: /* Fall-through: */ case E820_TYPE_RAM: return "System RAM"; case E820_TYPE_ACPI:return "ACPI Tables"; @@ -1083,8 +1083,9 @@ const char *__init e820_type_to_string(struct e820_entry *entry) case E820_TYPE_PMEM:return "Persistent Memory"; case E820_TYPE_RESERVED:return "Reserved"; case E820_TYPE_SOFT_RESERVED: return "Soft Reserved"; - default:return "Unknown E820 type"; + default:break; } + return "Unknown E820 type"; } static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 05/16] arm64: dts: mt8195: Disable I2C0 node
Il 04/07/22 12:00, Tinghan Shen ha scritto: From: Tzung-Bi Shih The I2C0 node doesn't need to be enabled in dtsi. "The I2C0 node should not be enabled globally, as usage is board dependant: disable it in dtsi." after which... Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Tzung-Bi Shih Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 436687ba826f..8032b839dfe8 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -829,7 +829,7 @@ clock-names = "main", "dma"; #address-cells = <1>; #size-cells = <0>; - status = "okay"; + status = "disabled"; }; i2c1: i2c@11e01000 { ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 04/16] arm64: dts: mt8195: Disable watchdog external reset signal
Il 04/07/22 12:00, Tinghan Shen ha scritto: Disable external output reset signal in first round of watchdog reset to reserve wdt reset reason for debugging watchdog issue. If my understanding of the commit decription is right, then we can clarify that with something like: "[...] for debugging eventual watchdog issues". Otherwise, if this implies that disable-extrst is needed to avoid losing the reset reason stored in the WDT, you could say something like: "Disable external output reset signal in the first round of watchdog reset to avoid losing the reset reason stored in the watchdog registers" After which: Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Fengquan Chen Signed-off-by: Tinghan Shen --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index 066c14989708..436687ba826f 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi @@ -327,6 +327,7 @@ watchdog: watchdog@10007000 { compatible = "mediatek,mt8195-wdt", "mediatek,mt6589-wdt"; + mediatek,disable-extrst; reg = <0 0x10007000 0 0x100>; }; ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
Il 04/07/22 12:00, Tinghan Shen ha scritto: The max clock items for the dts node with compatible 'mediatek,mt8195-smi-sub-common' should be 3. However, the dtbs_check of such node will get following message, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: ['apb', 'smi', 'gals0'] is too long From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml Remove the last 'else' checking to fix this error. Signed-off-by: Tinghan Shen --- .../memory-controllers/mediatek,smi-common.yaml| 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a98b359bf909..e5f553e2e12a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -143,7 +143,15 @@ allOf: - const: gals0 - const: gals1 -else: # for gen2 HW that don't have gals + - if: # for gen2 HW that don't have gals + properties: +compatible: + enum: +- mediatek,mt2712-smi-common MT6795 also doesn't have any GALS, please add it in here. Regards, Angelo +- mediatek,mt8167-smi-common +- mediatek,mt8173-smi-common + +then: properties: clocks: minItems: 2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/mediatek: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: 42d57fc58aeb ("iommu/mediatek: Initialise/Remove for multi bank dev") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang --- drivers/iommu/mtk_iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index b2ae84046249..b45b0c1cfff9 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -1174,6 +1174,8 @@ static int mtk_iommu_probe(struct platform_device *pdev) banks_num = data->plat_data->banks_num; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) + return -EINVAL; if (resource_size(res) < banks_num * MTK_IOMMU_BANK_SZ) { dev_err(dev, "banknr %d. res %pR is not enough.\n", banks_num, res); return -EINVAL; -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: (EXT) Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
Am Freitag, 1. Juli 2022, 09:02:22 CEST schrieb Saravana Kannan: > On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein > > wrote: > > Hi Saravana, > > > > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan: > > > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein > > > > > > wrote: > > > > Hi, > > > > > > > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren: > > > > > Hi, > > > > > > > > > > * Saravana Kannan [700101 02:00]: > > > > > > Now that fw_devlink=on by default and fw_devlink supports > > > > > > "power-domains" property, the execution will never get to the > > > > > > point > > > > > > where driver_deferred_probe_check_state() is called before the > > > > > > supplier > > > > > > has probed successfully or before deferred probe timeout has > > > > > > expired. > > > > > > > > > > > > So, delete the call and replace it with -ENODEV. > > > > > > > > > > Looks like this causes omaps to not boot in Linux next. With this > > > > > simple-pm-bus fails to probe initially as the power-domain is not > > > > > yet available. On platform_probe() genpd_get_from_provider() returns > > > > > -ENOENT. > > > > > > > > > > Seems like other stuff is potentially broken too, any ideas on > > > > > how to fix this? > > > > > > > > I think I'm hit by this as well, although I do not get a lockup. > > > > In my case I'm using > > > > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and probing of > > > > 3832.blk-ctrl fails as the power-domain is not (yet) registed. > > > > > > Ok, took a look. > > > > > > The problem is that there are two drivers for the same device and they > > > both initialize this device. > > > > > > gpc: gpc@303a { > > > > > > compatible = "fsl,imx8mq-gpc"; > > > > > > } > > > > > > $ git grep -l "fsl,imx7d-gpc" -- drivers/ > > > drivers/irqchip/irq-imx-gpcv2.c > > > drivers/soc/imx/gpcv2.c > > > > > > IMHO, this is a bad/broken design. > > > > > > So what's happening is that fw_devlink will block the probe of > > > 3832.blk-ctrl until 303a.gpc is initialized. And it stops > > > blocking the probe of 3832.blk-ctrl as soon as the first driver > > > initializes the device. In this case, it's the irqchip driver. > > > > > > I'd recommend combining these drivers into one. Something like the > > > patch I'm attaching (sorry for the attachment, copy-paste is mangling > > > the tabs). Can you give it a shot please? > > > > I tried this patch and it delayed the driver initialization (those of UART > > as > > well BTW). Unfortunately the driver fails the same way: > Thanks for testing the patch! > > > > [1.125253] imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV: failed > > > to > > > > attach power domain "bus" > > > > More than that it even introduced some more errors: > > > [0.008160] irq: no irq domain found for gpc@303a ! > > So the idea behind my change was that as long as the irqchip isn't the > root of the irqdomain (might be using the terms incorrectly) like the > gic, you can make it a platform driver. And I was trying to hack up a > patch that's the equivalent of platform_irqchip_probe() (which just > ends up eventually calling the callback you use in IRQCHIP_DECLARE(). > I probably made some mistake in the quick hack that I'm sure if > fixable. > > > > [0.013251] Failed to map interrupt for > > > /soc@0/bus@3040/timer@306a > > However, this timer driver also uses TIMER_OF_DECLARE() which can't > handle failure to get the IRQ (because it's can't -EPROBE_DEFER). So, > this means, the timer driver inturn needs to be converted to a > platform driver if it's supposed to work with the IRQCHIP_DECLARE() > being converted to a platform driver. > > But that's a can of worms not worth opening. But then I remembered > this simpler workaround will work and it is pretty much a variant of > the workaround that's already in the gpc's irqchip driver to allow two > drivers to probe the same device (people really should stop doing > that). > > Can you drop my previous hack patch and try this instead please? I'm > 99% sure this will work. > > diff --git a/drivers/irqchip/irq-imx-gpcv2.c > b/drivers/irqchip/irq-imx-gpcv2.c index b9c22f764b4d..8a0e82067924 100644 > --- a/drivers/irqchip/irq-imx-gpcv2.c > +++ b/drivers/irqchip/irq-imx-gpcv2.c > @@ -283,6 +283,7 @@ static int __init imx_gpcv2_irqchip_init(struct > device_node *node, > * later the GPC power domain driver will not be skipped. > */ > of_node_clear_flag(node, OF_POPULATED); > + fwnode_dev_initialized(domain->fwnode, false); > return 0; > } Just to be sure here, I tried this patch on top of next-20220701 but unfortunately this doesn't fix the original problem either. The timer errors are gone though. The probe of imx8m-blk-ctrl got slightly delayed (from 0.74 to 0.90s printk time) but results in the identical error message. Best regards, Alexander ___