Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

* Saravana Kannan [220701 08:21]: > On Fri, Jul 1, 2022 at 1:10 AM Saravana Kannan wrote: > > > > On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote: > > > > > > * Tony Lindgren [220701 08:33]: > > > > * Saravana Kannan [220630 23:25]: > >

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

* Tony Lindgren [220701 08:33]: > * Saravana Kannan [220630 23:25]: > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote: > > > > > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan > > > wrote: > > > > > > &g

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

* Saravana Kannan [220630 23:25]: > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote: > > > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan > > wrote: > > > > > > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote: > > > > > > >

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

* Saravana Kannan [220623 08:17]: > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote: > > > > * Saravana Kannan [220622 19:05]: > > > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > > > This issue is no directly related fw_devlink. It

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

* Saravana Kannan [220622 19:05]: > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > > > Hi, > > > > * Saravana Kannan [220621 19:29]: > > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > > > > > > > Hi, >

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

Hi, * Saravana Kannan [220621 19:29]: > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > > > Hi, > > > > * Saravana Kannan [700101 02:00]: > > > Now that fw_devlink=on by default and fw_devlink supports > > > "power-domains&qu

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

Hi, * Saravana Kannan [700101 02:00]: > Now that fw_devlink=on by default and fw_devlink supports > "power-domains" property, the execution will never get to the point > where driver_deferred_probe_check_state() is called before the supplier > has probed successfully or before deferred probe

Re: [PATCH] iommu/omap: Fix regression in probe for NULL pointer dereference

Hi, * Joerg Roedel [220408 08:23]: > On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote: > > Can you guys please get this fix into the -rc series? Or ack it so > > I can pick it up into my fixes branch? > > Sorry for the delay, Covid catched me so I was away from

Re: [PATCH] iommu/omap: Fix regression in probe for NULL pointer dereference

Hi, * Tony Lindgren [220331 09:21]: > Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started > triggering a NULL pointer dereference for some omap variants: > > __iommu_probe_device from probe_iommu_group+0x2c/0x38 > probe_iommu_group from b

Re: [PATCH v4 8/9] iommu: Remove unused argument in is_attach_deferred

Hi, * Jason Gunthorpe [220330 17:31]: > On Wed, Mar 30, 2022 at 08:19:37PM +0300, Tony Lindgren wrote: > > > > > __iommu_probe_device from probe_iommu_group+0x2c/0x38 > > > > probe_iommu_group from bus_for_each_dev+0x74/0xbc > > > > bus_fo

[PATCH] iommu/omap: Fix regression in probe for NULL pointer dereference

obe/release_device() call-backs") Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") Signed-off-by: Tony Lindgren --- 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.

Re: [PATCH v4 8/9] iommu: Remove unused argument in is_attach_deferred

* Jason Gunthorpe [220330 14:21]: > On Wed, Mar 30, 2022 at 05:00:39PM +0300, Tony Lindgren wrote: > > Hi, > > > > * Lu Baolu [700101 02:00]: > > > The is_attach_deferred iommu_ops callback is a device op. The domain > > > argument is unnecessary and n

Re: [PATCH v4 8/9] iommu: Remove unused argument in is_attach_deferred

Hi, * Lu Baolu [700101 02:00]: > The is_attach_deferred iommu_ops callback is a device op. The domain > argument is unnecessary and never used. Remove it to make code clean. Looks like this causes a regression for at least drivers/iommu/omap-iommu.c. To me it seems the issue is there is no

Re: [PATCH 1/4] ARM/omap1: switch to use dma_direct_set_offset for lbus DMA offsets

* Janusz Krzysztofik [200919 22:29]: > Hi Tony, > > On Friday, September 18, 2020 7:49:33 A.M. CEST Tony Lindgren wrote: > > * Christoph Hellwig [200917 17:37]: > > > Switch the omap1510 platform ohci device to use dma_direct_set_offset > > > to set the DMA off

Re: [PATCH 1/4] ARM/omap1: switch to use dma_direct_set_offset for lbus DMA offsets

* Christoph Hellwig [200917 17:37]: > Switch the omap1510 platform ohci device to use dma_direct_set_offset > to set the DMA offset instead of using direct hooks into the DMA > mapping code and remove the now unused hooks. Looks nice to me :) I still can't test this probably for few more weeks

Re: [PATCH 0/2] OMAP IOMMU fixes to go with 5.4 OMAP IOMMU changes

* Suman Anna [191017 23:00]: > 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

Re: [PATCH] Revert "dma-contiguous: do not allocate a single page from CMA area"

question is whether to add alloc_page()/free_page() fallbacks to > those call sites, or stuff them directly into the CMA helpers here. Well if you come up with some test patch, I can easily test it :) > > Would you please test and verify? Thanks! Yes this revert works for me: Tested

Re: [PATCH 06/14] mmc: omap: handle highmem pages

* Christoph Hellwig [190212 07:27]: > Instead of setting up a kernel pointer to track the current PIO address, > track the offset in the current page, and do an atomic kmap for the page > while doing the actual PIO operations. I'm currently having issues booting my test devices (770 and n8x0)

Re: [PATCH 0/4] Cleanup legacy OMAP IOMMU device creation

* Suman Anna [151022 10:16]: > Hi Tony, > > On 09/16/2015 06:48 PM, Suman Anna wrote: > > Hi Tony, > > > > The following series removes the legacy platform device creation > > logic for OMAP IOMMU devices. I will cleanup the legacy support > > from the OMAP IOMMU driver in a

Re: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

* Tony Lindgren <t...@atomide.com> [151012 15:57]: > * Suman Anna <s-a...@ti.com> [151012 15:37]: > > Hi Tony, > > > > On 10/12/2015 04:43 PM, Tony Lindgren wrote: > > > * Suman Anna <s-a...@ti.com> [151002 16:27]: > > >> The DSP_SYSTEM

Re: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

* Suman Anna [151002 16:27]: > The DSP_SYSTEM sub-module is a dedicated system control logic > module present within a DRA7 DSP processor sub-system. This > module is responsible for power management, clock generation > and connection to the device PRCM module. > > Add a syscon

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

* Suman Anna s-a...@ti.com [150724 09:27]: Hi Tony, On 07/23/2015 11:30 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150723 09:25]: Hi Tony, On 07/23/2015 02:24 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150722 09:25]: On 07/22/2015 12:26 AM, Tony Lindgren wrote

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

* Suman Anna s-a...@ti.com [150723 09:25]: Hi Tony, On 07/23/2015 02:24 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150722 09:25]: On 07/22/2015 12:26 AM, Tony Lindgren wrote: I don't like using syscon for tinkering directly with SoC registers. This is not a SoC-level

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

* Suman Anna s-a...@ti.com [150722 09:25]: On 07/22/2015 12:26 AM, Tony Lindgren wrote: I don't like using syscon for tinkering directly with SoC registers. This is not a SoC-level register, but a register within a sub-module of the DSP processor sub-system. The DSP_SYSTEM sub-module

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

* Suman Anna s-a...@ti.com [150721 16:58]: --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,6 +26,8 @@ #include linux/of_iommu.h #include linux/of_irq.h #include linux/of_platform.h +#include linux/regmap.h +#include linux/mfd/syscon.h #include

Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver

* Laurent Pinchart laurent.pinch...@ideasonboard.com [140723 07:02]: Hi Joerg, On Wednesday 23 July 2014 15:52:17 Joerg Roedel wrote: On Mon, Jul 21, 2014 at 11:19:29PM -0700, Tony Lindgren wrote: Tony, is there still time to get this (and especially patch 2/3, which touches arch

Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver

* Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 11:17]: Hi Tony and Joerg, On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]: Hi Suman, Joerg and Tony, On Friday 18 July 2014 11:53:56 Suman Anna

Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver

for those ? How about Joerg maybe do an immutable branch against v3.16-rc1 with just these three patches and merge it into your tree? That way I too can merge the minimal branch in if there are conflics. If that works for Joerg, then for arch/arm/*omap* changes: Acked-by: Tony Lindgren t

Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15

* Suman Anna s-a...@ti.com [140311 14:52]: Hi Paul, On 03/05/2014 06:24 PM, Suman Anna wrote: Hi Paul, Benoit, This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support patches that are under arch/arm. The series just assimilates patches 8 through 13 from the v3 OMAP

Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15

* Suman Anna s-a...@ti.com [140312 10:25]: On 03/12/2014 12:04 PM, Tony Lindgren wrote: For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Dan Murphy is currently working on this, and there is still some work

Re: [PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15

* Suman Anna s-a...@ti.com [140304 09:03]: On 03/04/2014 10:04 AM, Joerg Roedel wrote: Applied patches 1-7 to my arm/omap branch. Tony, you can pull that branch into your tree if needed (when I pushed it, which will happen today or tomorrow). OK thanks, looks like remaining patches

Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2

-a...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Tony Lindgren t...@atomide.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines

* Suman Anna s-a...@ti.com [140213 10:19]: The OMAP iommu driver performs the reset management for the iommu instances in processor sub-systems using the omap_device API which are currently supplied as platform data ops. Use pdata quirks to maintain the functionality as the OMAP iommu driver

Re: [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs

* Suman Anna s-a...@ti.com [140213 10:19]: From: Florian Vaussard florian.vauss...@epfl.ch The irq numbers, ocp address space and device attribute data have all been cleaned up for OMAP3 IOMMUs. All this data is populated via the corresponding dt node. Signed-off-by: Florian Vaussard

Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2

-a...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Tony Lindgren t...@atomide.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv2 04/16] iommu/omap: add devicetree support

for the arch/arm/*omap* parts: Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/omap-iommu.c | 5 + drivers/iommu/omap-iommu.c | 41 2 files changed, 42 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/omap

Re: [PATCH 8/9] iommu: OMAP: build only on OMAP2+

o...@wizery.com Cc: Tony Lindgren t...@atomide.com Cc: Omar Ramirez Luna omar.l...@linaro.org Makes sense, I doubt that anybody will work on omap1 version at this point: Acked-by: Tony Lindgren t...@atomide.com --- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH v5 4/5] iommu/omap: adapt to runtime pm

to be checked by Kevin, added him to cc. For the arch/arm/mach-omap2/ change above: Acked-by: Tony Lindgren t...@atomide.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks

* Omar Ramirez Luna omar.l...@linaro.org [121119 17:08]: This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path from enabling modulemode inside CLKCTRL using its clk-enable_reg field. Instead is left to _omap4_enable_module though soc_ops, as the one in charge of this setting.

Re: [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM

Omar, * Omar Ramirez Luna omar.l...@linaro.org [121017 16:54]: On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote: These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu when I have that pushed out as that removes plat/*iommu*.h files. Ok, will wait and rebase