There is a spelling mistake in a comment, fix it.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a61587..8e4e8fea10
There are several spelling mistakes, as follows:
guarentees ==> guarantees
resgister ==> register
insufficent ==> insufficient
creats ==> creates
tabke ==> take
Signed-off-by: Zhen Lei
---
drivers/iommu/intel/dmar.c | 6 +++---
drivers/iommu/intel/iommu.c | 2 +-
drivers/iommu/i
There are several spelling mistakes, as follows:
alignement ==> alignment
programing ==> programming
implemtation ==> implementation
assignement ==> assignment
By the way, both "programing" and "programming" are acceptable, but the
latter seems more formal.
Signed-off-by: Zhen Lei
---
drivers/i
There is a spelling mistake in a comment, fix it.
Signed-off-by: Zhen Lei
---
drivers/iommu/omap-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 71f29c0927fc710..b2a6ab700ec43d1 100644
--- a/drivers/iommu/o
There is a spelling mistake in a comment, fix it.
Signed-off-by: Zhen Lei
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd52e..c8c9bf1d70b29dc 100644
--- a/drivers/iommu/mtk_
There is a spelling mistake in a comment, fix it.
Signed-off-by: Zhen Lei
---
drivers/iommu/sun50i-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index ea6db1341916524..7685b96b2d445a7 100644
--- a/drivers/i
There are several spelling mistakes, as follows:
funcions ==> functions
distiguish ==> distinguish
detroyed ==> destroyed
Signed-off-by: Zhen Lei
---
drivers/iommu/iommu.c | 4 ++--
drivers/iommu/iova.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c
There are several spelling mistakes, as follows:
Returs ==> Returns
defaul ==> default
assocaited ==> associated
Signed-off-by: Zhen Lei
---
drivers/iommu/fsl_pamu.c| 2 +-
drivers/iommu/fsl_pamu_domain.c | 2 +-
drivers/iommu/fsl_pamu_domain.h | 2 +-
3 files changed, 3 insertions(+),
This detection and correction covers the entire driver/iommu directory.
Zhen Lei (8):
iommu/pamu: fix a couple of spelling mistakes
iommu/omap: Fix spelling mistake "alignement" -> "alignment"
iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical"
iommu/sun50i: Fix spelling mistake
The IOMMU in many SoC depends on the MM clocks and power-domain which
are device_initcall normally, thus the subsys_init here is not helpful.
This patch switches it to module_platform_driver which also allow the
driver built as module.
Correspondingly switch the config to tristate, and update the
This patch only adds support for building the IOMMU-v1 driver as module.
Correspondingly switch the config to tristate and update the iommu_ops's
owner to THIS_MODULE.
Signed-off-by: Yong Wu
---
v2: change note:
a) Update iommu_ops's owner to THIS_MODULE
b) Fix typo in the title from "All
Hi Thomas/Marc,
On 3/25/2021 12:07 PM, Thomas Gleixner wrote:
On Thu, Mar 25 2021 at 17:43, Marc Zyngier wrote:
On Fri, 26 Feb 2021 20:11:16 +,
Megha Dey wrote:
+
+#include
+
+#ifdef CONFIG_IMS_MSI_ARRAY
Given that this covers the whole driver, what is this #defined used
for? You might
Hi Marc,
On 3/25/2021 10:53 AM, Marc Zyngier wrote:
On Fri, 26 Feb 2021 20:11:17 +,
Megha Dey wrote:
From: Dave Jiang
Add new helpers to get the Linux IRQ number and device specific index
for given device-relative vector so that the drivers don't need to
allocate their own arrays to keep
On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote:
> On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
>
> I'm probably just confused or maybe the documentation is outdated but I don't
> see how I could specify "this device can only use DMA addresses from
> 0x0010...0x3ff0 but can map thes
On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
> On 2021-03-25 07:53, Sven Peter wrote:
> >
> >
> > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> >> On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> >>>
> >>> As I mentioned before, not all DARTs support the full 32-b
Hi Robin,
Thanks for the review!
On Wed, Mar 24, 2021, at 17:37, Robin Murphy wrote:
> On 2021-03-20 15:19, Sven Peter wrote:
> > Apple's DART iommu uses a pagetable format that's very similar to the ones
> > already implemented by io-pgtable.c.
> > Add a new format variant to support the require
On Thu, Mar 25 2021 at 17:43, Marc Zyngier wrote:
> On Fri, 26 Feb 2021 20:11:16 +,
> Megha Dey wrote:
>> +
>> +#include
>> +
>> +#ifdef CONFIG_IMS_MSI_ARRAY
>
> Given that this covers the whole driver, what is this #defined used
> for? You might as well make the driver depend on this config
On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote:
>> +/**
>> + * irq_set_auxdata - Set auxiliary data
>> + * @irq:Interrupt to update
>> + * @which: Selector which data to update
>> + * @auxval: Auxiliary data value
>> + *
>> + * Function to update auxiliary data for an interrupt, e.g. to upda
On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote:
> Megha Dey wrote:
>> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
>> struct device *dev,
>> if (ret)
>> return ret;
>>
>> +if (ops->msi_alloc_store) {
>> +ret = ops->msi_alloc_sto
Hi Jason,
On Thu, 25 Mar 2021 14:16:45 -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> > wrote:
> >
> > > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan
On Wed, 24 Mar 2021 16:16:03 +0800, Zhen Lei wrote:
> In arm_smmu_gerror_handler(), the value of the SMMU_GERROR register is
> filtered by GERROR_ERR_MASK. However, the GERROR_ERR_MASK does not contain
> the SFM bit. As a result, the subsequent error processing is not performed
> when only the SFM
On Mon, 15 Mar 2021 11:32:24 +0530, Rajendra Nayak wrote:
> Add the SoC specific compatible for SC7280 implementing
> arm,mmu-500.
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] dt-bindings: arm-smmu: Add compatible for SC7280 SoC
https://git.kernel.org/will/c/a9aa2bb18ecb
Che
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote:
> The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
> offlined.
>
> Let's move it to core code, so everyone can take advantage.
>
> Also throw in a patch to stop exporting free_iova_fast().
>
> Differences to v1
On Fri, 26 Feb 2021 20:11:17 +,
Megha Dey wrote:
>
> From: Dave Jiang
>
> Add new helpers to get the Linux IRQ number and device specific index
> for given device-relative vector so that the drivers don't need to
> allocate their own arrays to keep track of the vectors and hwirq for
> the m
On Tue, Mar 02, 2021 at 10:26:43AM +0100, Jean-Philippe Brucker wrote:
> When handling faults from the event or PRI queue, we need to find the
> struct device associated with a SID. Add a rb_tree to keep track of
> SIDs.
>
> Acked-by: Jonathan Cameron
> Reviewed-by: Eric Auger
> Signed-off-by: J
On Fri, 26 Feb 2021 20:11:16 +,
Megha Dey wrote:
>
> Generic IMS(Interrupt Message Store) irq chips and irq domain
> implementations for IMS based devices which store the interrupt messages
> in an array in device memory.
>
> Allocation and freeing of interrupts happens via the generic
> msi
^^Nit: presumably you meant "Allow" in the subject.
On 2021-03-25 17:16, Will Deacon wrote:
On Tue, Mar 23, 2021 at 01:58:00PM +0800, Yong Wu wrote:
This patch only adds support for building the IOMMU-v1 driver as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
-
On Tue, Mar 02, 2021 at 10:26:37AM +0100, Jean-Philippe Brucker wrote:
> Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
> dev_iommu") removed iommu_priv from fwspec and commit 5702ee24182f
> ("ACPI/IORT: Check ATS capability in root complex nodes") added @flags.
> Update the struct
On Tue, Mar 02, 2021 at 10:26:38AM +0100, Jean-Philippe Brucker wrote:
> The pasid-num-bits property shouldn't need a dedicated fwspec field,
> it's a job for device properties. Add properties for IORT, and access
> the number of PASID bits using device_property_read_u32().
>
> Suggested-by: Robin
On Tue, Mar 09, 2021 at 12:10:44PM +0530, Sai Prakash Ranjan wrote:
> On 2021-02-05 17:38, Sai Prakash Ranjan wrote:
> > On 2021-02-04 03:16, Will Deacon wrote:
> > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > > > On 2021-02-01 23:50, Jordan Crouse wrote:
> > > > > On M
On Fri, 26 Feb 2021 20:11:12 +,
Megha Dey wrote:
>
> Introduce a new function pointer in the irq_chip structure(irq_set_auxdata)
> which is responsible for updating data which is stored in a shared register
> or data storage. For example, the idxd driver uses the auxiliary data API
> to enabl
On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> wrote:
>
> > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe
On Tue, Mar 23, 2021 at 01:58:00PM +0800, Yong Wu wrote:
> This patch only adds support for building the IOMMU-v1 driver as module.
> Correspondingly switch the config to tristate.
>
> Signed-off-by: Yong Wu
> ---
> rebase on v5.12-rc2.
> ---
> drivers/iommu/Kconfig| 2 +-
> drivers/iomm
On Fri, Mar 19, 2021 at 12:52:02PM +, Robin Murphy wrote:
> Rather than have separate opaque setter functions that are easy to
> overlook and lead to repetitive boilerplate in drivers, let's pass the
> relevant initialisation parameters directly to iommu_device_register().
>
> Signed-off-by: R
On Fri, Mar 19, 2021 at 12:52:01PM +, Robin Murphy wrote:
> It happens that the 3 drivers which first supported being modular are
> also ones which play games with their pgsize_bitmap, so have non-const
> iommu_ops where dynamically setting the owner manages to work out OK.
> However, it's less
On Fri, 26 Feb 2021 20:11:11 +,
Megha Dey wrote:
>
> From: Thomas Gleixner
>
> For devices which don't have a standard storage for MSI messages like the
> upcoming IMS (Interrupt Message Store) it's required to allocate storage
> space before allocating interrupts and after freeing them.
>
Hi Jean-Philippe,
On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
wrote:
> On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe
> > wrote:
> > > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
25.03.2021 18:52, Thierry Reding пишет:
> On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote:
>> 25.03.2021 16:03, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> From Tegra20 through Tegra210, either the GART or SMMU drivers need
>>> access to the internals of the memory contr
> -Original Message-
> From: Jon Nettleton [mailto:j...@solid-run.com]
> Sent: 25 March 2021 08:40
> To: Shameerali Kolothum Thodi
> Cc: erik.kan...@intel.com; linux-arm-ker...@lists.infradead.org;
> linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org;
> de...@acpica.org; Lorenz
On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote:
> 25.03.2021 16:03, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > From Tegra20 through Tegra210, either the GART or SMMU drivers need
> > access to the internals of the memory controller driver because they are
> > tightly
25.03.2021 16:03, Thierry Reding пишет:
> From: Thierry Reding
>
> From Tegra20 through Tegra210, either the GART or SMMU drivers need
> access to the internals of the memory controller driver because they are
> tightly coupled (in fact, the GART and SMMU are part of the memory
> controller). On
On Thu, Mar 25, 2021 at 01:10:12PM +0530, Sai Prakash Ranjan wrote:
> On 2021-03-15 00:31, Sai Prakash Ranjan wrote:
> > On 2021-03-12 04:59, Bjorn Andersson wrote:
> > > On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote:
> > > > On 2021-02-27 00:44, Bjorn Andersson wrote:
> > > > > On Fri 26
On Thu, Mar 25, 2021 at 02:27:10PM +, Robin Murphy wrote:
> On 2021-03-25 13:03, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Instead of programming all SID overrides during early boot, perform the
> > operation on-demand after the SMMU translations have been set up for a
> > device
On Thu, Feb 25, 2021 at 02:14:54PM +0800, Lu Baolu wrote:
> The lazy IOTLB flushing setup leaves a time window, in which the device
> can still access some system memory, which has already been unmapped by
> the device driver. It's not suitable for untrusted devices. A malicious
> device might use
On 2021-03-25 13:03, Thierry Reding wrote:
From: Thierry Reding
Tegra186 requires the same SID override programming as Tegra194 in order
to seamlessly transition from the firmware framebuffer to the Linux
framebuffer, so the Tegra implementation needs to be used on Tegra186
devices as well.
Si
On 2021-03-25 13:03, Thierry Reding wrote:
From: Thierry Reding
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding
---
drivers/iommu/arm/arm-smm
On 2021-03-25 13:03, Thierry Reding wrote:
From: Thierry Reding
Parse the reg property in device tree and detect the number of instances
represented by a device tree node. This is subsequently needed in order
to support single-instance SMMUs with the Tegra implementation because
additional prog
On 2021-03-25 13:03, Thierry Reding wrote:
From: Thierry Reding
Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and progr
Joerg,
On 3/18/21 10:31 PM, Joerg Roedel wrote:
On Fri, Mar 12, 2021 at 03:04:09AM -0600, Suravee Suthikulpanit wrote:
@@ -519,6 +521,7 @@ struct protection_domain {
spinlock_t lock;/* mostly used to lock the page table*/
u16 id; /* the domain id written
From: Thierry Reding
The secure firmware keeps some SID override registers set as passthrough
in order to allow devices such as the display controller to operate with
no knowledge of SMMU translations until an operating system driver takes
over. This is needed in order to seamlessly transition fr
From: Thierry Reding
Parse the reg property in device tree and detect the number of instances
represented by a device tree node. This is subsequently needed in order
to support single-instance SMMUs with the Tegra implementation because
additional programming is needed to properly configure the S
From: Thierry Reding
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
drivers/i
From: Thierry Reding
The memory client IDs will subsequently be used to program override SIDs
for the given clients depending on the device tree configuration.
Signed-off-by: Thierry Reding
---
drivers/memory/tegra/tegra186.c | 206
1 file changed, 206 insertio
From: Thierry Reding
Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and programs the SID specified in device tree, which c
From: Thierry Reding
Add the device tree node for the dual-SMMU found on Tegra194 and hook up
peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86
1 file changed, 86 insertions(+)
From: Thierry Reding
On Tegra186 and later, the memory controller needs to be programmed in
coordination with any of the ARM SMMU instances to configure the stream
ID used for each memory client.
To support this, add a phandle reference to the memory controller to the
SMMU device tree node.
Sig
From: Thierry Reding
Tegra186 requires the same SID override programming as Tegra194 in order
to seamlessly transition from the firmware framebuffer to the Linux
framebuffer, so the Tegra implementation needs to be used on Tegra186
devices as well.
Signed-off-by: Thierry Reding
---
drivers/iom
From: Thierry Reding
>From Tegra20 through Tegra210, either the GART or SMMU drivers need
access to the internals of the memory controller driver because they are
tightly coupled (in fact, the GART and SMMU are part of the memory
controller). On later chips, a separate hardware block implements t
From: Thierry Reding
Hi,
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappi
On 2021-03-25 12:30, John Garry wrote:
Function free_iova_fast() is only referenced by dma-iommu.c, which can
only be in-built, so stop exporting it.
This was missed in an earlier tidy-up patch.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 1 -
1 file c
On 2021-03-25 12:30, John Garry wrote:
Function iommu_dma_free_cpu_cached_iovas() no longer has any caller, so
delete it.
With that, function free_cpu_cached_iovas() may be made static.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 9 -
driv
The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
offlined.
Let's move it to core code, so everyone can take advantage.
Also throw in a patch to stop exporting free_iova_fast().
Differences to v1:
- Add RB tags (thanks!)
- Add patch to stop exporting free_iova_fast()
- D
Like the Intel IOMMU driver already does, flush the per-IOVA domain
CPU rcache when a CPU goes offline - there's no point in keeping it.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 30 +-
include/linux/cpuhotplug.h | 1 +
inc
Function iommu_dma_free_cpu_cached_iovas() no longer has any caller, so
delete it.
With that, function free_cpu_cached_iovas() may be made static.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 9 -
drivers/iommu/iova.c | 3 ++-
include/linux/dma-iommu.h | 8
in
Now that the core code handles flushing per-IOVA domain CPU rcaches,
remove the handling here.
Reviewed-by: Lu Baolu
Signed-off-by: John Garry
---
drivers/iommu/intel/iommu.c | 31 ---
include/linux/cpuhotplug.h | 1 -
2 files changed, 32 deletions(-)
diff --git a
Function free_iova_fast() is only referenced by dma-iommu.c, which can
only be in-built, so stop exporting it.
This was missed in an earlier tidy-up patch.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/
On 2021-03-25 07:53, Sven Peter wrote:
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
Date: Sat, 20 Mar 2021 15:19:33 +
From: Sven Peter
I have just noticed today though that at least the USB DWC3 controller in host
mode
On Thu, Mar 25, 2021 at 10:48:17AM +, Robin Murphy wrote:
> On 2021-03-25 09:43, Will Deacon wrote:
> > [+ Joerg]
> >
> > On Thu, Mar 25, 2021 at 11:38:24AM +0800, chenxiang wrote:
> > > From: Xiang Chen
> > >
> > > After the change of patch ("iommu: Switch gather->end to the
> > > inclusive
On 2021-03-25 09:43, Will Deacon wrote:
[+ Joerg]
On Thu, Mar 25, 2021 at 11:38:24AM +0800, chenxiang wrote:
From: Xiang Chen
After the change of patch ("iommu: Switch gather->end to the
inclusive end"), the performace drops from 1600+K IOPS to 1200K in our
kunpeng ARM64 platform.
We find tha
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > And a flag IOMMU_SVA_BIND_SUPERVISOR (not that I plan to implement it in
> > the SMMU, but I think we need to clean the current usage)
> >
> You mean move #define SVM_FLAG_SUPERVISOR_MODE out of Intel code to be a
> generic flag in iom
On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > > > Also wondering about device driver allocating auxiliary domains for
> > > > their private
[+ Joerg]
On Thu, Mar 25, 2021 at 11:38:24AM +0800, chenxiang wrote:
> From: Xiang Chen
>
> After the change of patch ("iommu: Switch gather->end to the
> inclusive end"), the performace drops from 1600+K IOPS to 1200K in our
> kunpeng ARM64 platform.
> We find that the range [start1, end1) ac
On Mon, Mar 22, 2021 at 11:37 AM Shameerali Kolothum Thodi
wrote:
>
> [+]
>
> Hi Erik,
>
> As this is now just merged ino acpica-master and based on the discussion we
> had here,
>
> https://github.com/acpica/acpica/pull/638
>
> I had a discussion with ARM folks(Lorenzo) in the linaro-open-discus
Hi Robin,
On Wed, Mar 24, 2021, at 16:29, Robin Murphy wrote:
> On 2021-03-20 15:19, Sven Peter wrote:
> >
> > I have just noticed today though that at least the USB DWC3 controller in
> > host
> > mode uses *two* darts at the same time. I'm not sure yet which parts seem to
> > require which DA
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 15:19:33 +
> > > From: Sven Peter
> > > I have just noticed today though that at least the USB DWC3 controller in
> > > host
> > > mode uses *two
Hi Will,
On 2021-03-15 00:31, Sai Prakash Ranjan wrote:
On 2021-03-12 04:59, Bjorn Andersson wrote:
On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote:
Hi Bjorn,
On 2021-02-27 00:44, Bjorn Andersson wrote:
> On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote:
>
>
> The current logic picks one
76 matches
Mail list logo
