* 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]:
> >
* 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
* 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:
> > > >
> > >
* 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
* 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,
> >
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
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 time
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
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
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
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.
* 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
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 is_a
* 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
* 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
th
* 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
t;
> I guess the 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 w
* 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)
wit
* 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 subsequent merge win
* Tony Lindgren [151012 15:57]:
> * Suman Anna [151012 15:37]:
> > Hi Tony,
> >
> > On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> > > * Suman Anna [151002 16:27]:
> > >> The DSP_SYSTEM sub-module is a dedicated system control logic
> > >>
* Suman Anna [151012 15:37]:
> Hi Tony,
>
> On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> > * 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
>
* 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 node for this modu
* Suman Anna [150903 16:01]:
> >>>> On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> > OK maybe check the syss/sysc registers involved here for each hardware
> > module here and which driver tinkers with which registers? This will
> > make things a lot easier in the
* Suman Anna [150724 09:27]:
> Hi Tony,
>
> On 07/23/2015 11:30 PM, Tony Lindgren wrote:
> > * Suman Anna [150723 09:25]:
> >> Hi Tony,
> >>
> >> On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> >>> * Suman Anna [150722 09:2
* Suman Anna [150723 09:25]:
> Hi Tony,
>
> On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> > * Suman Anna [150722 09:25]:
> >> On 07/22/2015 12:26 AM, Tony Lindgren wrote:
> >>>
> >>> I don't like using syscon for tinkering directly with SoC
* Suman Anna [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.
* Suman Anna [150721 16:58]:
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -26,6 +26,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -112,6 +114,18 @@ void omap_iommu_restore_ctx(struct device *dev)
> }
> EXPORT_SYMBOL_
* Laurent Pinchart [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
> >
* Laurent Pinchart [140721 11:17]:
> Hi Tony and Joerg,
>
> On Monday 21 July 2014 02:33:36 Tony Lindgren wrote:
> > * Laurent Pinchart [140721 02:16]:
> > > Hi Suman, Joerg and Tony,
> > >
> > > On Friday 18 July 2014 11:53:56 Suman Anna wrote:
> &
ut 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
If the above is too complicated,
* Suman Anna [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
* Suman Anna [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 IOM
* Suman Anna [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 compile j
* Suman Anna [140228 12:46]:
> Hi Joerg, Tony,
>
> This is an updated series of the OMAP IOMMU DT adaptation intended
> for 3.15 merge window, addressing the comments from the v2 series.
> This series is rebased onto 3.14-rc4, and the only change to bindings
> is to drop the dma-window property.
* Florian Vaussard [140227 01:19]:
> Hi,
>
> On 02/26/2014 06:59 PM, Suman Anna wrote:
> > Tony,
> >
> > On 02/26/2014 11:18 AM, Tony Lindgren wrote:
> >> * Suman Anna [140213 10:19]:
> >>> From: Florian Vaussard
> >>>
> &
his will not work and driver will not be probed. Convert it!
>
> Signed-off-by: Florian Vaussard
> [s-a...@ti.com: dev_name adaptation and improved error checking]
> Signed-off-by: Suman Anna
Best that this gets merged along with the other iommu patches, so
for the arch/ar
> > by marking the DT node disabled, so remove this obsolete flag and
> > the corresponding hwmod data can be enabled.
> >
> > Cc: Paul Walmsley
> > Signed-off-by: Florian Vaussard
> > [s-a...@ti.com: revise commit log]
> > Signed-off-by:
* Suman Anna [140213 10:19]:
> From: Florian Vaussard
>
> 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
> Signed-off-by: Suman Anna
This
* Suman Anna [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
> gets conv
> > by marking the DT node disabled, so remove this obsolete flag and
> > the corresponding hwmod data can be enabled.
> >
> > Cc: Paul Walmsley
> > Signed-off-by: Florian Vaussard
> > [s-a...@ti.com: revise commit log]
> > Signed-off-by:
* Arnd Bergmann [130305 14:21]:
> The OMAP IOMMU driver intentionally fails to build on OMAP1
> platforms, so we should not allow enabling it there.
>
> Signed-off-by: Arnd Bergmann
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> Cc: Ohad Ben-Cohen
> Cc: T
* Omar Ramirez Luna [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.
>
> According to comme
a->nr_tlb_entries;
> pdata->da_start = a->da_start;
> pdata->da_end = a->da_end;
The runtime PM related changes would be good to be checked
by Kevin, added him to cc. For the arch/arm/mach-omap2/ change above:
Acked-by: Tony Lindgren
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Omar,
* Omar Ramirez Luna [121017 16:54]:
> On 16 October 2012 12:22, Tony Lindgren 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 on
* Omar Ramirez Luna [121011 18:07]:
> These patches are needed for remoteproc to work on OMAP4.
>
> Introduced iommu hwmod support for OMAP3 (iva, isp) and
> OMAP4 (ipu, dsp), along with the corresponding runtime PM
> and routines to deassert reset lines, enable/disable clocks
> and configure sys
45 matches
Mail list logo
