On Fri, Jul 01, 2016 at 12:19:51PM +0100, Robin Murphy wrote:
> On 01/07/16 11:32, Marek Szyprowski wrote:
> > Frankly, I would avoid moving this workaround to the iommu core. IMHO the
> > best solution would be to let IOMMU controllers to be instantiated as
> > normal
> > devices and implement
Hi Robin,
On 2016-07-01 13:19, Robin Murphy wrote:
Hi Marek,
On 01/07/16 11:32, Marek Szyprowski wrote:
Hi Robin,
On 2016-06-28 17:48, Robin Murphy wrote:
So far, all the users of the generic of_xlate configuration mechanism
are resorting to explicit platform device creation to ensure the
Hi Marek,
On 01/07/16 11:32, Marek Szyprowski wrote:
> Hi Robin,
>
>
> On 2016-06-28 17:48, Robin Murphy wrote:
>> So far, all the users of the generic of_xlate configuration mechanism
>> are resorting to explicit platform device creation to ensure the IOMMU
>> device is ready before anything
Hi Robin,
On 2016-06-28 17:48, Robin Murphy wrote:
So far, all the users of the generic of_xlate configuration mechanism
are resorting to explicit platform device creation to ensure the IOMMU
device is ready before anything tries to refer to it. As I'm about to
convert two more drivers that
On Tue, Jun 28, 2016 at 04:48:21PM +0100, Robin Murphy wrote:
> So far, all the users of the generic of_xlate configuration mechanism
> are resorting to explicit platform device creation to ensure the IOMMU
> device is ready before anything tries to refer to it. As I'm about to
> convert two more
So far, all the users of the generic of_xlate configuration mechanism
are resorting to explicit platform device creation to ensure the IOMMU
device is ready before anything tries to refer to it. As I'm about to
convert two more drivers that will need exactly the same thing, let's
nip that