Hi Miaoqian,
On 1/9/22 8:43 PM, Miaoqian Lin wrote:
> Hi Suman Anna,
> On Fri, Jan 07, 2022 at 08:42:16AM -0600, Suman Anna wrote:
>> Hi Miaoqian,
>>
>>
>>> Add the corresponding 'put_device()' in the error handling paths.
>>
>> Also, need it in the regular path, not just in error handling path.
>
Hi Miaoqian,
On 1/7/22 2:04 AM, Miaoqian Lin wrote:
> The reference taken by 'of_find_device_by_node()' must be released when
> not needed anymore.
Thanks for catching this.
> Add the corresponding 'put_device()' in the error handling paths.
Also, need it in the regular path, not just in error
Hi Rob,
On 6/15/21 2:15 PM, Rob Herring wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final
On 8/20/20 6:01 PM, Robin Murphy wrote:
> On 2020-08-20 20:55, Sakari Ailus wrote:
>> On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
>>> On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> Now that arch
Hi Robin,
On 8/20/20 10:08 AM, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma,
> implement the corresponding driver-side support for DMA domains.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/omap-iommu.c | 22 +-
> 1 file chang
On 12/30/19 11:26 AM, Krzysztof Kozlowski wrote:
> Print size_t as %zu or %zx to fix -Wformat warnings when compiling on
> 64-bit platform (e.g. with COMPILE_TEST):
>
> drivers/iommu/omap-iommu.c: In function ‘flush_iotlb_page’:
> drivers/iommu/omap-iommu.c:437:47: warning:
> forma
Hi Krzysztof,
On 12/31/19 2:07 AM, Krzysztof Kozlowski wrote:
> On Tue, Dec 31, 2019 at 03:43:39PM +0800, kbuild test robot wrote:
>> Hi Krzysztof,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on iommu/next]
>> [also build test WARNING on v5.5-rc4]
>> [if y
Hi Tony,
On 8/26/19 7:14 PM, Suman Anna wrote:
> Hi Tony,
>
> The following 2 patches need to go along with the recent "iommu/omap: misc
> fixes" series [1] that is currently staged [2] for a 5.4 merge and available
> in linux-next. That series added runtime pm callbacks in preparation for
> the
Hi Tony,
The following 2 patches need to go along with the recent "iommu/omap: misc
fixes" series [1] that is currently staged [2] for a 5.4 merge and available
in linux-next. That series added runtime pm callbacks in preparation for
the ti-sysc migration, but without adding the necessary platform
The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks after commit db8918f61d51 ("iommu/omap: streamline
enable/disable through runtime pm callbacks"). Plug in these
pdata ops for all the existing IOMMUs through
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata previously. The OMAP IOMMU driver now requires the
platform data ops for device_enable/idle on all the IOMMU devices
after commit db8918f61d51 ("iommu/omap: streamline enable/disable
through runtime pm callbacks") to ena
The macro SLAB_HWCACHE_ALIGN is of type slab_flags_t, but is currently
assigned in the OMAP IOMMU driver using a unsigned long variable. This
generates a sparse warning around the type check. Fix this by defining
the variable flags using the correct type.
Signed-off-by: Suman Anna
---
drivers/io
On 8/9/19 11:13 AM, Joerg Roedel wrote:
> On Wed, Aug 07, 2019 at 11:26:50AM +0300, Tero Kristo wrote:
>> +static inline int omap_iommu_domain_deactivate(struct iommu_domain *domain)
>> {}
>> +static inline int omap_iommu_domain_activate(struct iommu_domain *domain) {}
>
> This caused compilation
Hi Yangtao,
On 6/13/19 11:26 AM, Yangtao Li wrote:
> Updates license to use SPDX-License-Identifier.
>
> Signed-off-by: Yangtao Li
Thanks for the patch. Can you also update another related file
while at this. Will leave it to Joerg if he prefers it as a separate
patch, or folded into this patch
Hi Joerg,
The following is v2 of the patch series that enhances the OMAP IOMMU driver
to support the mirror-programming of the two MMUs present within the DSP
subsystems on TI DRA7xx/AM57xx family of SoCs.
The main changes are to address the review comments on the registration of
the MMU devices
The OMAP IOMMU driver allows only a single device (eg: a rproc
device) to be attached per domain. The current attach detection
logic relies on a check for an attached iommu for the respective
client device. Change this logic to use the client device pointer
instead in preparation for supporting mul
A client user instantiates and attaches to an iommu_domain to
program the OMAP IOMMU associated with the domain. The iommus
programmed by a client user are bound with the iommu_domain
through the user's device archdata. The OMAP IOMMU driver
currently supports only one IOMMU per IOMMU domain per us
On 09/01/2017 11:33 AM, Joerg Roedel wrote:
> Hi Suman,
> On Fri, Sep 01, 2017 at 11:21:45AM -0500, Suman Anna wrote:
>> It's primarily a question of whether each iommu platform device need to
>> be represented as a unique iommu_device or not. If you still think that
>> both these need to be presen
Hi Joerg,
On 09/01/2017 05:01 AM, Joerg Roedel wrote:
> Hi Suman,
>
> On Thu, Aug 31, 2017 at 08:14:02AM -0500, Suman Anna wrote:
>> The OMAP IOMMU driver has been enhanced to support allowing
>> multiple IOMMUs to be programmed by a single client user. This
>> support is being added mainly to ha
Hi Joerg,
The following two patches enhance the OMAP IOMMU driver to support
mirror-programming of two MMUs present within the DSP subsystems
specifically on TI DRA7xx/AM57xx family of SOCs. The TI OMAP DSP
subsystems traditionally always has a DSP core and an internal EDMA
block behind a single
A client user instantiates and attaches to an iommu_domain to
program the OMAP IOMMU associated with the domain. The iommus
programmed by a client user are bound with the iommu_domain
through the user's device archdata. The OMAP IOMMU driver
currently supports only one IOMMU per IOMMU domain per us
The OMAP IOMMU driver allows only a single device (eg: a rproc
device) to be attached per domain. The current attach detection
logic relies on a check for an attached iommu for the respective
client device. Change this logic to use the client device pointer
instead in preparation for supporting mul
On 07/28/2017 03:49 PM, Josue Albarran wrote:
> The OMAP IOMMU driver was using ARM assembly code directly for
> flushing the MMU page table entries from the caches. This caused
> MMU faults on OMAP4 (Cortex-A9 based SoCs) as L2 caches were not
> handled due to the presence of a PL310 L2 Cache Cont
On 06/28/2017 07:00 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Make sure that the device_group callback returns an ERR_PTR
> instead of NULL.
>
> Signed-off-by: Joerg Roedel
Thanks for the patch,
Acked-by: Suman Anna
regards
Suman
> ---
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file c
24 matches
Mail list logo
