This patch mainly adds support for mt8192 IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
Convert MediaTek IOMMU to DT schema.
Signed-off-by: Yong Wu
---
.../bindings/iommu/mediatek,iommu.txt | 103
.../bindings/iommu/mediatek,iommu.yaml| 154 ++
2 files changed, 154 insertions(+), 103 deletions(-)
delete mode 100644 Documentation/devicet
Convert MediaTek SMI to DT schema.
Signed-off-by: Yong Wu
---
.../mediatek,smi-common.txt | 49 -
.../mediatek,smi-common.yaml | 100 ++
.../memory-controllers/mediatek,smi-larb.txt | 49 -
.../memory-controllers/mediatek,smi-
This patch adds decriptions for mt8192 IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
|
In the latest SoC, there are several HW IP require a sepecial iova
range, mainly CCU and VPU has this requirement. Take CCU as a example,
CCU require its iova locate in the range(0x4000_ ~ 0x43ff_).
In this patch we add a domain definition for the special port. In the
example of CCU, If we
Extend the max larb number definition as mt8192 has larb_nr over 16.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
---
.../bindings/memory-controllers/mediatek,smi-larb.yaml| 2 +-
include/dt-bindings/memory/mtk-smi-larb-port.h| 4 ++--
2 files changed, 3 insertions(+), 3
Put all the macros about smi larb/port togethers, this is a preparing
patch for extending LARB_NR and adding new dom-id support.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
---
include/dt-bindings/memory/mt2712-larb-port.h | 2 +-
include/dt-bindings/memory/mt6779-larb-port.h | 2 +-
inclu
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: Yong Wu
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io-pgtable.h | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drive
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/io-pgtable-arm-v7s.c | 34 +++---
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drive
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: Yong Wu
---
drivers/iommu/io-pgtable-arm-v7s.c | 13 ++---
drivers/iommu/mtk_iommu.c | 2 +-
2 files changed, 11 ins
Use the common larb-port header in the source code.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 7 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 1 +
include/soc/mediatek/smi.h | 2 --
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/iom
Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
BTW, change the ias/oas checking format in arm_v7s_map.
Signed-off-by: Yong Wu
---
drivers/iommu/io-pgtable-arm-v7s.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletion
In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 ++
1 file changed, 6 insertions(+), 4 del
In the lastest SoC, M4U has its special power domain. thus, If the engine
begin to work, it should help enable the power for M4U firstly.
Currently if the engine work, it always enable the power/clocks for
smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
then, if smi-common
Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
for the previous SoC. this also is a preparing patch for supporting
multi-domains.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, the
For multiple iommu_domains, we need to reserve some iova regions. Take a
example, If the default iova region is 0 ~ 4G, but the 0x4000_ ~
0x43ff_ is only for the special CCU0 domain. Thus we should exclude
this region for the default iova region.
This patch adds iova reserved flow. It's a
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four banks:
This patch adds pm runtime callback.
In pm runtime case, all the registers backup/restore and bclk are
controlled in the pm_runtime callback, then pm_suspend is not needed in
this case.
runtime PM is disabled when suspend, thus we call
pm_runtime_status_suspended instead of pm_runtime_suspended.
If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush
register. Add a new macro for this.
there is a minor change unrelated with this patch. it also use the new
macro.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 11 +++
1 file changed, 7 insertions(+), 4 delet
If the iova is over 32bit, the fault status register bit is a little
different. Add a flag for the special register bits.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drive
Some HW IP(ex: CCU) require the special iova range. That means the
iova got from dma_alloc_attrs for that devices must locate in his
special range. In this patch, we allocate a special iova_range for
each a special requirement and create each a iommu domain for each
a iova_range.
meanwhile we stil
Add mt8192 iommu support.
For multi domain, Add 1M gap for the vdec domain size. That is because
vdec HW has a end address register which require (start_addr +
len) rather than (start_addr + len - 1). Take a example, if the start_addr
is 0xfff0, size is 0x10, then the end_address is 0xfff0
Add "struct mtk_iommu_data *" in the "struct mtk_iommu_domain",
reduce the call mtk_iommu_get_m4u_data().
No functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b
Add mt8192 smi support.
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index e94c99ca2883..0ec3eff4d92d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk
Hi All,
On 25.09.2020 23:23, Alex Deucher wrote:
> On Tue, Sep 22, 2020 at 2:28 AM Marek Szyprowski
> wrote:
>> On 22.09.2020 01:15, Alex Goins wrote:
>>> Tested-by: Alex Goins
>>>
>>> This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
>>> AMDGPU in v5.9.
>> Thanks for te
On Wed, Sep 30, 2020 at 09:01:09AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:34, Nicolin Chen пишет:
> > On Wed, Sep 30, 2020 at 08:10:35AM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 03:30, Nicolin Chen пишет:
> >>> void tegra_smmu_remove(struct tegra_smmu *smmu)
> >>> {
> >>> + bus_set_io
On Wed, 30 Sep 2020 at 02:35, Nicolin Chen wrote:
>
> This can be used by both tegra-smmu and tegra20-devfreq drivers.
>
> Suggested-by: Dmitry Osipenko
> Signed-off-by: Nicolin Chen
> ---
>
> Changelog
> v1->v2
> * N/A
>
> drivers/memory/tegra/mc.c | 23 +++
> include/soc/
On Wed, Sep 30, 2020 at 08:58:50AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:29, Nicolin Chen пишет:
> > Hi Dmitry,
> >
> > On Wed, Sep 30, 2020 at 08:10:07AM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 03:30, Nicolin Chen пишет:
> >>> - group->group = iommu_group_alloc();
> >>> + group->gro
Hi Krzysztof,
On Wed, Sep 30, 2020 at 09:21:39AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 30 Sep 2020 at 02:35, Nicolin Chen wrote:
> >
> > This can be used by both tegra-smmu and tegra20-devfreq drivers.
> >
> > Suggested-by: Dmitry Osipenko
> > Signed-off-by: Nicolin Chen
> > ---
> >
> > C
30.09.2020 09:38, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 09:32:20AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 08:44, Nicolin Chen пишет:
>>> On Wed, Sep 30, 2020 at 08:12:10AM +0300, Dmitry Osipenko wrote:
30.09.2020 03:30, Nicolin Chen пишет:
...
> int tegra_mc_write_emem_c
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still see iova alloc failure even after retry as global
rcache is holding the iova's which can cause
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cached node iova allocation can still fail
because of thi
On Wed, 30 Sep 2020 at 09:31, Nicolin Chen wrote:
>
> Hi Krzysztof,
>
> On Wed, Sep 30, 2020 at 09:21:39AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 30 Sep 2020 at 02:35, Nicolin Chen wrote:
> > >
> > > This can be used by both tegra-smmu and tegra20-devfreq drivers.
> > >
> > > Suggested-by:
Hi Joerg,
Please pull these arm-smmu updates for 5.10. Summary in the tag, but the
big thing here is the long-awaited SVM enablement from Jean-Philippe.
We're not quite done yet, but this pull extends the SMMUv3 driver so that
we're very close to being able to share page-tables directly with the C
This patch simply adds support for PCI devices.
Signed-off-by: Nicolin Chen
---
Changelog
v2->v3
* Replaced ternary conditional operator with if-else in .device_group()
* Dropped change in tegra_smmu_remove()
v1->v2
* Added error-out labels in tegra_smmu_probe()
* Dropped pci_request_acs() s
This series is to add PCI support with three changes:
PATCH-1 adds a helper function to get mc pointer
PATCH-2 adds support for clients that don't exist in DTB
PATCH-3 adds PCI support accordingly
Changelog (Detail in each patch)
v2->v3
* Replaced with devm_tegra_get_memory_controller
* Updated
From: Dmitry Osipenko
Multiple Tegra drivers need to retrieve Memory Controller and hence there
is quite some duplication of the retrieval code among the drivers. Let's
add a new common helper for the retrieval of the MC.
Signed-off-by: Dmitry Osipenko
Signed-off-by: Nicolin Chen
---
Changelo
Previously the driver relies on bus_set_iommu() in .probe() to call
in .probe_device() function so each client can poll iommus property
in DTB to configure fwspec via tegra_smmu_configure(). According to
the comments in .probe(), this is a bit of a hack. And this doesn't
work for a client that does
Just provide a weak default definition of dma_contiguous_early_fixup and
let arm override it.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-contiguous.h | 15 ---
arch/arm/mm/dma-mapping.c | 1 -
include/asm-generic/Kbuild| 1 -
include/asm-g
Hi all,
this series cleans up the dma-mapping headers by moving everything not
required by normal drivers out of into a new
and then folding most other DMA mapping related
headers either into the new dma-map-ops.h one, or by moving them to
kernel/dma/ and thus out of the global scope. A bunch o
Most of the dma_direct symbols should only be used by direct.c and
mapping.c, so move them to kernel/dma. In fact more of dma-direct.h
should eventually move, but that will require more coordination with
other subsystems.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 106 ---
Most of dma-debug.h is not required by anything outside of kernel/dma.
Move the four declarations needed by dma-mappin.h or dma-ops providers
into dma-mapping.h and dma-map-ops.h, and move the remainder of the
file to kernel/dma/debug.h.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/
dma_declare_contiguous is a trivial wrapper around
dma_contiguous_reserve_area and just has a single caller.
Signed-off-by: Christoph Hellwig
---
arch/arm/mach-davinci/devices-da8xx.c | 16 +-
include/linux/dma-contiguous.h| 32 ---
2 files changed, 10
dma_contiguous_set_default contains a trivial assignment, and has a
single caller that is compiled if CONFIG_CMA_DMA is enabled.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-contiguous.h | 7 ---
kernel/dma/contiguous.c| 2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
Move more nitty gritty DMA implementation details into the common
internal header.
Signed-off-by: Christoph Hellwig
---
MAINTAINERS | 1 -
arch/arc/mm/dma.c | 1 -
arch/arm/mm/dma-mapping.c | 1 -
arch/arm/xen/mm.c | 2 +-
arc
Split out all the bits that are purely for dma_map_ops implementations
and related code into a new header so that they
don't get pulled into all the drivers. That also means the architecture
specific is not pulled in by
any more, which leads to a missing includes that were pulled in by the
x86
dev_set_cma_area contains a trivial assignment. It has just three
callers that all have a non-NULL device and depend on CONFIG_DMA_CMA,
so remove the wrapper.
Signed-off-by: Christoph Hellwig
---
arch/arm/mach-davinci/devices-da8xx.c | 2 +-
include/linux/dma-contiguous.h| 8
k
Merge dma-contiguous.h into dma-map-ops.h, after removing the comment
describing the contiguous allocator into kernel/dma/contigous.c.
Signed-off-by: Christoph Hellwig
---
.../admin-guide/kernel-parameters.txt | 2 +-
arch/arm/mach-davinci/devices-da8xx.c | 2 +-
arch/arm/mac
"On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> From: Dmitry Osipenko
>
> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> is quite some duplication of the retrieval code among the drivers. Let's
> add a new common helper for the retrieval of the MC.
>
> Signed-o
On Mon, Sep 28, 2020 at 11:39:02PM +0100, Will Deacon wrote:
> On Mon, Sep 28, 2020 at 06:23:15PM +0100, Will Deacon wrote:
> > On Mon, Sep 28, 2020 at 06:47:31PM +0200, Jean-Philippe Brucker wrote:
> > > On Fri, Sep 18, 2020 at 12:18:40PM +0200, Jean-Philippe Brucker wrote:
> > > > This is version
On Mon, Sep 28, 2020 at 10:43:26PM +, Fenghua Yu wrote:
> Hi, Will and Jean,
>
> On Mon, Sep 28, 2020 at 11:22:51PM +0100, Will Deacon wrote:
> > On Fri, Sep 18, 2020 at 12:18:41PM +0200, Jean-Philippe Brucker wrote:
> > > From: Fenghua Yu
> > >
> > > PASID is shared by all threads in a proc
On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> Previously the driver relies on bus_set_iommu() in .probe() to call
> in .probe_device() function so each client can poll iommus property
> in DTB to configure fwspec via tegra_smmu_configure(). According to
> the comments in .probe(), this is
On Wed, Sep 30, 2020 at 11:21:14AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > Previously the driver relies on bus_set_iommu() in .probe() to call
> > in .probe_device() function so each client can poll iommus property
> > in DTB to configure fwspe
On Wed, Sep 30, 2020 at 11:07:32AM +0200, Krzysztof Kozlowski wrote:
> "On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > From: Dmitry Osipenko
> >
> > Multiple Tegra drivers need to retrieve Memory Controller and hence there
> > is quite some duplication of the retrieval code among the d
Hi Alex,
On 9/29/20 8:18 PM, Alex Williamson wrote:
> On Tue, 29 Sep 2020 09:18:22 +0200
> Auger Eric wrote:
>
>> Hi all,
>>
>> [also correcting some outdated email addresses + adding Lorenzo in cc]
>>
>> On 9/29/20 12:42 AM, Alex Williamson wrote:
>>> On Mon, 28 Sep 2020 21:50:34 +0200
>>> Eric
On Wed, Sep 30, 2020 at 02:40:32AM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 11:21:14AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> > >
> > > Previously the driver relies on bus_set_iommu() in .probe() to call
> > > in .probe_device() functi
On Wed, Sep 30, 2020 at 02:41:45AM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 11:07:32AM +0200, Krzysztof Kozlowski wrote:
> > "On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> > >
> > > From: Dmitry Osipenko
> > >
> > > Multiple Tegra drivers need to retrieve Memory Controller and h
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
> >> #9 is obviously just for the folks interested in IMS
> >>
> >
> > I see that the tip tree (as of 9/29) has most of these patches bu
Hi Jason
On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > Devices on the VMD bus use their own MSI irq domain, but it is not
> > distinguishable from regular PCI/MSI irq domains. This is
On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> Hi Jason
>
> On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > Devices on the VMD bus use their own MSI irq do
+Megha
On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > Hi Jason
> >
> > On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > > From:
...
> +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct tegra_mc *mc;
> + int err;
> +
> + np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> + if (!np)
> +
...
> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>
> - of_node_put(args.np);
> - index++;
> - }
> + /* An invalid mc pointer means mc and smmu drivers are not ready */
> +
On Wed, 30 Sep 2020 at 16:41, Dmitry Osipenko wrote:
>
> ...
> > +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> > +{
> > + struct platform_device *pdev;
> > + struct device_node *np;
> > + struct tegra_mc *mc;
> > + int err;
> > +
> > + np = of_find_ma
...
> +#ifdef CONFIG_PCI
> + if (!iommu_present(&pci_bus_type)) {
In the previous reply you said that you're borrowing this check from the
arm-smmu driver, but arm-smmu also has a similar check for
platform_bus_type, while Tegra SMMU driver doesn't have it. Hence I'm
objecting the necessity o
...
> static int tegra_smmu_attach_dev(struct iommu_domain *domain,
>struct device *dev)
> {
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
> struct tegra_smmu_as *as = to_smmu_as(do
On Wed, Sep 30 2020 at 08:43, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
>> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
>> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
>> >> #9is obviously just for the folks interested in IMS
>> >>
>> >
>>
30.09.2020 17:45, Krzysztof Kozlowski пишет:
> On Wed, 30 Sep 2020 at 16:41, Dmitry Osipenko wrote:
>>
>> ...
>>> +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
>>> +{
>>> + struct platform_device *pdev;
>>> + struct device_node *np;
>>> + struct tegra_mc *mc;
>
On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
> From: Dmitry Osipenko
>
> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> is quite some duplication of the retrieval code among the drivers. Let's
> add a new common helper for the retrieval of the MC.
>
30.09.2020 18:23, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
>> From: Dmitry Osipenko
>>
>> Multiple Tegra drivers need to retrieve Memory Controller and hence there
>> is quite some duplication of the retrieval code among the drivers. Let's
>> add a new
On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote:
> Previously the driver relies on bus_set_iommu() in .probe() to call
> in .probe_device() function so each client can poll iommus property
> in DTB to configure fwspec via tegra_smmu_configure(). According to
> the comments in .probe(),
I'...
>> +struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
>> +struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>
> It looks to me like the only reason why you need this new global API is
> because PCI devices may not have a device tree node with a phandle to
> the IOM
30.09.2020 18:23, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
>> From: Dmitry Osipenko
>>
>> Multiple Tegra drivers need to retrieve Memory Controller and hence there
>> is quite some duplication of the retrieval code among the drivers. Let's
>> add a new
On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote:
> 30.09.2020 18:23, Thierry Reding пишет:
> > On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
> >> From: Dmitry Osipenko
> >>
> >> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> >> is quite
On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote:
> I'...
> >> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
> >> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> >
> > It looks to me like the only reason why you need this new global API is
> > becaus
30.09.2020 19:03, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 18:23, Thierry Reding пишет:
>>> On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
From: Dmitry Osipenko
Multiple Tegra drivers need to retrieve Memor
Hi all,
this series has a bunch of fixups for the noncoherent DMA allocator
rework that recently landed in linux-next.
I think the most important part is that the idea of vmap()ing
non-contiguous allocations in dma_alloc_noncoherent doesn't work very
well after all. It means we can't just rely o
The function has a single caller, so open code it there and take
advantage of the precalculated page count variable.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/dr
Prepare for supporting the DMA_ATTR_NO_KERNEL_MAPPING flag in
dma_alloc_pages.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index b5f20781d3a96f..b5d56810130b22 1006
Check for highmem pages from CMA, just like in the dma_direct_alloc path.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 121a9c1969dd3a..b5f20781d3a96f 100644
--- a/kernel/d
Add a new API that returns a virtually non-contigous array of pages
and dma address. This API is only implemented for dma-iommu and will
not be implemented for non-iommu DMA API instances that have to allocate
contiguous memory. It is up to the caller to check if the API is
available.
The intent
This ensures dma_direct_alloc_pages will use the right gfp mask, as
well as keeping the code for that common.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/kernel/dma/direct
Document the new dma_alloc_pages and dma_free_pages APIs, and fix
up the documentation for dma_alloc_noncoherent and dma_free_noncoherent.
Reported-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
Documentation/core-api/dma-api.rst | 45 ++
1 file changed, 40 in
Use and entirely separate code path for the DMA_ATTR_NO_KERNEL_MAPPING
path. This avoids any confusion about the ret type, and avoids lots of
attr checks and helpers that can be significantly simplified now.
It also ensures that common handling is applied to architetures still
using the arch allo
On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote:
> I'...
> >> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
> >> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> >
> > It looks to me like the only reason why you need this new global API is
> > becaus
It turns out allowing non-contigous allocations here was a rather bad
idea, as we'll now need to define ways to get the pages for mmaping
or dma_buf sharing. Revert this change and stick to the original
concept. A different API for the use case of non-contigous allocations
will be added back late
On Wed, Sep 30, 2020 at 07:06:27PM +0300, Dmitry Osipenko wrote:
> 30.09.2020 19:03, Thierry Reding пишет:
> > On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 18:23, Thierry Reding пишет:
> >>> On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote:
> Fro
30.09.2020 19:15, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 07:06:27PM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 19:03, Thierry Reding пишет:
>>> On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote:
30.09.2020 18:23, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 01:42
30.09.2020 19:06, Thierry Reding пишет:
> On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote:
>> I'...
+ struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>>>
>>> It looks to me like the only reason why
...
>> Secondly, I'm already about to use the new tegra_get_memory_controller()
>> API for all the T20/30/124/210 EMC and devfreq drivers.
>
> Also, this really proves the point I was trying to make about how this
> is going to proliferate...
Sorry, I'm probably totally missing yours point.. "wha
On Wed, Sep 30, 2020 at 07:26:00PM +0300, Dmitry Osipenko wrote:
> 30.09.2020 19:15, Thierry Reding пишет:
> > On Wed, Sep 30, 2020 at 07:06:27PM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 19:03, Thierry Reding пишет:
> >>> On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote:
>
On Wed, Sep 30, 2020 at 07:25:41PM +0300, Dmitry Osipenko wrote:
> 30.09.2020 19:06, Thierry Reding пишет:
> > On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote:
> >> I'...
> +struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
> +struct iommu_fwspe
Hi Thomas/Jason,
On 9/30/2020 8:20 AM, Thomas Gleixner wrote:
On Wed, Sep 30 2020 at 08:43, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
#9 is obviously
...
>> I don't think that the MC driver will stay built-in forever, although
>> its modularization is complicated right now. Hence something shall keep
>> the reference to the MC device resources while they are in use and this
>> patch takes care of doing that.
>
> It looks to me like all the othe
Megha,
On Wed, Sep 30 2020 at 10:25, Megha Dey wrote:
> On 9/30/2020 8:20 AM, Thomas Gleixner wrote:
Your IMS patches? Why do you need something special again?
>
> By IMS patches, I meant your IMS driver patch that was updated (as it
> was untested, it had some compile errors and we removed
On Wed, Sep 30, 2020 at 01:08:27PM +, Derrick, Jonathan wrote:
> +Megha
>
> On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > > Hi Jason
> > >
> > > On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> >
On Wed, Sep 30, 2020 at 05:53:20PM +0300, Dmitry Osipenko wrote:
> ...
> > +#ifdef CONFIG_PCI
> > + if (!iommu_present(&pci_bus_type)) {
>
>
> In the previous reply you said that you're borrowing this check from the
> arm-smmu driver, but arm-smmu also has a similar check for
> platform_bus_typ
On Wed, Sep 30, 2020 at 05:31:31PM +0200, Thierry Reding wrote:
> On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote:
> > Previously the driver relies on bus_set_iommu() in .probe() to call
> > in .probe_device() function so each client can poll iommus property
> > in DTB to configure fws
On Wed, Sep 30, 2020 at 06:09:43PM +0300, Dmitry Osipenko wrote:
> ...
> > static int tegra_smmu_attach_dev(struct iommu_domain *domain,
> > struct device *dev)
> > {
> > + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > struct tegra_smmu *smmu = de
1 - 100 of 114 matches
Mail list logo