[EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller

[Frank Li]

> -----Original Message-----
> From: Marc Zyngier <maz at kernel.org>
> Sent: Friday, July 22, 2022 2:33 AM
> To: Frank Li <frank.li at nxp.com>
> Cc: jdmason at kudzu.us; tglx at linutronix.de; robh+dt at kernel.org;
> krzysztof.kozlowski+dt at linaro.org; shawnguo at kernel.org;
> s.hauer at pengutronix.de; kw at linux.com; bhelgaas at google.com;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> pci at vger.kernel.org; Peng Fan <peng.fan at nxp.com>; Aisheng Dong
> <aisheng.dong at nxp.com>; kernel at pengutronix.de; festevam at gmail.com;
> dl-linux-imx <linux-imx at nxp.com>; kishon at ti.com;
> lorenzo.pieralisi at arm.com; ntb at lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi
> controller
> 
> Caution: EXT Email
> 
> On Thu, 21 Jul 2022 16:22:08 +0100,
> Frank Li <frank.li at nxp.com> wrote:
> >
> > > > +     pos = find_first_zero_bit(&msi_data->used, IMX_MU_CHANS);
> > > > +     if (pos < IMX_MU_CHANS)
> > > > +             __set_bit(pos, &msi_data->used);
> > > > +     else
> > > > +             err = -ENOSPC;
> > > > +     spin_unlock(&msi_data->lock);
> > > > +
> > > > +     if (err)
> > > > +             return err;
> > > > +
> > > > +     err = iommu_dma_prepare_msi(info->desc, msi_data->msiir_addr
> +
> > > pos * 4);
> > >
> > > Does this HW even have an IOMMU?
> >
> > [Frank Li] we have a platform with iommu.
> 
> I really wonder whether you are taking me for a ride, or whether you
> are completely misunderstanding what this IOMMU business is about.
> 
> This is a *CPU* writing to the device to generate an MSI. CPU
> transactions cannot be translated by an IOMMU as they are not
> (surprise!) IO devices. They are in control of their own translation,
> contrary to devices that generate MSIs.

[Frank Li] I think that It is not *CPU* writing to the device to generate an MSI. 
It is another bus master to write to generate IRQ.  According to my understand, 
Bus master (such as PCI EP devices) write to an address to trigger irq, OR
DMA setup DMA write descriptor at last one.  Any address should be translate by
IOMMU if it is enabled.  If not,  this is empty function call.  

> 
> So what sort of translation do you expect this to setup? What StreamID
> is getting used by the DMA framework? There is no answer to these
> questions because they don't make any sense. None of it makes any
> sense.
> 
> At best, you are simply copy-pasting things from various drivers
> without understanding what they are all about.
 
[Frank Li] it is first time to write irq chip driver, so I have to base on or reference
Other drivers to start development.  Of course, there are some miss understand
During development.  From functional call name, it make sense although I don't know
All detail behind that.  

Any bus master access memory need go through IOMMU if enabled.  

I have not tested it at IOMMU enabled platform yet.  Some maintainer require
Added similar function call if a feature enabled when I do other upstream work.  
So I kept as refer driver did. Maybe refer driver code is too old.  

If there are problem, I can delete it.  So far, it don't impact my test platform. 
I can add fix patch if met problem at IOMMU enabled platform.

> I suggest you stop
> doing that and make use of your time working out the problem rather
> than wasting the reviewers'.

Thank you for your review and great comments.  This driver function worked. 
I know I made some stupid problem, it should be fixed before sent out.

I also want to make sure the overall idea worked firstly.  So far no-one
Use MSI as doorbell from PCIe-EP function drivers yet.  

> 
>         M.
> 
> --
> Without deviation from the norm, progress is not possible.