On Fri, May 08, 2015 at 08:30:00PM +0100, Stuart Yoder wrote: > On Fri, May 8, 2015 at 10:49 AM, Will Deacon <will.deacon@xxxxxxx> wrote: > > On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote: > >> The FSL LS2085A SoC has an actual RID->SID mapping table in the PCI > >> controller, but it is not static in the sense of fixed in hardware or > >> firmware. It's > >> a programmable mapping table, and we envision Linux programming this table. > > > > Ok, so I assume you're not planning to use ACPI with this system? > > Not initially, but perhaps in the future. I guess I don't know the implications > to ACPI yet. Well, I suggest you take a look at the IORT spec[1] asap, because I don't think it can describe your system if you want to go in the direction of dynamic mappings. > > Also, we can't just program this table willy-nilly, as I'm sure you're > > aware. For example, updating a the SMRs in a live SMMU is a big no-no, > > so although Linux may initialise the table, it can only be safely changed > > at device init/teardown time, surely? > > Correct. That would not be updated when a device is live. Ok, so the best way for Linux is probably to abstract this in the bus code and have that allocate the IDs when a device is `hotplugged' on. This would also fit well with consolidating the group creation for platform and PCI devices. Will [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
