On 5/12/22 22:00, Thierry Reding wrote:
> -277,7 +278,9 @@ static struct iommu_domain *tegra_smmu_domain_alloc(unsigned
> type)
> {
> struct tegra_smmu_as *as;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED &&
> + type != IOMMU_DOMAIN_DMA
On 5/4/22 14:52, Robin Murphy wrote:
> On 2022-05-04 01:52, Dmitry Osipenko wrote:
>> On 4/11/22 16:46, Robin Murphy wrote:
>>> @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct
>>> host1x_device *dev)
>>> struct host1x *host
On 4/11/22 16:46, Robin Murphy wrote:
> @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct
> host1x_device *dev)
> struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
> struct iommu_domain *domain;
>
> + /* For starters, this is moot if no IOMMU is available
amp; iommu_present(_bus_type)) {
> + if (host1x_drm_wants_iommu(dev)) {
> tegra->domain = iommu_domain_alloc(_bus_type);
> if (!tegra->domain) {
> err = -ENOMEM;
Robin, thank you for the updated version. The patch lo
On 4/6/22 21:06, Robin Murphy wrote:
> On 2022-04-06 15:32, Dmitry Osipenko wrote:
>> On 4/5/22 17:19, Robin Murphy wrote:
>>> Remove the pointless check. host1x_drm_wants_iommu() cannot return true
>>> unless an IOMMU exists for the host1x platform device, which
On 4/5/22 17:19, Robin Murphy wrote:
> Remove the pointless check. host1x_drm_wants_iommu() cannot return true
> unless an IOMMU exists for the host1x platform device, which at the moment
> means the iommu_present() test could never fail.
>
> Signed-off-by: Robin Murphy
> ---
>
01.03.2022 19:14, cyn...@kapsi.fi пишет:
> +/* host1x context devices */
> +
> +struct host1x_context {
> + struct host1x *host;
> +
> + refcount_t ref;
> + struct pid *owner;
> +
> + struct device dev;
> + u64 dma_mask;
> + u32 stream_id;
> +};
I'm still not very happy
22.02.2022 13:54, Mikko Perttunen пишет:
> On 2/22/22 12:46, Dmitry Osipenko wrote:
>> 22.02.2022 11:27, Mikko Perttunen пишет:
>>> On 2/21/22 22:10, Dmitry Osipenko wrote:
>>>> 21.02.2022 14:44, Mikko Perttunen пишет:
>>>>> On 2/19/22 20:54, Dmitry Os
22.02.2022 11:27, Mikko Perttunen пишет:
> On 2/21/22 22:10, Dmitry Osipenko wrote:
>> 21.02.2022 14:44, Mikko Perttunen пишет:
>>> On 2/19/22 20:54, Dmitry Osipenko wrote:
>>>> 19.02.2022 21:49, Dmitry Osipenko пишет:
>>>>> 18.02.2022 14:
21.02.2022 14:44, Mikko Perttunen пишет:
> On 2/19/22 20:54, Dmitry Osipenko wrote:
>> 19.02.2022 21:49, Dmitry Osipenko пишет:
>>> 18.02.2022 14:39, Mikko Perttunen пишет:
>>>> +static int vic_get_streamid_offset(struct tegra_drm_client *client)
>>>> +{
21.02.2022 15:06, Mikko Perttunen пишет:
> On 2/19/22 20:35, Dmitry Osipenko wrote:
>> 18.02.2022 14:39, Mikko Perttunen пишет:
>>> + if (context->memory_context &&
>>> context->client->ops->get_streamid_offset) {
>> ^
19.02.2022 21:49, Dmitry Osipenko пишет:
> 18.02.2022 14:39, Mikko Perttunen пишет:
>> +static int vic_get_streamid_offset(struct tegra_drm_client *client)
>> +{
>> +struct vic *vic = to_vic(client);
>> +int err;
>> +
>> +err = vic_lo
18.02.2022 14:39, Mikko Perttunen пишет:
> +static int vic_get_streamid_offset(struct tegra_drm_client *client)
> +{
> + struct vic *vic = to_vic(client);
> + int err;
> +
> + err = vic_load_firmware(vic);
You can't invoke vic_load_firmware() while RPM is suspended. Either
replace
18.02.2022 14:39, Mikko Perttunen пишет:
> + if (context->memory_context &&
> context->client->ops->get_streamid_offset) {
^^^
> + int offset =
> context->client->ops->get_streamid_offset(context->client);
> +
> + if (offset >= 0) {
> +
19.02.2022 20:54, Dmitry Osipenko пишет:
> 18.02.2022 14:39, Mikko Perttunen пишет:
>> +config TEGRA_HOST1X_CONTEXT_BUS
>> +bool
>> +
>> config TEGRA_HOST1X
>> tristate "NVIDIA Tegra host1x driver"
>> depends on ARCH_TEGRA || (ARM
18.02.2022 14:39, Mikko Perttunen пишет:
> +config TEGRA_HOST1X_CONTEXT_BUS
> + bool
> +
> config TEGRA_HOST1X
> tristate "NVIDIA Tegra host1x driver"
> depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
> select DMA_SHARED_BUFFER
> + select TEGRA_HOST1X_CONTEXT_BUS
What is
18.02.2022 14:39, Mikko Perttunen пишет:
> + for (index = 0; index < cdl->len; index++) {
> + struct iommu_fwspec *fwspec;
> +
> + ctx = >devs[index];
> +
> + ctx->host = host1x;
> +
> + device_initialize(>dev);
> +
> +
18.02.2022 14:39, Mikko Perttunen пишет:
...
> +/*
> + * Due to an issue with T194 NVENC, only 38 bits can be used.
> + * Anyway, 256GiB of IOVA ought to be enough for anyone.
> + */
> +static dma_addr_t context_device_dma_mask = DMA_BIT_MASK(38);
s/dma_addr_t/u64/ ? Apparently you should get
14.12.2021 17:53, Mikko Perttunen пишет:
> On 12/14/21 16:35, Dmitry Osipenko wrote:
>> 14.12.2021 11:05, Jon Hunter пишет:
>>> Hi all,
>>>
>>> Still no response on this :-(
>>
>> I see only two patches on Tegra ML and others on DRI ML. Might be go
14.12.2021 11:05, Jon Hunter пишет:
> Hi all,
>
> Still no response on this :-(
I see only two patches on Tegra ML and others on DRI ML. Might be good
to start with re-sending this whole series and CCing MLs properly.
___
iommu mailing list
09.12.2021 23:01, Nicolin Chen пишет:
> On Thu, Dec 09, 2021 at 10:58:32PM +0300, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 09.12.2021 22:54, Nicolin Chen пишет:
>>> On Thu, Dec 09, 2021 at 10:44:25PM +0300,
09.12.2021 22:54, Nicolin Chen пишет:
> On Thu, Dec 09, 2021 at 10:44:25PM +0300, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 09.12.2021 22:24, Nicolin Chen пишет:
>>> On Thu, Dec 09, 2021 at 05:49:09PM +0300,
09.12.2021 22:51, Nicolin Chen пишет:
> On Thu, Dec 09, 2021 at 10:40:42PM +0300, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 09.12.2021 22:32, Nicolin Chen пишет:
>>> On Thu, Dec 09, 2021 at 05:47:18PM +0300,
09.12.2021 22:24, Nicolin Chen пишет:
> On Thu, Dec 09, 2021 at 05:49:09PM +0300, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 09.12.2021 10:38, Nicolin Chen пишет:
>>> +static unsigned long pd_pt_index_iova
09.12.2021 22:32, Nicolin Chen пишет:
> On Thu, Dec 09, 2021 at 05:47:18PM +0300, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 09.12.2021 10:38, Nicolin Chen пишет:
>>> @@ -545,6 +719,15 @@ static void tegra_smmu_de
09.12.2021 10:38, Nicolin Chen пишет:
> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int
> pt_index)
> +{
> + return (pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT |
> +(pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT;
> +}
I'd change the return type
09.12.2021 10:38, Nicolin Chen пишет:
> @@ -545,6 +719,15 @@ static void tegra_smmu_detach_as(struct tegra_smmu *smmu,
> if (group->swgrp != swgrp)
> continue;
> group->as = NULL;
> +
> + if (smmu->debugfs_mappings) {
Do we really need
08.12.2021 11:47, Nicolin Chen пишет:
> static void tegra_smmu_attach_as(struct tegra_smmu *smmu,
>struct tegra_smmu_as *as,
>unsigned int swgroup)
> @@ -517,6 +646,12 @@ static void tegra_smmu_attach_as(struct tegra_smmu *smmu,
>
08.12.2021 11:47, Nicolin Chen пишет:
> + seq_printf(s, "\t\t%-14s | %-4s | %-10s%s | %-10s%s | %-11s\n",
> +"PTE RANGE", "ATTR",
> +"PHYS", sizeof(phys_addr_t) > 4 ? "" : "",
> +"IOVA", sizeof(dma_addr_t)
Hi,
08.12.2021 11:47, Nicolin Chen пишет:
> This patch dumps all active mapping entries from pagetable to a
> debugfs directory named "mappings".
>
> Attaching an example:
>
> [SWGROUP: xusb_host] [as: (id: 5), (attr: R|W|-), (pd_dma:
> 0x80005000)]
> {
> [index: 1023]
23.04.2021 19:32, Thierry Reding пишет:
> From: Navneet Kumar
>
> Allow creating identity and DMA API compatible IOMMU domains. When
> creating a DMA API compatible domain, make sure to also create the
> required cookie.
IOMMU_DOMAIN_DMA should be a disaster. It shouldn't work without
preparing
04.10.2021 22:23, Thierry Reding пишет:
> On Sun, Oct 03, 2021 at 04:09:56AM +0300, Dmitry Osipenko wrote:
>> 23.04.2021 19:32, Thierry Reding пишет:
>>> I've made corresponding changes in the proprietary bootloader, added a
>>> compatibility shim in U-Boot (which f
23.04.2021 19:32, Thierry Reding пишет:
> I've made corresponding changes in the proprietary bootloader, added a
> compatibility shim in U-Boot (which forwards information created by the
> proprietary bootloader to the kernel) and the attached patches to test
> this on Jetson TX1, Jetson TX2 and
15.09.2021 15:09, Dmitry Osipenko пишет:
> 15.09.2021 07:38, Nicolin Chen пишет:
>> On Tue, Sep 14, 2021 at 10:20:30PM +0300, Dmitry Osipenko wrote:
>>> 14.09.2021 21:49, Nicolin Chen пишет:
>>>> On Tue, Sep 14, 2021 at 04:29:15PM +0300, Dmitry Osipenko wrote:
>&g
15.09.2021 07:38, Nicolin Chen пишет:
> On Tue, Sep 14, 2021 at 10:20:30PM +0300, Dmitry Osipenko wrote:
>> 14.09.2021 21:49, Nicolin Chen пишет:
>>> On Tue, Sep 14, 2021 at 04:29:15PM +0300, Dmitry Osipenko wrote:
>>>> 14.09.2021 04:38, Nicolin Chen пише
14.09.2021 21:49, Nicolin Chen пишет:
> On Tue, Sep 14, 2021 at 04:29:15PM +0300, Dmitry Osipenko wrote:
>> 14.09.2021 04:38, Nicolin Chen пишет:
>>> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int
>>> pt_index)
>>> +{
14.09.2021 04:38, Nicolin Chen пишет:
> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int
> pt_index)
> +{
> + return ((dma_addr_t)pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT |
> +((dma_addr_t)pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT;
> +}
We
16.07.2021 17:41, Rob Herring пишет:
> On Fri, Jul 2, 2021 at 8:05 AM Dmitry Osipenko wrote:
>>
>> 23.04.2021 19:32, Thierry Reding пишет:
>>> +void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
>>> +{
>>> + struct
14.07.2021 13:52, Joerg Roedel пишет:
> On Mon, Jul 12, 2021 at 03:13:41AM +0300, Dmitry Osipenko wrote:
>> -err = iommu_device_sysfs_add(>iommu, dev, NULL, dev_name(dev));
>> +err = iommu_device_sysfs_add(>iommu, dev, NULL, "smmu");
>
> Are you sure
Change debugfs directory name to "smmu", which is a much more obvious name
than the generic name of the memory controller device-tree node.
Signed-off-by: Dmitry Osipenko
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i
01.07.2021 21:14, Thierry Reding пишет:
> On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
>> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
>>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote:
On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry
23.04.2021 19:32, Thierry Reding пишет:
> +void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
> +{
> + struct of_phandle_iterator it;
> + int err;
> +
> + of_for_each_phandle(, err, dev->of_node, "memory-region",
> "#memory-region-cells", 0) {
> +
29.04.2021 08:51, Krishna Reddy пишет:
> Hi Dmitry,
>
>> Thank you for the answer. Could you please give more information about:
>> 1) Are you on software or hardware team, or both?
>
> I am in the software team and has contributed to initial Tegra SMMU driver in
> the downstream along with
28.04.2021 08:57, Mikko Perttunen пишет:
> On 4/28/21 8:51 AM, Dmitry Osipenko wrote:
>> 23.04.2021 19:32, Thierry Reding пишет:
>>> Note that there will be no new releases of the bootloader for earlier
>>> devices, so adding support for these new DT binding
23.04.2021 19:32, Thierry Reding пишет:
> Note that an earlier proposal was to use the existing simple-framebuffer
> device tree bindings to transport this information. Unfortunately there
> are cases where this is not enough. On Tegra SoCs, for example, the
> bootloader will also set up a color
23.04.2021 19:32, Thierry Reding пишет:
> Note that there will be no new releases of the bootloader for earlier
> devices, so adding support for these new DT bindings will not be
> practical. The bootloaders on those devices do pass information about
> the active framebuffer via the kernel
27.04.2021 21:30, Krishna Reddy пишет:
>> Is it always safe to enable SMMU ASID in a middle of a DMA request made by a
>> memory client?
>
> From MC point of view, It is safe to enable and has been this way from many
> years in downstream code for display engine.
> It doesn't impact the
26.04.2021 10:14, Thierry Reding пишет:
> On Sat, Apr 24, 2021 at 11:27:10PM +0300, Dmitry Osipenko wrote:
>> 23.04.2021 18:23, Dmitry Osipenko пишет:
>>> 23.04.2021 18:01, Guillaume Tucker пишет:
>>>> On 02/04/2021 15:40, Dmitry Osipenko wrote:
>>>
24.04.2021 23:27, Dmitry Osipenko пишет:
> 23.04.2021 18:23, Dmitry Osipenko пишет:
>> 23.04.2021 18:01, Guillaume Tucker пишет:
>>> On 02/04/2021 15:40, Dmitry Osipenko wrote:
>>>> 01.04.2021 11:55, Nicolin Chen пишет:
>>>>> On Mon, Mar 29, 20
23.04.2021 18:23, Dmitry Osipenko пишет:
> 23.04.2021 18:01, Guillaume Tucker пишет:
>> On 02/04/2021 15:40, Dmitry Osipenko wrote:
>>> 01.04.2021 11:55, Nicolin Chen пишет:
>>>> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote:
>>>>> Th
23.04.2021 19:32, Thierry Reding пишет:
> Hi,
>
> this is an updated proposal to solve the problem of passing memory
> regions that are actively being accessed during boot. The particular
> use-case that I need this for is when the bootloader has set up the
> display controller to scan out a boot
23.04.2021 18:01, Guillaume Tucker пишет:
> On 02/04/2021 15:40, Dmitry Osipenko wrote:
>> 01.04.2021 11:55, Nicolin Chen пишет:
>>> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote:
>>>> The previous commit fixes problem where display client was att
08.04.2021 17:07, Dmitry Osipenko пишет:
>> Whatever happened to the idea of creating identity mappings based on the
>> obscure tegra_fb_mem (or whatever it was called) command-line option? Is
>> that command-line not universally passed to the kernel from bootloaders
>>
08.04.2021 16:26, Thierry Reding пишет:
> On Thu, Apr 08, 2021 at 02:42:42AM -0700, Nicolin Chen wrote:
>> On Mon, Mar 29, 2021 at 02:32:55AM +0300, Dmitry Osipenko wrote:
>>> All consumer-grade Android and Chromebook devices show a splash screen
>>> on boot and then d
08.04.2021 15:40, Thierry Reding пишет:
> On Mon, Mar 29, 2021 at 02:32:55AM +0300, Dmitry Osipenko wrote:
>> All consumer-grade Android and Chromebook devices show a splash screen
>> on boot and then display is left enabled when kernel is booted. This
>> behaviour is u
01.04.2021 11:55, Nicolin Chen пишет:
> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote:
>> The previous commit fixes problem where display client was attaching too
>> early to IOMMU during kernel boot in a multi-platform kernel configuration
&
perform DMA at that time. We can work around this problem
by deferring the enable of SMMU translation for a specific devices,
like a display controller, until the first IOMMU mapping is created,
which works good enough in practice because by that time h/w is already
stopped.
Signed-off-by: Dmitry
,
revert it.
Signed-off-by: Dmitry Osipenko
---
drivers/iommu/tegra-smmu.c | 71 +-
1 file changed, 1 insertion(+), 70 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index af1e4b5adb27..572a4544ae88 100644
--- a/drivers/iommu/tegra
28.03.2021 18:25, Dmitry Osipenko пишет:
> 03.03.2021 12:47, Dmitry Osipenko пишет:
>> 03.03.2021 02:08, Nicolin Chen пишет:
>>> On Sat, Feb 27, 2021 at 12:59:17PM +0300, Dmitry Osipenko wrote:
>>>> 25.02.2021 09:27, Nicolin Chen пишет:
>>>> ...
>>&g
03.03.2021 12:47, Dmitry Osipenko пишет:
> 03.03.2021 02:08, Nicolin Chen пишет:
>> On Sat, Feb 27, 2021 at 12:59:17PM +0300, Dmitry Osipenko wrote:
>>> 25.02.2021 09:27, Nicolin Chen пишет:
>>> ...
>>>>> The partially revert should be okay, but it's n
26.03.2021 19:55, Dmitry Osipenko пишет:
> 26.03.2021 19:35, Thierry Reding пишет:
>> On Fri, Mar 26, 2021 at 06:29:28PM +0300, Dmitry Osipenko wrote:
>>> 25.03.2021 16:03, Thierry Reding пишет:
>>>> From: Thierry Reding
>>>>
>>>> Hi,
26.03.2021 19:35, Thierry Reding пишет:
> On Fri, Mar 26, 2021 at 06:29:28PM +0300, Dmitry Osipenko wrote:
>> 25.03.2021 16:03, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> Hi,
>>>
>>> this is a set of patches that is the resu
25.03.2021 16:03, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi,
>
> this is a set of patches that is the result of earlier discussions
> regarding early identity mappings that are needed to avoid SMMU faults
> during early boot.
>
> The goal here is to avoid early identity mappings
25.03.2021 19:11, Dmitry Osipenko пишет:
> 25.03.2021 18:52, Thierry Reding пишет:
>> On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote:
>>> 25.03.2021 16:03, Thierry Reding пишет:
>>>> From: Thierry Reding
>>>>
>>>> From Teg
25.03.2021 18:52, Thierry Reding пишет:
> On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote:
>> 25.03.2021 16:03, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> From Tegra20 through Tegra210, either the GART or SMMU drivers need
>&
25.03.2021 16:03, Thierry Reding пишет:
> From: Thierry Reding
>
> From Tegra20 through Tegra210, either the GART or SMMU drivers need
> access to the internals of the memory controller driver because they are
> tightly coupled (in fact, the GART and SMMU are part of the memory
> controller). On
16.03.2021 14:16, Thierry Reding пишет:
>> +seq_puts(s, "}\n");
>> +seq_printf(s, "Total PDE count: %u\n", pde_count);
>> +seq_printf(s, "Total PTE count: %llu\n", pte_count);
> Some of the above looks like it wouldn't be very easily consumed by
> scripts. Is that something we want to
15.03.2021 23:36, Nicolin Chen пишет:
> +static int tegra_smmu_mappings_show(struct seq_file *s, void *data)
> +{
> + struct tegra_smmu_group_debug *group_debug = s->private;
> + const struct tegra_smmu_swgroup *group;
> + struct tegra_smmu_as *as;
> + struct tegra_smmu *smmu;
> +
15.03.2021 23:36, Nicolin Chen пишет:
> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int
> pt_index)
> +{
> + return ((dma_addr_t)pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT |
> +((dma_addr_t)pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT;
> +}
Total PDE count: 1
> Total PTE count: 1
>
> Signed-off-by: Nicolin Chen
> ---
Good to me, thanks.
Tested-by: Dmitry Osipenko
Reviewed-by: Dmitry Osipenko
> + for (pd_index = 0; pd_index < SMMU_NUM_PDE; pd_index++) {
> + struct page *pt_page;
> +
14.03.2021 11:06, Nicolin Chen пишет:
> + for (pd_index = 0; pd_index < SMMU_NUM_PDE; pd_index++) {
> + struct page *pt_page;
> + u32 *addr;
> + int i;
unsigned int
and then printf specifiers also should be %u
14.03.2021 11:06, Nicolin Chen пишет:
> This patch dumps all active mapping entries from pagetable
> to a debugfs directory named "mappings".
>
> Ataching an example:
>
> SWGROUP: hc
> ASID: 0
> reg: 0x250
> PTB_ASID: 0xe0080004
> as->pd_dma: 0x80004000
> {
> [1023] 0xf008000b (1)
>
Signed-off-by: Dmitry Osipenko
---
drivers/iommu/tegra-smmu.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 97eb62f667d2..602aab98c079 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
10.03.2021 06:36, Nicolin Chen пишет:
...
> +static int tegra_smmu_mappings_show(struct seq_file *s, void *data)
> +{
> + struct tegra_smmu_group_debug *group_debug = s->private;
> + const struct tegra_smmu_swgroup *group;
> + struct tegra_smmu_as *as;
> + struct tegra_smmu *smmu;
11.03.2021 01:17, Nicolin Chen пишет:
> On Wed, Mar 10, 2021 at 11:22:57PM +0300, Dmitry Osipenko wrote:
>> 10.03.2021 22:13, Dmitry Osipenko пишет:
>>> I found that this patch introduced a serious regression on Tegra30 using
>>> today's linux-next. Tegra30 has two 3d
10.03.2021 06:36, Nicolin Chen пишет:
> This patch dumps all active mapping entries from pagetable
> to a debugfs directory named "mappings".
>
> Ataching an example:
>
> SWGROUP: hc
> ASID: 0
> reg: 0x250
> PTB_ASID: 0xe0080004
> as->pd_dma: 0x80004000
> {
> [1023] 0xf0080013 (1)
>
10.03.2021 22:13, Dmitry Osipenko пишет:
> 19.02.2021 01:07, Nicolin Chen пишет:
>> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
>> removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
>> of_xlate SMMU's S
19.02.2021 01:07, Nicolin Chen пишет:
> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
> removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
> of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and
> tegra_smmu_configure() that
03.03.2021 02:08, Nicolin Chen пишет:
> On Sat, Feb 27, 2021 at 12:59:17PM +0300, Dmitry Osipenko wrote:
>> 25.02.2021 09:27, Nicolin Chen пишет:
>> ...
>>>> The partially revert should be okay, but it's not clear to me what makes
>>>> difference for T12
25.02.2021 09:27, Nicolin Chen пишет:
...
>> The partially revert should be okay, but it's not clear to me what makes
>> difference for T124 since I don't see that problem on T30, which also
>> has active display at a boot time.
>
> Hmm..do you see ->attach_dev() is called from
23.02.2021 05:13, Nicolin Chen пишет:
> Hi Dmitry,
>
> On Sat, Feb 20, 2021 at 08:16:22AM +0300, Dmitry Osipenko wrote:
>> 19.02.2021 01:07, Nicolin Chen пишет:
>>> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
>>> r
19.02.2021 01:07, Nicolin Chen пишет:
> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
> removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
> of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and
> tegra_smmu_configure() that
05.11.2020 18:49, Thierry Reding пишет:
> On Thu, Sep 24, 2020 at 07:23:34PM +0300, Dmitry Osipenko wrote:
>> 24.09.2020 17:01, Thierry Reding пишет:
>>> On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote:
>>>> 04.09.2020 15:59, Thierry Reding пиш
25.11.2020 00:21, Nicolin Chen пишет:
> Hi Joerg,
>
> These five patches were acked by Thierry and acked-n-tested by
> Dmitry a while ago. Would it be possible for you to apply them?
>
> Thanks!
Hi,
You probably should try to ping Will Deacon.
https://lkml.org/lkml/2020/11/17/243
05.10.2020 14:15, Thierry Reding пишет:
> On Mon, Oct 05, 2020 at 01:36:55PM +0300, Dmitry Osipenko wrote:
>> 05.10.2020 12:53, Thierry Reding пишет:
>>> On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote:
>>>> 02.10.2020 17:22, Dmitry Osip
05.10.2020 12:53, Thierry Reding пишет:
> On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote:
>> 02.10.2020 17:22, Dmitry Osipenko пишет:
>>>> static int tegra_smmu_of_xlate(struct device *dev,
>>>> struct of_phandle_a
05.10.2020 12:16, Thierry Reding пишет:
...
>> I think you meant regmap in regards to protecting IO accesses, but this
>> is not what regmap is about if IO accesses are atomic by nature.
>
> Then why is there regmap-mmio?
To protect programming sequences for example, actually that's the only
05.10.2020 00:57, Nicolin Chen пишет:
> On Sat, Oct 03, 2020 at 05:06:42PM +0300, Dmitry Osipenko wrote:
>> 03.10.2020 09:59, Nicolin Chen пишет:
>>> static int tegra_smmu_of_xlate(struct device *dev,
>>>struct of_phandle_args *
05.10.2020 10:13, Thierry Reding пишет:
...
> Have you also seen that sun50i-iommu does look up the SMMU from a
> phandle using of_find_device_by_node()? So I think you've shown yourself
> that even "modern" drivers avoid global pointers and look up via
> phandle.
I have no problem with the
29.09.2020 20:41, Dmitry Osipenko пишет:
> 29.09.2020 09:13, Nicolin Chen пишет:
>> The tegra_smmu_group_get was added to group devices in different
>> SWGROUPs and it'd return a NULL group pointer upon a mismatch at
>> tegra_smmu_find_group(), so for most of clients/devic
29.09.2020 20:42, Dmitry Osipenko пишет:
> 29.09.2020 09:13, Nicolin Chen пишет:
>> This is used to protect potential race condition at use_count.
>> since probes of client drivers, calling attach_dev(), may run
>> concurrently.
>>
>> Signed-off-by: Nicolin Che
i2c: Adding to iommu group 0
> tegra-i2c 7000c500.i2c: Adding to iommu group 0
> tegra-i2c 7000d000.i2c: Adding to iommu group 0
> tegra-pcie 1003000.pcie: Adding to iommu group 1
> ...
>
> Note that dmesg log above
03.10.2020 09:59, Nicolin Chen пишет:
> This patch simply adds support for PCI devices.
>
> Signed-off-by: Nicolin Chen
> Reviewed-by: Dmitry Osipenko
Small nit: yours s-b tag always should be the last line of the commit
message because you're "signing up" words th
patch. But I'm not a maintainer of the SMMU driver, hence will leave it
up to Thierry and Joerg to decide whether this is good or needs to be
improved.
Otherwise this patch is good to me, thanks. I tested it on Nexus 7,
which is Tegra30.
Reviewed-by:
03.10.2020 09:59, Nicolin Chen пишет:
> ubuntu@jetson:~$ dmesg | grep iommu
> iommu: Default domain type: Translated
> tegra-i2c 7000c400.i2c: Adding to iommu group 0
> tegra-i2c 7000c500.i2c: Adding to iommu group 0
> tegra-i2c 7000d000.i2c: Adding to iommu group 0
>
03.10.2020 09:59, Nicolin Chen пишет:
> static int tegra_smmu_of_xlate(struct device *dev,
> struct of_phandle_args *args)
> {
> + struct platform_device *iommu_pdev = of_find_device_by_node(args->np);
> + struct tegra_mc *mc =
03.10.2020 02:53, Nicolin Chen пишет:
> On Fri, Oct 02, 2020 at 11:12:18PM +0300, Dmitry Osipenko wrote:
>> 02.10.2020 22:45, Nicolin Chen пишет:
>>> On Fri, Oct 02, 2020 at 05:41:50PM +0300, Dmitry Osipenko wrote:
>>>> 02.10.2020 09:08, Nicolin Chen пишет:
>>&
02.10.2020 22:45, Nicolin Chen пишет:
> On Fri, Oct 02, 2020 at 05:41:50PM +0300, Dmitry Osipenko wrote:
>> 02.10.2020 09:08, Nicolin Chen пишет:
>>> static int tegra_smmu_attach_dev(struct iommu_domain *domain,
>>> struct device
02.10.2020 21:01, Nicolin Chen пишет:
> On Fri, Oct 02, 2020 at 05:23:14PM +0300, Dmitry Osipenko wrote:
>> 02.10.2020 09:08, Nicolin Chen пишет:
>>> static struct iommu_device *tegra_smmu_probe_device(struct device *dev)
>>> {
>>> - struct device_nod
02.10.2020 09:08, Nicolin Chen пишет:
> This patch simply adds support for PCI devices.
>
> Signed-off-by: Nicolin Chen
> ---
Reviewed-by: Dmitry Osipenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfo
1 - 100 of 390 matches
Mail list logo
