On Wed, Oct 11, 2017 at 01:26:10PM +0800, Hanjun Guo wrote: > On 2017/10/10 17:20, Lorenzo Pieralisi wrote: > > On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote: > >> Hi Lorenzo, > >> > >> Sorry for the late reply, holidays in China for the past week. > >> > >> At 2017/9/27 21:54, Lorenzo Pieralisi wrote: > >>> Hi Hanjun, > >>> > >>> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote: > >>>> IORT revision C introduced SMMUv3 MSI support which adding a > >>>> device ID mapping index in SMMUv3 sub table, to get the SMMUv3 > >>>> device ID mapping for the output ID (dev ID for ITS) and the > >>>> link to which ITS. > >>>> > >>>> So if a platform supports SMMUv3 MSI for control interrupt, > >>>> there will be a additional single map entry under SMMU, this > >>>> will not introduce any difference for devices just use one > >>>> step map to get its output ID and parent (ITS or SMMU), such > >>>> as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to > >>>> do the special handling for two steps map case such as > >>>> PCI/NC--->SMMUv3--->ITS. > >>>> > >>>> Take a PCI hostbridge for example, > >>>> > >>>> |----------------------| > >>>> | Root Complex Node | > >>>> |----------------------| > >>>> | map entry[x] | > >>>> |----------------------| > >>>> | id value | > >>>> | output_reference | > >>>> |---|------------------| > >>>> | > >>>> | |----------------------| > >>>> |-->| SMMUv3 | > >>>> |----------------------| > >>>> | SMMU dev ID | > >>>> | mapping index 0 | > >>>> |----------------------| > >>>> | map entry[0] | > >>>> |----------------------| > >>>> | id value | > >>>> | output_reference-----------> ITS 1 (SMMU MSI domain) > >>>> |----------------------| > >>>> | map entry[1] | > >>>> |----------------------| > >>>> | id value | > >>>> | output_reference-----------> ITS 2 (PCI MSI domain) > >>>> |----------------------| > >>>> > >>>> When the SMMU dev ID mapping index is 0, there is entry[0] > >>>> to map to a ITS, we need to skip that map entry for PCI > >>>> or NC (named component), or we may get the wrong ITS parent. > >>> Is this actually true ? I think that currently we would simply skip > >>> the entry and print an error log but we can't get a wrong ITS parent. > >> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id > >> mapping, we need to fix the IORT spec as well. > >> > >>> I am rewriting this commit (I will probably split it), it is doing the > >>> right thing but the commit log is stale (probably caused by code > >>> reshuffling). > >> Do I need to resend another version, or you can help to update it? > >> please let me know. > > I reworked the patches, you can repost/retest them I made them available > > in the branch below, we will have to add a guard around ACPICA smmu > > struct (unfortunately I think we will have to use the ACPICA version as > > a guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI > > tree (and your patch made it into the release - I will check ACPICA > > upstream). > > Bob already merged my pull request yesterday, I think it will be ready for > acpica release for this month. That's good, mind updating the patch series with an ACPICA guard in IORT code in preparation for the pull request ? > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iort/smmu-msi-for-4.15 > > > > Thanks! I will retest then repost. Thank you, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
