> > The present value shows the existing type of default domain.
> > If user wants to change it (Eg: from DMA to IDENTITY or vice versa), he
> attempts to write the new value.
> > Kernel performs checks to make sure that the driver in unbinded and it's
> > safe
> to change the default domain
When user requests kernel to change the default domain type of a group
through sysfs, kernel has to make sure if it's ok to change the domain type
of every device in the group to the requested domain (every device may not
support both the domain types i.e. DMA and identity). Hence, add a call
back
Presently, the default domain of a group is allocated during boot time and it
cannot be changed later. So, the device would typically be either in
identity/pass through mode or the device would be in DMA mode as long as the
system is up and running. There is no way to change the default domain
Presently, the default domain of a group is allocated during boot time
(i.e. when a device is being added to a group) and it cannot be changed
later. So, the device would typically be either in identity/pass_through
mode (controlled by "iommu=pt" kernel command line argument) or the device
would
The default domain type of an iommu group can be changed using file
"/sys/kernel/iommu_groups//type". Hence, document it's usage and
more importantly spell out it's limitations and an example.
Cc: Christoph Hellwig
Cc: Joerg Roedel
Cc: Ashok Raj
Cc: Will Deacon
Cc: Lu Baolu
Cc: Sohil Mehta
device_def_domain_type() determines the domain type a device could have and
it's called only during boot. But, to change the domain of a group through
sysfs, kernel has to call this function during runtime. Hence, add an
argument to the function which lets the function know if it's being called
at
On Tue, Jul 02, 2019 at 11:40:02AM +0100, Robin Murphy wrote:
> On reflection, I don't really think that size_t fits here anyway, since
> all the members of the incoming struct scatterlist are unsigned int too.
> Does the patch below work?
Yes.
> ->8-
> From: Robin Murphy
> Subject:
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 4 insertions(+)
diff --git
From: Rob Clark
Avoid attaching any non-driver managed domain if the driver indicates
that it manages the iommu directly.
This solves a couple problems that drm/msm + arm-smmu has with the iommu
framework:
1) In some cases the bootloader takes the iommu out of bypass and
enables the
From: Rob Clark
One of the challenges we need to handle to enable the aarch64 laptops
upstream is dealing with the fact that the bootloader enables the
display and takes the corresponding SMMU context-bank out of BYPASS.
Unfortunately, currently, the IOMMU framework attaches a DMA (or
On 07/06/2019 20:35, Andrew F. Davis wrote:
Hello all,
So I've got a new IP on our new SoC I'm looking to make use of and would
like some help figuring out what framework best matches its function. The
IP is called a "Page-based Address Translator" or PAT. A PAT instance
(there are 5 of these
On 7/1/2019 10:48 AM, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
but it turns out that because we didn't filter valid gfp_t flags
on the DMA allocator, a bunch of drivers
On 01/07/2019 18:41, Robin Murphy wrote:
> Hi Jean-Philippe,
>
> I realise it's a bit late for a "review", but digging up the original
> patch seemed as good a place as any to raise this...
>
> On 17/04/2019 19:24, Jean-Philippe Brucker wrote:
> [...]
>> @@ -1740,6 +1906,9 @@ static void
On 01/07/2019 22:50, Nicolin Chen wrote:
> Hi Robin,
>
> On Mon, Jul 01, 2019 at 01:39:55PM +0100, Robin Murphy wrote:
The max_len is a u32 type variable so the calculation on the
left hand of the last if-condition will potentially overflow
when a cur_len gets closer to UINT_MAX --
14 matches
Mail list logo
