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:
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 = >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(>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 = >devs[i];
41
42 ctx->host = host1x;
43
44 device_initialize(>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 = >dma_mask;
52 ctx->dev.coherent_dma_mask = ctx->dma_mask;
53 dev_set_name(>dev, "host1x-ctx.%d", i);
54 ctx->dev.bus = _context_device_bus_type;
55 ctx->dev.parent = host1x->dev;
56
57 dma_set_max_seg_size(>dev, UINT_MAX);
58
59 err = device_add(>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(>dev, node, true, );
66 if (err) {
67 dev_err(host1x->dev, "IOMMU configuration
failed for context device %d: %d\n",
68 i, err);
69 device_del(>dev);
70 goto del_devices;
71 }
72
73 fwspec = dev_iommu_fwspec_get(>dev);
74 if (!fwspec) {
75 dev_err(host1x->dev, "Context device %d has no
IOMMU!\n", i);
76 device_del(>dev);
77 goto del_devices;
78 }
79
> 80 ctx->stream_id = fwspec->ids[0] & 0x;
81 }
82
83
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 error: in arc_ifcvt
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 = < 0 CMDQ_THR_PRIO_4>;
> #clock-cells = <1>;
> };
>
> @@ -1976,6 +1977,114 @@
> power-domains = < 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 = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_OVL0>;
> + iommus = <_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x 0x1000>;
> + };
> +
> + rdma0: rdma@1c002000 {
> + compatible = "mediatek,mt8195-disp-rdma";
> + reg = <0 0x1c002000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_RDMA0>;
> + iommus = <_vdo M4U_PORT_L0_DISP_RDMA0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x2000 0x1000>;
> + };
> +
> + color0: color@1c003000 {
> + compatible = "mediatek,mt8195-disp-color",
> + "mediatek,mt8173-disp-color";
> + reg = <0 0x1c003000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_COLOR0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x3000 0x1000>;
> + };
> +
> + ccorr0: ccorr@1c004000 {
> + compatible = "mediatek,mt8195-disp-ccorr",
> + "mediatek,mt8192-disp-ccorr";
> + reg = <0 0x1c004000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_CCORR0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x4000 0x1000>;
> + };
> +
> + aal0: aal@1c005000 {
> + compatible = "mediatek,mt8195-disp-aal",
> + "mediatek,mt8183-disp-aal";
> + reg = <0 0x1c005000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_AAL0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x5000 0x1000>;
> + };
> +
> + gamma0: gamma@1c006000 {
> + compatible = "mediatek,mt8195-disp-gamma",
> + "mediatek,mt8183-disp-gamma";
> + reg = <0 0x1c006000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_GAMMA0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x6000 0x1000>;
> + };
> +
> + dither0: dither@1c007000 {
> + compatible = "mediatek,mt8195-disp-dither",
> + "mediatek,mt8183-disp-dither";
> + reg = <0 0x1c007000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = < CLK_VDO0_DISP_DITHER0>;
> + mediatek,gce-client-reg =
> + < SUBSYS_1c00 0x7000 0x1000>;
> + };
> +
> + dsc0: dsc@1c009000 {
> + compatible = "mediatek,mt8195-disp-dsc";
> + reg = <0 0x1c009000 0 0x1000>;
> + interrupts = ;
> +
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 =
+ 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 = <_ao CLK_INFRA_AO_GCE>;
+ };
+
+ gce1: mailbox@1033 {
+ compatible = "mediatek,mt8195-gce";
+ reg = <0 0x1033 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <2>;
+ clocks = <_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 = <>;
power-domains = < MT8195_POWER_DOMAIN_AUDIO>;
interrupts = ;
+ resets = < 14>;
+ reset-names = "audiosys";
clocks = <>,
< CLK_APMIXED_APLL1>,
< 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 = < CLK_TOP_ADSP>,
+<>,
+< CLK_TOP_AUDIO_LOCAL_BUS>,
+< CLK_TOP_MAINPLL_D7_D2>,
+<_adsp CLK_SCP_ADSP_AUDIODSP>,
+< CLK_TOP_AUDIO_H>;
+ clock-names = "adsp_sel",
+"clk26m_ck",
+"audio_local_bus",
+"mainpll_d7_d2",
+"scp_adsp_audiodsp",
+"audio_h";
+ power-domains = < MT8195_POWER_DOMAIN_ADSP>;
+ mbox-names = "rx", "tx";
+ mboxes = <_mailbox0>, <_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 = < 0 CMDQ_THR_PRIO_4>;
#clock-cells = <1>;
};
@@ -1976,6 +1977,114 @@
power-domains = < 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 = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_OVL0>;
+ iommus = <_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x 0x1000>;
+ };
+
+ rdma0: rdma@1c002000 {
+ compatible = "mediatek,mt8195-disp-rdma";
+ reg = <0 0x1c002000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_RDMA0>;
+ iommus = <_vdo M4U_PORT_L0_DISP_RDMA0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x2000 0x1000>;
+ };
+
+ color0: color@1c003000 {
+ compatible = "mediatek,mt8195-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1c003000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_COLOR0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x3000 0x1000>;
+ };
+
+ ccorr0: ccorr@1c004000 {
+ compatible = "mediatek,mt8195-disp-ccorr",
+"mediatek,mt8192-disp-ccorr";
+ reg = <0 0x1c004000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_CCORR0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x4000 0x1000>;
+ };
+
+ aal0: aal@1c005000 {
+ compatible = "mediatek,mt8195-disp-aal",
+"mediatek,mt8183-disp-aal";
+ reg = <0 0x1c005000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_AAL0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x5000 0x1000>;
+ };
+
+ gamma0: gamma@1c006000 {
+ compatible = "mediatek,mt8195-disp-gamma",
+"mediatek,mt8183-disp-gamma";
+ reg = <0 0x1c006000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_GAMMA0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x6000 0x1000>;
+ };
+
+ dither0: dither@1c007000 {
+ compatible = "mediatek,mt8195-disp-dither",
+"mediatek,mt8183-disp-dither";
+ reg = <0 0x1c007000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_DITHER0>;
+ mediatek,gce-client-reg =
+< SUBSYS_1c00 0x7000 0x1000>;
+ };
+
+ dsc0: dsc@1c009000 {
+ compatible = "mediatek,mt8195-disp-dsc";
+ reg = <0 0x1c009000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+
[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 = <
CLK_TOP_ULPOSC1_D10>;
};
+ iommu_infra: infra-iommu@10315000 {
+ compatible = "mediatek,mt8195-iommu-infra";
+ reg = <0 0x10315000 0 0x5000>;
+ interrupts = ,
+,
+,
+,
+;
+ clocks = <>;
+ 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 = < CLK_VPP0_GALS_VPP1_WPE>,
+ < CLK_VPP0_GALS_VPP1_WPE>,
+ < CLK_VPP0_GALS_VPP1_WPE>;
+ clock-names = "apb", "smi", "gals0";
+ mediatek,smi = <_common_vpp>;
+ power-domains = < MT8195_POWER_DOMAIN_VPPSYS0>;
+ };
+
+ smi_sub_common_vdec_vpp0_2x1: smi@14011000 {
+ compatible = "mediatek,mt8195-smi-sub-common";
+ reg = <0 0x14011000 0 0x1000>;
+ clocks = < CLK_VPP0_GALS_VDEC_VDEC_CORE1>,
+< CLK_VPP0_GALS_VDEC_VDEC_CORE1>,
+< CLK_VPP0_GALS_VDEC_VDEC_CORE1>;
+ clock-names = "apb", "smi", "gals0";
+ mediatek,smi = <_common_vpp>;
+ power-domains = < MT8195_POWER_DOMAIN_VPPSYS0>;
+ };
+
+ smi_common_vpp: smi@14012000 {
+ compatible = "mediatek,mt8195-smi-common-vpp";
+ reg = <0 0x14012000 0 0x1000>;
+ clocks = < CLK_VPP0_SMI_COMMON_LARB4>,
+ < CLK_VPP0_SMI_COMMON_LARB4>,
+ < CLK_VPP0_SMI_RSI>,
+ < CLK_VPP0_SMI_RSI>;
+ clock-names = "apb", "smi", "gals0", "gals1";
+ power-domains = < MT8195_POWER_DOMAIN_VPPSYS0>;
+ };
+
+ larb4: larb@14013000 {
+ compatible = "mediatek,mt8195-smi-larb";
+ reg = <0 0x14013000 0 0x1000>;
+ mediatek,larb-id = <4>;
+ mediatek,smi = <_sub_common_vpp0_vpp1_2x1>;
+ clocks = < CLK_VPP0_GALS_VPP1_WPE>,
+ < CLK_VPP0_SMI_COMMON_LARB4>;
+ clock-names = "apb", "smi";
+ power-domains = < MT8195_POWER_DOMAIN_VPPSYS0>;
+ };
+
+ iommu_vpp: iommu@14018000 {
+ compatible = "mediatek,mt8195-iommu-vpp";
+ reg = <0 0x14018000 0 0x1000>;
+ mediatek,larbs = <
+
+
+ >;
+ interrupts = ;
+ clocks = < CLK_VPP0_SMI_IOMMU>;
+ clock-names = "bclk";
+ #iommu-cells = <1>;
+ power-domains = < 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>;
+ mediatek,larb-id = <7>;
+ mediatek,smi = <_common_vdo>;
+ clocks = < CLK_WPE_SMI_LARB7>,
+< CLK_WPE_SMI_LARB7>;
+ clock-names = "apb", "smi";
+
[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 = <
CLK_APMIXED_MFGPLL>;
+ clock-names = "mfg";
+ mediatek,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 = < CLK_TOP_VPP>,
+< CLK_TOP_CAM>,
+< CLK_TOP_CCU>,
+< CLK_TOP_IMG>,
+< CLK_TOP_VENC>,
+< CLK_TOP_VDEC>,
+< CLK_TOP_WPE_VPP>,
+< CLK_TOP_CFG_VPP0>,
+< CLK_VPP0_SMI_COMMON>,
+<
CLK_VPP0_GALS_VDO0_LARB0>,
+<
CLK_VPP0_GALS_VDO0_LARB1>,
+<
CLK_VPP0_GALS_VENCSYS>,
+<
CLK_VPP0_GALS_VENCSYS_CORE1>,
+< CLK_VPP0_GALS_INFRA>,
+<
CLK_VPP0_GALS_CAMSYS>,
+<
CLK_VPP0_GALS_VPP1_LARB5>,
+
[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 @@
<>, <>, <>, <>;
};
+ dmic_codec: dmic-codec {
+ compatible = "dmic-codec";
+ num-channels = <2>;
+ wakeup-delay-ms = <50>;
+ };
+
+ sound: mt8195-sound {
+ mediatek,platform = <>;
+ 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 = <>;
+ power-domains = < MT8195_POWER_DOMAIN_AUDIO>;
+ interrupts = ;
+ clocks = <>,
+ < CLK_APMIXED_APLL1>,
+ < CLK_APMIXED_APLL2>,
+ < CLK_TOP_APLL12_DIV0>,
+ < CLK_TOP_APLL12_DIV1>,
+ < CLK_TOP_APLL12_DIV2>,
+ < CLK_TOP_APLL12_DIV3>,
+ < CLK_TOP_APLL12_DIV9>,
+ < CLK_TOP_A1SYS_HP>,
+ < CLK_TOP_AUD_INTBUS>,
+ < CLK_TOP_AUDIO_H>,
+ < CLK_TOP_AUDIO_LOCAL_BUS>,
+ < CLK_TOP_DPTX_MCK>,
+ < CLK_TOP_I2SO1_MCK>,
+ < CLK_TOP_I2SO2_MCK>,
+ < CLK_TOP_I2SI1_MCK>,
+ < CLK_TOP_I2SI2_MCK>,
+ <_ao CLK_INFRA_AO_AUDIO_26M_B>,
+ <_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 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 = < 0>;
clock-frequency = <170100>;
capacity-dmips-mhz = <578>;
cpu-idle-states = <_off_l _off_l>;
@@ -38,6 +39,7 @@
compatible = "arm,cortex-a55";
reg = <0x100>;
enable-method = "psci";
+ performance-domains = < 0>;
clock-frequency = <170100>;
capacity-dmips-mhz = <578>;
cpu-idle-states = <_off_l _off_l>;
@@ -50,6 +52,7 @@
compatible = "arm,cortex-a55";
reg = <0x200>;
enable-method = "psci";
+ performance-domains = < 0>;
clock-frequency = <170100>;
capacity-dmips-mhz = <578>;
cpu-idle-states = <_off_l _off_l>;
@@ -62,6 +65,7 @@
compatible = "arm,cortex-a55";
reg = <0x300>;
enable-method = "psci";
+ performance-domains = < 0>;
clock-frequency = <170100>;
capacity-dmips-mhz = <578>;
cpu-idle-states = <_off_l _off_l>;
@@ -74,6 +78,7 @@
compatible = "arm,cortex-a78";
reg = <0x400>;
enable-method = "psci";
+ performance-domains = < 1>;
clock-frequency = <217100>;
capacity-dmips-mhz = <1024>;
cpu-idle-states = <_off_b _off_b>;
@@ -86,6 +91,7 @@
compatible = "arm,cortex-a78";
reg = <0x500>;
enable-method = "psci";
+ performance-domains = < 1>;
clock-frequency = <217100>;
capacity-dmips-mhz = <1024>;
cpu-idle-states = <_off_b _off_b>;
@@ -98,6 +104,7 @@
compatible = "arm,cortex-a78";
reg = <0x600>;
enable-method = "psci";
+ performance-domains = < 1>;
clock-frequency = <217100>;
capacity-dmips-mhz = <1024>;
cpu-idle-states = <_off_b _off_b>;
@@ -110,6 +117,7 @@
compatible = "arm,cortex-a78";
reg = <0x700>;
enable-method = "psci";
+ performance-domains = < 1>;
clock-frequency = <217100>;
capacity-dmips-mhz = <1024>;
cpu-idle-states = <_off_b _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 = <>;
--
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 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 = <
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 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 = <
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 = <_ao CLK_INFRA_AO_PMIC_AP>,
+<_ao CLK_INFRA_AO_PMIC_TMR>,
+< CLK_TOP_SPMI_M_MST>;
+ clock-names = "pmif_sys_ck",
+ "pmif_tmr_ck",
+ "spmimst_clk_mux";
+ assigned-clocks = < CLK_TOP_PWRAP_ULPOSC>;
+ assigned-clock-parents = <
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 = < 0 CMDQ_THR_PRIO_4>;
#clock-cells = <1>;
};
@@ -1976,6 +1977,114 @@
power-domains = < 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 = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DISP_OVL0>;
+ iommus = <_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
+ mediatek,gce-client-reg =
+< 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
Re: [PATCH v7 16/21] block: add check when merging zone device pages
On Thu, Jun 30, 2022 at 03:50:10PM -0600, Logan Gunthorpe wrote: > Oh, it turns out this code has nothing to do with REQ_NOMERGE. It's used > indirectly in bio_map_user_iov() and __bio_iov_iter_get_pages() when > adding pages to the bio via page_is_mergeable(). So it's not about > requests being merged it's about pages being merged. Oh, true. > So I'm not sure how we can avoid this, but it only happens when two > adjacent pages are added to the same bio in a row, so I don't think it's > that common, but the check can probably be moved down so it happens > after the same_page check to make it a little less common. Yes, looks like we have to keep it. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
