From: Dmitry Osipenko <digetx@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>,
Thierry Reding <thierry.reding@gmail.com>
Cc: devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property
Date: Fri, 25 Sep 2020 16:21:17 +0300 [thread overview]
Message-ID: <70712ca4-8971-3af4-d0d0-b73788d6cfa9@gmail.com> (raw)
In-Reply-To: <484b9e90-7395-6161-577c-4d3f3716997e@arm.com>
25.09.2020 15:39, Robin Murphy пишет:
...
>> IIRC, in the past Robin Murphy was suggesting to read out hardware state
>> early during kernel boot in order to find what regions are in use by
>> hardware.
>
> I doubt I suggested that in general, because I've always firmly believed
> it to be a terrible idea. I've debugged too many cases where firmware or
> kexec has inadvertently left DMA running and corrupted kernel memory, so
> in general we definitely *don't* want to blindly trust random hardware
> state. Anything I may have said in relation to Qualcomm's fundamentally
> broken hypervisor/bootloader setup should not be considered outside that
> specific context ;)
>
> Robin.
>
>> I think it should be easy to do for the display controller since we
>> could check clock and PD states in order to decide whether DC's IO could
>> be accessed and then read out the FB pointer and size. I guess it should
>> take about hundred lines of code.
The active DMA is indeed very dangerous, but it's a bit less dangerous
in a case of read-only DMA.
I got another idea of how we could benefit from the active display
hardware. Maybe we could do the following:
1. Check whether display is active
2. Allocate CMA that matches the FB size
3. Create identity mapping for the CMA
4. Switch display framebuffer to our CMA
5. Create very early simple-framebuffer out of the CMA
6. Once Tegra DRM driver is loaded, it will kick out the simple-fb, and
thus, release temporal CMA and identity mapping.
This will provide us with a very early framebuffer output and it will
work on all devices out-of-the-box!
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-09-25 13:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 12:59 [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Thierry Reding
2020-09-04 12:59 ` [PATCH v2 2/4] iommu: Implement of_iommu_get_resv_regions() Thierry Reding
2020-09-04 12:59 ` [PATCH v2 3/4] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding
2020-09-04 13:00 ` [RFC 4/4] iommu/tegra-smmu: Add support for reserved regions Thierry Reding
2020-09-14 22:08 ` [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Rob Herring
2020-09-15 12:36 ` Thierry Reding
2020-09-24 11:27 ` Thierry Reding
2020-11-05 16:43 ` Thierry Reding
2020-11-05 17:47 ` Robin Murphy
2020-11-06 15:25 ` Thierry Reding
2020-11-10 19:33 ` Thierry Reding
2020-12-17 15:00 ` Thierry Reding
2020-12-18 22:15 ` Rob Herring
2020-12-19 0:49 ` Thierry Reding
2020-09-24 13:23 ` Dmitry Osipenko
2020-09-24 14:01 ` Thierry Reding
2020-09-24 16:23 ` Dmitry Osipenko
2020-09-25 12:39 ` Robin Murphy
2020-09-25 13:21 ` Dmitry Osipenko [this message]
2020-11-05 16:23 ` Thierry Reding
2020-09-25 13:52 ` Dmitry Osipenko
2020-11-05 15:57 ` Thierry Reding
2020-11-05 15:49 ` Thierry Reding
2021-01-12 19:00 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70712ca4-8971-3af4-d0d0-b73788d6cfa9@gmail.com \
--to=digetx@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=thierry.reding@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).