The device driver needs an API to get its aux-domain. A typical usage
scenario is:
unsigned long pasid;
struct iommu_domain *domain;
struct device *dev = mdev_dev(mdev);
struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
domain = iommu_aux_get_d
This series aims to extend the IOMMU aux-domain API set so that it
could be more friendly to vfio/mdev usage. The interactions between
vfio/mdev and iommu during mdev creation and passthr are:
1. Create a group for mdev with iommu_group_alloc();
2. Add the device to the group with
group =
Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
vfio_group data structure so that it could be reused in other places.
Signed-off-by: Lu Baolu
---
drivers/vfio/vfio_iommu_type1.c | 44 ++--
The iommu aux-domain api's work only when IOMMU_DEV_FEAT_AUX is enabled
for the device. Add this check to avoid misuse.
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iom
This adds two new aux-domain APIs for a use case like vfio/mdev where
sub-devices derived from an aux-domain capable device are created and
put in an iommu_group.
/**
* iommu_aux_attach_group - attach an aux-domain to an iommu_group which
* contains sub-devices (for exam
Hi Alex,
On Mon, 13 Jul 2020 16:48:42 -0600
Alex Williamson wrote:
> On Tue, 7 Jul 2020 16:43:45 -0700
> Jacob Pan wrote:
>
> > IOMMU UAPI is newly introduced to support communications between
> > guest virtual IOMMU and host IOMMU. There has been lots of
> > discussions on how it should work
On 2020-07-14 00:43, Jordan Crouse wrote:
On Mon, Jul 13, 2020 at 08:03:32PM +0100, Will Deacon wrote:
On Mon, Jul 13, 2020 at 11:00:32AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> > On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> From: Fenghua Yu
> Sent: Tuesday, July 14, 2020 7:48 AM
>
> From: Ashok Raj
>
> ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
> features
> are a complicated stack with lots of interconnected pieces.
> This documentation provides a big picture overview for all of the
> From: Fenghua Yu
> Sent: Tuesday, July 14, 2020 7:48 AM
>
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with uapi
> definitions, define PASID and its variations (e.g. max PASID) as "u32".
> "u32" is also shorter
The pull request you sent on Mon, 13 Jul 2020 17:36:54 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.8-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0dc589da873b58b70f4caf4b070fb0cf70fdd1dc
Thank you!
--
Deet-doot-
Hi Robin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git core
head: 97215a7df4351fdd9141418568be872fb1032d6e
commit: b4ceb4a5359ed1c9ba4a20acf3a70d4bbead3248 [18/19] iommu: Tidy up Kconfig
for SoC IOMMUs
config: xtensa-allyesconfi
20. 6. 19. 오후 7:36에 Marek Szyprowski 이(가) 쓴 글:
> Use common helper for checking the contiguity of the imported dma-buf.
>
> Signed-off-by: Marek Szyprowski
Acked-by : Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++
> 1 file changed, 3
20. 6. 19. 오후 7:36에 Marek Szyprowski 이(가) 쓴 글:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called w
On Fri, 19 Jun 2020 09:20:07 +0100, Lorenzo Pieralisi wrote:
> There is nothing PCI specific (other than the RID - requester ID)
> in the of_map_rid() implementation, so the same function can be
> reused for input/output IDs mapping for other busses just as well.
>
> Rename the RID instances/names
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the d
Hi, Thomas, Joerg, and other maintainers,
This series only has one change in patch 1 on top of v5 (see change log).
Could you please consider to merge it upstream?
Thanks.
-Fenghua
=
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Signed-o
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
- Change
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM devic
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua Y
From: Peter Zijlstra
The flag is defined for the task to identify if the task has a valid
PASID. Its initial value is 0 when the task is forked/cloned. It will
be used shortly.
Signed-off-by: Peter Zijlstra
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
---
v2:
- Add this patch to defi
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.
Decoding the user instruction is ugly and sets a bad architecture
pre
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
---
v5:
- Reviewed by Lu Baolu
v2:
- Add this
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in E
On Tue, 7 Jul 2020 16:43:45 -0700
Jacob Pan wrote:
> IOMMU UAPI is newly introduced to support communications between guest
> virtual IOMMU and host IOMMU. There has been lots of discussions on how
> it should work with VFIO UAPI and userspace in general.
>
> This document is indended to clarif
Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
DMA controllers, therefore document RZ/G2H specific bindings.
Signed-off-by: Lad Prabhakar
---
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetre
From: Marian-Cristian Rotariu
Add sys-dmac[0-2] device nodes for RZ/G2H (R8A774E1) SoC.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 126 ++
1 file changed, 126 insertions(+)
diff --git a/arch/arm64/b
Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
relevant dt-bindings.
Signed-off-by: Lad Prabhakar
---
Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpi
From: Marian-Cristian Rotariu
Document RZ/G2H (R8A774E1) SoC bindings.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/rene
From: Marian-Cristian Rotariu
Add RZ/G2H (R8A774E1) IPMMU nodes.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 121 ++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774e
Hi All,
This patch series adds device nodes for IPMMU, DMAC, GPIO
and AVB nodes for RZ/G2H (R8A774E1) SoC.
Cheers,
Prabhakar
Lad Prabhakar (3):
dt-bindings: iommu: renesas,ipmmu-vmsa: Add r8a774e1 support
dt-bindings: dma: renesas,rcar-dmac: Document R8A774E1 bindings
dt-bindings: gpio: re
Document RZ/G2H (R8A774E1) SoC bindings.
Signed-off-by: Lad Prabhakar
---
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
b/Documentation/devicetree/bindings/iommu
From: Marian-Cristian Rotariu
This patch adds the SoC specific part of the Ethernet AVB
device tree node.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 41 +--
1 file changed, 39 insertions(+), 2 deleti
From: Marian-Cristian Rotariu
Add GPIO device nodes to the DT of the r8a774e1 SoC.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 73 +--
1 file changed, 56 insertions(+), 17 deletions(-)
diff --git a/a
From: Marian-Cristian Rotariu
Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
drivers/iommu/ipmmu-vmsa.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index
On Fri, Jul 03, 2020 at 11:26:32AM +0200, Tomasz Nowicki wrote:
> On 03.07.2020 11:05, Robin Murphy wrote:
> > On 2020-07-02 21:16, Tomasz Nowicki wrote:
> > > Add specific compatible string for Marvell usage due to errata of
> > > accessing 64bits registers of ARM SMMU, in AP806.
> > >
> > > AP80
Hi Bjorn,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on arm-perf/for-next/perf v5.8-rc5 next-20200713]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as
Signed-off-by: kernel test robot
---
arm-smmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 2e27cf9815ab6..fb85e716ae9ac 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1924,7 +1924,7 @
On Mon, Jul 13, 2020 at 1:41 PM Will Deacon wrote:
>
> On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> > On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > > On Thu, Jul 09, 2020 at 08:28:45PM -0700, John Stultz wrote:
> > > > On Thu, Jul 2, 2020 at 7:18 AM Will Deacon wrote:
On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > On Thu, Jul 09, 2020 at 08:28:45PM -0700, John Stultz wrote:
> > > On Thu, Jul 2, 2020 at 7:18 AM Will Deacon wrote:
> > > > On Thu, Jun 25, 2020 at 12:10:39AM +, John Stultz
On Thu, Jun 18, 2020 at 05:51:20PM +0200, Jean-Philippe Brucker wrote:
> With Shared Virtual Addressing (SVA), we need to mirror CPU TTBR, TCR,
> MAIR and ASIDs in SMMU contexts. Each SMMU has a single ASID space split
> into two sets, shared and private. Shared ASIDs correspond to those
> obtained
On 13/07/2020 12:16, Joerg Roedel wrote:
From: Joerg Roedel
This fixes a compile error when cross-compiling the driver
on x86-32.
Signed-off-by: Joerg Roedel
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iomm
On Mon, Jul 13, 2020 at 08:03:32PM +0100, Will Deacon wrote:
> On Mon, Jul 13, 2020 at 11:00:32AM -0600, Jordan Crouse wrote:
> > On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> > > On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> > > > Add a new implementation hook t
On Mon, Jul 13, 2020 at 11:00:32AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> > On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> > > Add a new implementation hook to allow the implementation specific code
> > > to tweek the context b
On Tue, Jul 07, 2020 at 08:09:41AM -0700, Rob Clark wrote:
> On Tue, Jul 7, 2020 at 5:34 AM Robin Murphy wrote:
> >
> > On 2020-06-26 21:04, Jordan Crouse wrote:
> > > Support auxiliary domains for arm-smmu-v2 to initialize and support
> > > multiple pagetables for a single SMMU context bank. Sinc
On Mon, Jul 13, 2020 at 04:09:02PM +0100, Will Deacon wrote:
> On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> > Add a link to the pointer to the struct device that is attached to a
> > domain. This makes it easy to get the pointer if it is needed in the
> > implementation specific
On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> > Add a new implementation hook to allow the implementation specific code
> > to tweek the context bank configuration just before it gets written.
> > The first user will
On Thu, Jun 18, 2020 at 05:51:17PM +0200, Jean-Philippe Brucker wrote:
> To enable address space sharing with the IOMMU, introduce mm_context_get()
> and mm_context_put(), that pin down a context and ensure that it will keep
> its ASID after a rollover. Export the symbols to let the modular SMMUv3
Hi Linus,
The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:
Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.8-rc5
for you to fetch changes up to a0
On Mon, Jul 13, 2020 at 02:33:26PM +0100, Will Deacon wrote:
> I can't see this in Joerg's tree or in linux-next. Joerg: did you pick this
> one up? (I thought you did, but I can't find it!).
Yes, its in the tree and and will be pushed soon. I'll also send it to
Linus today.
Joerg
__
On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> Add a new implementation hook to allow the implementation specific code
> to tweek the context bank configuration just before it gets written.
> The first user will be the Adreno GPU implementation to turn on
> SCTLR.HUPCF to ensure t
On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> Add a link to the pointer to the struct device that is attached to a
> domain. This makes it easy to get the pointer if it is needed in the
> implementation specific code.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/iommu/a
The sparse tool complains as follows:
drivers/iommu/iommu.c:386:5: warning:
symbol 'iommu_insert_resv_region' was not declared. Should it be static?
drivers/iommu/iommu.c:2182:5: warning:
symbol '__iommu_map' was not declared. Should it be static?
Those functions are not used outside of iommu.c
On 2020-07-10 21:29, Krishna Reddy wrote:
Thanks Rob. One question on setting "minItems: ". Please see below.
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - nvidia,tegra194-smmu
+then:
+ properties:
+reg:
+
On 2020-07-08 06:00, Krishna Reddy wrote:
ioremap smmu mmio region before calling into implementation init.
This is necessary to allow mapped address available during vendor
specific implementation init.
Reviewed-by: Robin Murphy
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c |
On Tue, Jul 07, 2020 at 10:00:12PM -0700, Krishna Reddy wrote:
> Changes in v10:
> Perform SMMU base ioremap before calling implementation init.
> Check for Global faults across both ARM MMU-500s during global interrupt.
> Check for context faults across all contexts of both ARM MMU-500s during
>
On Tue, Jul 07, 2020 at 10:00:17PM -0700, Krishna Reddy wrote:
> Add global/context fault hooks to allow vendor specific implementations
> override default fault interrupt handlers.
>
> Update NVIDIA implementation to override the default global/context fault
> interrupt handlers and handle interr
On Mon, Jun 08, 2020 at 04:13:08PM +0100, Will Deacon wrote:
> On Thu, Jun 04, 2020 at 02:39:04PM -0600, Jordan Crouse wrote:
> > When CONFIG_OF=n of_match_device() gets pre-processed out of existence
> > leaving qcom-smmu_client_of_match unused. Mark it as possibly unused to
> > keep the compiler
On Sat, Jul 11, 2020 at 03:11:33PM +0800, Yong Wu wrote:
> The SMI part always go with the IOMMU, Could you also help apply the
> mt6779 SMI basical part [1][2]. Both has already got reviewed-by from
> Rob and Matthias. and the [3] in that patchset is for performance
> improvement, it's not so nece
On Sun, Jul 12, 2020 at 04:20:58AM -0700, Liu Yi L wrote:
> This patch is added as instead of returning a boolean for DOMAIN_ATTR_NESTING,
> iommu_domain_get_attr() should return an iommu_nesting_info handle.
>
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
>
On Wed, Jul 08, 2020 at 12:32:42PM +0100, Robin Murphy wrote:
> As for the intel-iommu implementation, relegate the opportunistic
> attempt to allocate a SAC address to the domain of conventional PCI
> devices only, to avoid it increasingly causing far more performance
> issues than possible benefi
On 2020-07-13 10:12, Claire Chang wrote:
The bounced DMA ops provide an implementation of DMA ops that bounce
streaming DMA in and out of a specially allocated region. Only the
operations relevant to streaming DMA are supported.
I think there are too many implicit assumptions here - apparently
On 2020-07-13 10:12, Claire Chang wrote:
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For e
From: Joerg Roedel
This fixes a compile error when cross-compiling the driver
on x86-32.
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 6ff62452bbf9..122925dbe547 100644
-
Introduce the new compatible string, bounced-dma-pool, for bounced DMA.
One can specify the address and length of the bounced memory region by
bounced-dma-pool in the device tree.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36 +++
1 file chang
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
The bounced DMA ops provide an implementation of DMA ops that bounce
streaming DMA in and out of a specially allocated region. Only the
operations relevant to streaming DMA are supported.
Signed-off-by: Claire Chang
---
include/linux/device.h | 3 +
include/linux/dma-mapping.h | 1 +
ke
Add the initialization function to create bounce buffer pools from
matching reserved-memory nodes in the device tree.
The bounce buffer pools provide a basic level of protection against
the DMA overwriting buffer contents at unexpected times. However, to
protect against general data leakage and sy
If a device is not behind an IOMMU, we look up the device node and set
up the bounced DMA when the bounced-dma property is presented. One can
specify two reserved-memory nodes in the device tree. One with
shared-dma-pool to handle the coherent DMA buffer allocation, and
another one with bounced-dma
On Sat, Jul 11, 2020 at 09:58:38PM -0500, Bjorn Helgaas wrote:
> If BIOS handed off with ATS enabled and we somehow relied on it being
> already enabled, something might break if we start disabling ATS.
> Just a theoretical possibility, doesn't seem likely to me.
I don't think this will be a probl
On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
>
> For multiple iommu_domains, we need to reserve some iova regions, so we
> will add mtk_iommu_iova_region structure. It includes the base address
> and size of the range.
> This is a preparing patch for supporting multi-domain.
>
> Signed-off-by: A
On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
>
> In the previous SoC, the M4U HW is in the EMI power domain which is
> always on. the latest M4U is in the display power domain which may be
> turned on/off, thus we have to add pm_runtime interface for it.
>
> we should enable its power before M4U
75 matches
Mail list logo
