On Tue, Aug 23, 2016 at 08:05:11PM +0100, Robin Murphy wrote:
> At long last I've finished the big SMMUv2 rework, so here's everything
> all together for a v5. As a quick breakdown:
>
> Patches 1-3 are the core PCI part, all acked and ready to go. No code
> changes from v4.
>
> Patch 4 is merely
On Tue, Aug 23, 2016 at 08:05:28PM +0100, Robin Murphy wrote:
> With everything else now in place, fill in an of_xlate callback and the
> appropriate registration to plumb into the generic configuration
> machinery, and watch everything just work.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/
On 01/09/16 19:42, Will Deacon wrote:
> On Tue, Aug 23, 2016 at 08:05:21PM +0100, Robin Murphy wrote:
>> Making S2CRs first-class citizens within the driver with a high-level
>> representation of their state offers a neat solution to a few problems:
>>
>> Firstly, the information about which contex
On Thu, Sep 01, 2016 at 07:45:51PM +0100, Robin Murphy wrote:
> On 01/09/16 19:32, Will Deacon wrote:
> > On Tue, Aug 23, 2016 at 08:05:20PM +0100, Robin Murphy wrote:
> >> - while (--i >= 0)
> >> - __arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
> >> - kfree(smrs);
> >> + while (i-
On Tue, Aug 23, 2016 at 08:05:26PM +0100, Robin Murphy wrote:
> In the final step of preparation for full generic configuration support,
> swap our fixed-size master_cfg for the generic iommu_fwspec. For the
> legacy DT bindings, the driver simply gets to act as its own 'firmware'.
> Farewell, arbi
On Tue, Aug 23, 2016 at 08:05:22PM +0100, Robin Murphy wrote:
> To be able to support the generic bindings and handle of_xlate() calls,
> we need to be able to associate SMMUs and stream IDs directly with
> devices *before* allocating IOMMU groups. Furthermore, to support real
> default domains wit
On 01/09/16 19:32, Will Deacon wrote:
> On Tue, Aug 23, 2016 at 08:05:20PM +0100, Robin Murphy wrote:
>> In order to consider SMR masking, we really want to be able to validate
>> ID/mask pairs against existing SMR contents to prevent stream match
>> conflicts, which at best would cause transaction
On Tue, Aug 23, 2016 at 08:05:21PM +0100, Robin Murphy wrote:
> Making S2CRs first-class citizens within the driver with a high-level
> representation of their state offers a neat solution to a few problems:
>
> Firstly, the information about which context a device's stream IDs are
> associated wi
On Tue, Aug 23, 2016 at 08:05:20PM +0100, Robin Murphy wrote:
> In order to consider SMR masking, we really want to be able to validate
> ID/mask pairs against existing SMR contents to prevent stream match
> conflicts, which at best would cause transactions to fault unexpectedly,
> and at worst lea
On Tue, Aug 23, 2016 at 08:05:19PM +0100, Robin Murphy wrote:
> Rather than assuming fixed worst-case values for stream IDs and SMR
> masks, keep track of whatever implemented bits the hardware actually
> reports. This also obviates the slightly questionable validation of SMR
> fields in isolation
On 01/09/16 16:17, Lorenzo Pieralisi wrote:
[...]
>> +static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
>> {
>> struct arm_smmu_smr *smrs = smmu->smrs;
>> -int i, idx;
>> +int i, idx = -ENOSPC;
>>
>> -/* Allocate the SMRs on the SMMU */
>> -for_eac
On 01/09/16 18:06, Will Deacon wrote:
> Hi Robin,
>
> On Tue, Aug 23, 2016 at 08:05:16PM +0100, Robin Murphy wrote:
>> Now that we can properly describe the mapping between PCI RIDs and
>> stream IDs via "iommu-map", and have it fed it to the driver
>> automatically via of_xlate(), rework the SMMU
On Tue, Aug 23, 2016 at 08:05:18PM +0100, Robin Murphy wrote:
> Implement the SMMUv3 equivalent of d346180e70b9 ("iommu/arm-smmu: Treat
> all device transactions as unprivileged"), so that once again those
> pesky DMA controllers with their privileged instruction fetches don't
> unexpectedly fault
On Tue, Aug 23, 2016 at 08:05:17PM +0100, Robin Murphy wrote:
> With the device <-> stream ID relationship suitably abstracted and
> of_xlate() hooked up, the PCI dependency now looks, and is, entirely
> arbitrary. Any bus using the of_dma_configure() mechanism will work,
> so extend support to the
Hi Robin,
On Tue, Aug 23, 2016 at 08:05:16PM +0100, Robin Murphy wrote:
> Now that we can properly describe the mapping between PCI RIDs and
> stream IDs via "iommu-map", and have it fed it to the driver
> automatically via of_xlate(), rework the SMMUv3 driver to benefit from
> that, and get rid o
On Tue, Aug 23, 2016 at 08:05:11PM +0100, Robin Murphy wrote:
> Hi all,
>
> At long last I've finished the big SMMUv2 rework, so here's everything
> all together for a v5. As a quick breakdown:
>
> Patches 1-3 are the core PCI part, all acked and ready to go. No code
> changes from v4.
>
> Patch
On Tue, Aug 23, 2016 at 08:05:25PM +0100, Robin Murphy wrote:
> Stream Match Registers are one of the more awkward parts of the SMMUv2
> architecture; there are typically never enough to assign one to each
> stream ID in the system, and configuring them such that a single ID
> matches multiple entr
On 01/09/16 13:31, Will Deacon wrote:
> On Thu, Sep 01, 2016 at 01:07:19PM +0100, Robin Murphy wrote:
>> On 31/08/16 18:28, Will Deacon wrote:
>>> On Tue, Aug 23, 2016 at 08:05:15PM +0100, Robin Murphy wrote:
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+
On Thu, Sep 01, 2016 at 01:07:19PM +0100, Robin Murphy wrote:
> On 31/08/16 18:28, Will Deacon wrote:
> > On Tue, Aug 23, 2016 at 08:05:15PM +0100, Robin Murphy wrote:
> >> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> >> +{
> >> + struct iommu_fwspec *fwspec = dev->archda
On 31/08/16 18:28, Will Deacon wrote:
> On Tue, Aug 23, 2016 at 08:05:15PM +0100, Robin Murphy wrote:
>> Introduce a common structure to hold the per-device firmware data that
>> non-architectural IOMMU drivers generally need to keep track of.
>> Initially this is DT-specific to complement the exis
On 01/09/16 04:49, Anup Patel wrote:
> Hi Robin,
>
> What are the chances of having this series in Linux-4.9?
Well, I'm planning to do everything I can over the next few weeks to
make that happen, but ultimately it's down to maintainers, not me ;)
I'll certainly be posting a v6 next week to addr
21 matches
Mail list logo
