On Monday 16 April 2012, Hiroshi Doyu wrote:
> What about using "dma-window" property to specify IOVA range in dtsi as below?
>
> arch/powerpc/platforms/cell/iommu.c:
>
> 698 static int __init cell_iommu_get_window(struct device_node *np,
> 699 unsigned lo
On Wednesday 18 April 2012, Hiroshi Doyu wrote:
> If we can consider IOMMU as one of the implementation of DMA(Direct
> Memory Access), the prefix "dma-(window)" may make sense here. Then,
> we don't have to introduce a new concept "IO virtual address(iova)" in
> addition to the existing "bus addre
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
> I guess that it would work. Originally I thought that using DMA-API
> and IOMMU-API together in driver might be kind of layering violation
> since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
> might be cleaner. Considering t
On Tuesday 19 August 2014, Will Deacon wrote:
> > +static int arm_smmu_parse_iommus_properties(struct arm_smmu_device *smmu,
> > + int *num_masters)
> > +{
> > + struct of_phandle_args iommuspec;
> > + struct device_node *dn;
> > +
> > + for_each_node
On Monday 01 September 2014 09:53:29 Marek Szyprowski wrote:
> On 2014-09-01 09:07, Thierry Reding wrote:
> > On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
> >> Hi Greg,
> >>
> >> On 2014-08-05 12:47, Marek Szyprowski wrote:
> >>> This patch adds a new flags for device drivers.
On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote:
> > Who do you think needs to set this flag, and who needs to read it?
>
> In the proposed solution Exynos IOMMU driver creates a separate IO
> address space
> for every client device in a system and binds it to the default
> dma-mappi
On Monday 01 September 2014 14:07:34 Marek Szyprowski wrote:
> On 2014-09-01 13:56, Arnd Bergmann wrote:
> > On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote:
> >>> Who do you think needs to set this flag, and who needs to read it?
> >> In the propose
On Friday 29 August 2014 16:54:25 Will Deacon wrote:
> set_arch_dma_coherent_ops is called from of_dma_configure in order to
> swizzle the architectural dma-mapping functions over to a cache-coherent
> implementation. This is currently implemented only for ARM.
>
> In anticipation of re-using this
On Monday 01 September 2014 09:52:19 Thierry Reding wrote:
> I don't think this is the right direction. We've been preaching that
> using initcall ordering is a bad thing and people should be using
> deferred probe instead. Now we have a bunch of these OF tables that do
> the exact opposite. Note t
On Monday 01 September 2014 10:13:22 Thierry Reding wrote:
> On Fri, Aug 29, 2014 at 04:54:26PM +0100, Will Deacon wrote:
> > This patch adds a new function to the iommu_ops structure to allow a
> > device to be added to a specific IOMMU instance along with a set of
> > opaque IDs that are used int
On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
>
> I think this could use a bit more formalization. As I said in another
> reply earlier, there's very little standardization in the IOMMU API.
> That certainly gives us a lot of flexibility but it also has the
> downside that it's diffic
On Friday 29 August 2014 16:54:28 Will Deacon wrote:
> static void of_dma_configure(struct platform_device *pdev)
> {
> - u64 dma_addr, paddr, size;
> + u64 dma_addr, paddr, size, mask;
> int ret;
> - bool coherent;
> + bool coherent, iommu;
> unsigned long
On Monday 01 September 2014 17:34:00 Will Deacon wrote:
> On Mon, Sep 01, 2014 at 03:39:16PM +0100, Arnd Bergmann wrote:
> > On Monday 01 September 2014 10:13:22 Thierry Reding wrote:
> > > On Fri, Aug 29, 2014 at 04:54:26PM +0100, Will Deacon wrote:
> > > > diff -
On Monday 01 September 2014 17:40:00 Will Deacon wrote:
> On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
> > On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
> > >
> > > I think this could use a bit more formalization. As I said in another
&
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
>
> > -- I have concerns that allocating one domain per master might be
> > too much, but it's hard to tell without an IOMMU driver ported over.
>
> One domain per master is IMHO a sane default configuration. The only default
> alter
On Tuesday 02 September 2014 11:03:42 Will Deacon wrote:
> On Mon, Sep 01, 2014 at 09:18:26PM +0100, Arnd Bergmann wrote:
> > On Monday 01 September 2014 17:40:00 Will Deacon wrote:
> > > On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
> > > > On Mon
On Tuesday 02 September 2014 12:42:13 Marek Szyprowski wrote:
> Hi Arnd,
>
> On 2014-09-02 10:56, Arnd Bergmann wrote:
> > On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
> >>>-- I have concerns that allocating one domain per master might be
> >&
On Tuesday 02 September 2014 14:24:18 Marek Szyprowski wrote:
> >>> For isolation purposes, it can only help to have more domains, but
> >>> I would guess that there is some space overhead in maintaining lots
> >>> of page tables.
> >> I'm okay with both approaches (separate domain for each device
On Tuesday 02 September 2014 14:30:36 Marek Szyprowski wrote:
> However we also need to figure out how to let drivers to make their own
> configuration, like it is required by Exynos DRM subsystem, which consist
> of several devices, each having its own IOMMU controller, but for
> >>
On Tuesday 02 September 2014 14:05:08 Will Deacon wrote:
> On Tue, Sep 02, 2014 at 01:15:06PM +0100, Arnd Bergmann wrote:
> > > Anyway, I'll try to hack something together shortly. I think the proposal
> > > is:
> > >
> > > - Make add_device_maste
On Tuesday 02 September 2014 14:47:54 Varun Sethi wrote:
> > +void __init of_iommu_init(void)
> > +{
> > + struct device_node *np;
> > + const struct of_device_id *match, *matches = &__iommu_of_table;
> > +
> > + for_each_matching_node_and_match(np, matches, &match) {
> > +
On Tuesday 02 September 2014 15:03:14 Varun Sethi wrote:
> Hi Thierry/Will/Arnd,
> Where would the of_xlate callback reside and what would be its function?
>
It is an additional function pointer in iommu_ops and replaces the
add_device callback for IOMMUs that are DT-enabled.
The idea is that w
On Tuesday 02 September 2014 18:56:26 Will Deacon wrote:
> @@ -803,9 +804,11 @@ static int __init customize_machine(void)
> if (machine_desc->init_machine)
> machine_desc->init_machine();
> #ifdef CONFIG_OF
> - else
> + else {
> + of_iommu_init();
On Tuesday 02 September 2014 18:56:27 Will Deacon wrote:
> This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
> actually called outside of a few drivers) into arch_setup_dma_ops, so
> that we can use IOMMUs for DMA transfers in a more generic fashion.
>
> Since this significa
On Tuesday 02 September 2014 18:56:24 Will Deacon wrote:
> +struct iommu_dma_mapping *of_iommu_configure(struct device *dev)
> +{
> + struct of_phandle_args iommu_spec;
> + struct iommu_dma_mapping *mapping;
> + struct bus_type *bus = dev->bus;
> + const struct iommu_ops *op
On Tuesday 02 September 2014 18:56:20 Will Deacon wrote:
> The main difference since v1 is that I've introduced some generic
> structures to represent IOMMUs and their mappings (struct iommu_data and
> struct iommu_dma_mapping). This allows us to propagate the per-instance
> data all the way down t
On Sunday 14 September 2014, Varun Sethi wrote:
> "master-id-bits" property added to the IOMMU device node. This property can
> be used by the IOMMU driver to match relevan bits in the master id expressed
> by a DMA master.
>
> This can be used to mask out certain bits that get added to the device
On Monday 15 September 2014, Varun Sethi wrote:
> >
> > This seems rather specific to MMU-500. I don't think that most IOMMUs would
> > use the term 'master ID', 'stream ID' or even the general concept, and you
> > don't expand the acronym 'TBU'. I've seen many IOMMUs and I don't even
> > know wha
On Monday 22 September 2014 11:36:15 Thierry Reding wrote:
> On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
> > We need to ensure that the IOMMUs in the system have a chance to perform
> > some basic initialisation before we start adding masters to them.
> >
> > This patch adds a cal
On Monday 22 September 2014 13:40:40 Thierry Reding wrote:
> On Mon, Sep 22, 2014 at 01:08:27PM +0200, Arnd Bergmann wrote:
> > On Monday 22 September 2014 11:36:15 Thierry Reding wrote:
> > > On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
> > > > We nee
On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote:
> > I see two problems with using deferred probing here:
> >
> > - we don't actually need to defer the probing but the binding to the driver
> > when no dma ops are set, but it seems silly to even create the device
> > before we can
On Tuesday 30 September 2014 18:28:12 Mitchel Humpherys wrote:
> + */
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
Does it make sense to call this with tim
On Tuesday 30 September 2014 18:28:13 Mitchel Humpherys wrote:
> + if (readl_poll_timeout_atomic(cb_base + ARM_SMMU_CB_ATSR, tmp,
> + !(tmp & ATSR_ACTIVE), 50, 100)) {
>
This looks really bad.
You are doing up to 50 100us delays, each of which can be much long
On Tuesday 07 October 2014 18:47:59 Mitchel Humpherys wrote:
> On Wed, Oct 01 2014 at 01:25:33 AM, Arnd Bergmann wrote:
> > On Tuesday 30 September 2014 18:28:12 Mitchel Humpherys wrote:
> >> + */
> >> +#define readl_poll_timeout(addr, val,
On Friday 10 October 2014 12:44:45 Mitchel Humpherys wrote:
> >> Regarding the division, for the overwhelmingly common case where the
> >> user of the API passes in a constant for sleep_us the compiler optimizes
> >> out this calculation altogether and just sticks the final result in (I
> >> verifi
On Tuesday 14 October 2014 16:07:38 Laurent Pinchart wrote:
> On Tuesday 23 September 2014 09:44:25 Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote:
> > > > I see two problems with using deferred probing here:
> > > >
> >
On Thursday 30 October 2014 11:41:00 Will Deacon wrote:
> > +
> > +#define readl_poll_timeout(addr, val, cond, delay_us, timeout_us) \
> > + readx_poll_timeout(readl, addr, val, cond, delay_us, timeout_us)
> > +
> > +#define readl_poll_timeout_atomic(addr, val, cond, delay_us, timeout_us) \
> > +
On Thursday 13 November 2014 10:32:25 Thierry Reding wrote:
> From: Thierry Reding
>
> This is the sixth installment in the Tegra IOMMU and memory controller
> support series. This version addresses the final outstanding comments from
> Olof about using proper Kconfig symbols to track the depende
On Friday 14 November 2014 18:56:29 Will Deacon wrote:
>
> Here is the fourth iteration of the RFC I've previously posted here:
>
> RFCv1:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
> RFCv2:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-Se
On Friday 14 November 2014 19:27:54 Will Deacon wrote:
>
> > At the moment, iommu_ops is a structure that can get used for any
> > number of iommus of the same type, but by putting per-device private
> > data into the same structure you have to duplicate it per instance.
>
> I'm not sure I agree
t; my
>
> Acked-by: Joerg Roedel
>
> To further improve this we should probably introduce a seperate
> iommu-descriptor data-structure later which then describes a single
> hardware iommu device.
so I second that and add my
Acked-by: Arnd Bergmann
Now, who should m
On Monday 01 December 2014 16:58:09 Rob Herring wrote:
> > @@ -178,28 +180,21 @@ static void of_dma_configure(struct device *dev)
> > if (!dev->dma_mask)
> > dev->dma_mask = &dev->coherent_dma_mask;
> >
> > - /*
> > -* if dma-coherent property exist, call arch
On Tuesday 02 December 2014 10:23:00 Marek Szyprowski wrote:
> >> +static inline void of_iommu_set_ops(struct device_node *np,
> >> + const struct iommu_ops *ops)
> >> +{
> >> + np->data = (struct iommu_ops *)ops;
> >> +}
> >> +
> >> +static inline struct iom
On Tuesday 02 December 2014 14:16:57 Grant Likely wrote:
> On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring wrote:
> > On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon wrote:
> >>
> >> +static inline void of_iommu_set_ops(struct device_node *np,
> >> + const struct iommu
On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
> On Wed, Dec 03, 2014 at 07:57:50PM +0000, Arnd Bergmann wrote:
> > On Tuesday 02 December 2014 14:16:57 Grant Likely wrote:
> > > On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring
> > > wrote:
> > > >
On Thursday 04 December 2014 10:21:27 Will Deacon wrote:
> On Thu, Dec 04, 2014 at 10:10:17AM +0000, Arnd Bergmann wrote:
> > On Thursday 04 December 2014 09:49:53 Will Deacon wrote:
> > > On Wed, Dec 03, 2014 at 07:57:50PM +0000, Arnd Bergmann wrote:
> > > > On Tue
On Thursday 04 December 2014 12:26:58 Robin Murphy wrote:
>
> +struct of_iommu_node {
> + struct hlist_node list;
> + struct device_node *np;
> + const struct iommu_ops *ops;
> +};
> +static HLIST_HEAD(of_iommu_list);
> +static DEFINE_SPINLOCK(of_iommu_lock);
Looks good to me. F
On Friday 05 December 2014 12:10:37 Will Deacon wrote:
> On Thu, Dec 04, 2014 at 07:42:28PM +, Robin Murphy wrote:
> > On 04/12/14 17:58, Grant Likely wrote:
> > [...]
> > +struct of_iommu_node {
> > + struct list_head list;
> > + struct device_node *np;
> > +
On Friday 05 December 2014 16:35:06 Will Deacon wrote:
> Hi Olof,
>
> Please consider pulling the following series for 3.19. I appreciate that
> this is late in the day, but the patches have been around for a while and
> have collected all the Acks that they need. Marek has already been finding
>
On Monday 15 December 2014 22:25:21 Suman Tripathi wrote:
> + return 0;
> +}
> +
> +static struct of_device_id xgene_ahbc_mmu_of_match[] = {
> + { .compatible = "apm,xgene-ahbc-iommu"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, xgene_ahbc_mmu_of_match);
> +
> +static struct platfo
On Monday 15 December 2014 22:25:23 Suman Tripathi wrote:
> +*APM X-Gene AHBC IOMMU Architecture Implementation
> +
> +APM X-Gene SoC AHBC IOMMU translates the AHBC 32-bit address from
> +dma master to 42-bit AXI address by using a set of AIM(AHB Inbound mapper)
> +register.
> +
> +** AHBC IOMMU re
On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > > > IOMMUs are not as low-level as system interrupt controllers or system
> > > > clocks. I'm beginning to agree with Thierry that they should be treated
> > > > as normal platform devices as they're not required earlier than probe
> > > >
On Tuesday 16 December 2014 14:07:11 Laurent Pinchart wrote:
> Hi Arnd,
>
> On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> > On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > >>>> IOMMUs are not as low-level as system interrupt controlle
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
> > Using a single domain is a bit of a waste of resources in my case, so an
> > evolution would be to create four domains and assign devices to them based
> > on
> > a policy. The policy could be fixed (round-robin for instance), or
> > co
On Monday 15 December 2014 15:54:42 Mark Brown wrote:
> The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and
> outer_flush_range() functions. This breaks the build on arm64 allmodconfig
> in -next since support has been merged for some Exynos ARMv8 SoCs. Add a
> dependency on ARM to
On Wednesday 17 December 2014 12:09:49 Will Deacon wrote:
> On Tue, Dec 16, 2014 at 12:08:15PM +0000, Arnd Bergmann wrote:
> > On Monday 15 December 2014 18:09:33 Will Deacon wrote:
> > > > Using a single domain is a bit of a waste of resources in my case, so
> > >
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
>
> If we forbid the IOMMU driver from being compiled as a module can't we just
> rely on deferred probing ? The bus master driver will just be reprobed after
> the IOMMU gets probed, like for other devices.
>
> This could fail in c
On Wednesday 17 December 2014 14:45:18 Will Deacon wrote:
> On Wed, Dec 17, 2014 at 02:15:12PM +0000, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 12:09:49 Will Deacon wrote:
> > > On Tue, Dec 16, 2014 at 12:08:15PM +0000, Arnd Bergmann wrote:
> > > > On Mo
On Wednesday 17 December 2014 15:01:58 Will Deacon wrote:
> On Wed, Dec 17, 2014 at 02:27:30PM +, Robin Murphy wrote:
> > On 17/12/14 12:09, Will Deacon wrote:
> > > I think that's a slightly different case. The `grouping' in the DT, is on
> > > a
> > > per-master basis where a master may have
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
>
> On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > > If we forbid the IOMMU driver from being compiled as a module can&#x
On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote:
> Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
> > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > >
> > > If we forbid the IOMMU driver from being compiled as a module can&#
On Wednesday 17 December 2014 17:17:52 Will Deacon wrote:
> > > > I would hope that PCI is the only case we need to worry about for a
> > > > while.
> > > > This means we just need to come up with another property or a set of
> > > > properties
> > > > that we can put into a PCI host controller d
On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote:
> On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
> > > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> > > > On
On Thursday 18 December 2014 22:36:14 Laurent Pinchart wrote:
>
> > (currently only on ARM64, not ARM32, until someone adds support). I can see
> > your point regarding machines that have a mandatory IOMMU with no fallback
> > when there is no driver, but we can support them by making the iommu dr
On Sunday 21 December 2014 10:04:51 Will Deacon wrote:
> On Wed, Dec 17, 2014 at 07:48:29PM +0000, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 17:17:52 Will Deacon wrote:
> > > > > > I would hope that PCI is the only case we need to worry about for a
> >
On Wednesday 07 January 2015 18:57:05 Will Deacon wrote:
>
> Sorry for the delay on this, I had to do a bit of digging.
>
> On Mon, Dec 22, 2014 at 01:36:01PM +, Arnd Bergmann wrote:
> > Do you think it's possible that we might have to deal with a single PCI host
&g
On Wednesday 07 January 2015 13:49:50 Murali Karicheri wrote:
> PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
> add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
> and dma ops etc using the information from DT. The prior RFCs and discussions
On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
> On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri wrote:
>
> > + ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> > + if (ret < 0) {
> > + dma_addr = offset = 0;
> > + size = dev->coherent_dm
On Wednesday 07 January 2015 18:04:41 Murali Karicheri wrote:
> On 01/07/2015 04:18 PM, Arnd Bergmann wrote:
> > On Wednesday 07 January 2015 13:49:50 Murali Karicheri wrote:
> >> PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
> >&g
On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:
> On 01/08/2015 03:40 AM, Arnd Bergmann wrote:
> > On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
> >> On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri
> >> wrote:
> >>
> >>
On Thursday 08 January 2015 14:52:13 Murali Karicheri wrote:
>
> Could you add this as as a follow up patch as I don't have a platformm
> that support IOMMU and as such my understanding of the IOMMU is limited?
>
> I can help test the change to make sure it has no side effect on
> Keystone that
On Thursday 08 January 2015 09:56:39 Arnd Bergmann wrote:
> There is another interesting case, which is a USB host controller or
> something similar behind a PCI bus. These are quite common and also
> need to be handled in some form. Let's do just PCI first for now, but
> be awa
On Thursday 08 January 2015 18:44:31 Murali Karicheri wrote:
> The grep of dma-ranges for arch/arm shows the size used is mask + 1 as
>
> ./boot/dts/keystone.dtsi: dma-ranges = <0x8000 0x8
> 0x
> 0x8000>;
> ./boot/dts/keystone.dtsi: dma-ranges;
On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
>
> This one's a bit tricky to find a home for - I think technically it's
> probably an IOMMU patch, but then the long-underlying problem doesn't
> seem to have blown up anything until arm64, and my motivation is to
> make bits of Juno work,
r look at this patch please? You had some
> comments in the past.
No further objections from my side. I don't think it's really needed,
but it seems harmless, so
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Monday 19 January 2015 13:36:24 Thierry Reding wrote:
> On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote:
> > On Thursday 15 January 2015 11:12:17 Will Deacon wrote:
> > > On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding wrote:
> > > > On Wed, Jan 14, 2015 at 10:46:10AM +
On Sunday 18 January 2015 13:18:51 Laurent Pinchart wrote:
> On Sunday 18 January 2015 15:54:34 Alexandre Courbot wrote:
> > On 01/16/2015 08:18 AM, Laurent Pinchart wrote:
> > > On Thursday 15 January 2015 11:12:17 Will Deacon wrote:
> > >> On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding
On Monday 19 January 2015 17:21:14 Thierry Reding wrote:
> On Mon, Jan 19, 2015 at 04:52:41PM +0100, Arnd Bergmann wrote:
> > On Monday 19 January 2015 13:36:24 Thierry Reding wrote:
> > > On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote:
> > > > On
On Friday 23 January 2015 16:21:49 Laurent Pinchart wrote:
> +/**
> + * arm_iommu_detach_device
> + * @dev: valid struct device pointer
> + *
> + * Detaches the provided device from a previously attached map.
> + * This voids the dma operations (dma_map_ops pointer)
> + */
> +void arm_iommu_detach_
On Friday 23 January 2015 17:55:25 Laurent Pinchart wrote:
>
> On Friday 23 January 2015 16:27:24 Arnd Bergmann wrote:
> > On Friday 23 January 2015 16:21:49 Laurent Pinchart wrote:
> > > +/**
> > > + * arm_iommu_detach_device
> > >
clared identifier is
reported only once for each function it appears in
../arch/arm/mm/dma-mapping.c: In function '__atomic_get_pages':
../arch/arm/mm/dma-mapping.c:1358:27: error: 'atomic_pool' undeclared (first
use in this function)
struct dma_pool *pool = &atomic_pool
-bit.
Signed-off-by: Arnd Bergmann
Fixes: 859a732e4f713 ("iommu/arm-smmu: add support for iova_to_phys through
ATS1PR")
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 1d6d43bb3395..fc13dd56953e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-sm
On Wednesday 25 February 2015 11:03:02 Murali Karicheri wrote:
>
> > (I don't know exactly how these patches all fit together, so that's
> > probably not accurate, but that's the *sort* of thing I'd like to include.)
> >
> > If that actually *is* what's going on, I have to wonder why this isn't
>
On Thursday 05 March 2015 18:56:36 Robin Murphy wrote:
> @@ -1630,6 +1630,13 @@ static int arm_smmu_device_cfg_probe(struct
> arm_smmu_device *smmu)
> size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
> smmu->pa_size = size;
>
> + /*
> +* What t
On Monday 09 March 2015 18:59:37 Paul Bolle wrote:
> Hi Yong,
>
> Yong Wu schreef op ma 09-03-2015 om 19:57 [+0800]:
> > On Fri, 2015-03-06 at 12:30 +0100, Paul Bolle wrote:
> > > On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > > > --- a/drivers/soc/mediatek/Kconfig
> > > > +++
On Monday 09 March 2015 11:26:52 Yingjoe Chen wrote:
> On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > From: Yong Wu
> >
> > This patch add SMI(Smart Multimedia Interface) driver. This driver is
> > responsible to enable/disable iommu and control the clocks of each
> > loca
On Tuesday 10 March 2015 14:27:04 Yingjoe Chen wrote:
> On Mon, 2015-03-09 at 22:56 +0100, Arnd Bergmann wrote:
> > On Monday 09 March 2015 11:26:52 Yingjoe Chen wrote:
> > > On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > > > From: Yong Wu
>
this function)
np = of_find_matching_node(NULL, rk_iommu_dt_ids);
This removes the #ifdef and the corresponding of_match_ptr wrapper
to make it build both with CONFIG_OF enabled or disabled.
Signed-off-by: Arnd Bergmann
Fixes: 425061b0f5074 ("iommu/rockchip: Play nice in multi-platform build
callbacks")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 451e3c98ab2d..09c6e1c680db 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers
On Fri, Sep 6, 2019 at 5:24 PM Suman Anna wrote:
>
> Hi Arnd,
>
> On 9/6/19 10:15 AM, Arnd Bergmann wrote:
> > The runtime_pm functions are unused when CONFIG_PM is disabled:
> >
> > drivers/iommu/omap-iommu.c:1022:12: error: unused function
> > 'omap
On Thu, Jul 25, 2019 at 2:24 PM Dmitry Osipenko wrote:
>
> 25.07.2019 5:41, YueHaibing пишет:
> > If IOMMU_SUPPORT is not set, and COMPILE_TEST is y,
> > IOMMU_IOVA may be set to m. So building will fails:
> >
> > drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
> > iomm
zero(dma_limit, dev->bus_dma_limit);
^~~~
Add an explicit cast to work around it, as there is no min_not_zero_t()
equivalent of min_t().
Fixes: a7ba70f1787f ("dma-mapping: treat dev->bus_dma_mask as a DMA limit")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/
On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev,
> struct sdhci_host *host)
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_esdhc *esdhc;
> u16 host_ver;
> + u32 svr;
>
>
On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> > similarity index 91%
> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > rename to Docum
On Thursday 17 March 2016 12:01:01 Rob Herring wrote:
> On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote:
> > >> This makes the driver non-portable. Better identify the specific
> > >> workarounds based on the compatible string for this device, or add a
> > >> boolean DT property for the
On Monday 25 April 2016 14:32:42 Will Deacon wrote:
> > >>
> > >>+static inline __u64 hi_lo_readq_relaxed(const volatile void __iomem
> > >>*addr)
> > >>+{
> > >>+ const volatile u32 __iomem *p = addr;
> > >>+ u32 low, high;
> > >>+
> > >>+ high = readl_relaxed(p + 1);
> > >>+ low = readl_
On Monday 25 April 2016 16:28:01 Robin Murphy wrote:
> >>>
> >>> We _could_ - indeed I started doing that, but then decided that the
> >>> obfuscation of horrible macro-templated functions wasn't worth saving a
> >>> couple of hundred bytes in some code that isn't exactly difficult to
> >>> maintai
bit accessors as appropriate.
>
> CC: Arnd Bergmann
> CC: Christoph Hellwig
> CC: Darren Hart
> CC: Hitoshi Mitake
> Signed-off-by: Robin Murphy
> ---
>
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foun
On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
>
> + fsl_guts_init();
> + svr = fsl_guts_get_svr();
> + if (svr) {
> + esdhc->soc_ver = SVR_SOC_VER(svr);
> + esdhc->soc_rev = SVR_REV(svr);
> + } else {
> + dev_err(&pdev->dev, "Fa
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-...@lists.ozlabs.org
> > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger
101 - 200 of 345 matches
Mail list logo
