On 2021-11-22 17:47, Alex Bee wrote:
Am 22.11.21 um 09:10 schrieb Sascha Hauer:
Hi Alex,
On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:
Hi Sascha,
Am 17.11.21 um 15:33 schrieb Sascha Hauer:
This series adds initial graphics support for the Rockchip RK356[68]
SoCs. Graphics support is based around the VOP2 controller which
replaces the VOP controller found on earlier Rockchip SoCs. The driver
has been tested with HDMI support included in this series and MIPI-DSI
which is not included because it needs some more work. The driver is
taken from the downstream Rockchip kernel and heavily polished, most non
standard features have been removed for now. I tested the driver with
the libdrm modetest utility and also with weston with both pixman and
panfrost driver support. Michael Riesch reported the driver to work on
the RK3566 as well, but device tree support for this SoC is not yet
included in this series.
The HDMI changes are based on patches from Benjamin Gaignard, but
modified a bit as I found out that the HDMI port on the RK3568 only
needs one additional clock, not two. Also I added regulator support
which is needed to get the HDMI up on the rk3568-EVB board.
All review and testing feedback welcome
thanks for working on that - it's very (very,very) much appreciated.
It took me some time to figure it out: It seems rk3568-iommu driver s
broken - I did only get "white noise" when using it alongside vop
(similar like it was reported here before). However: removing the
iommu-property from vop makes it working for me with HDMI output on
quartz64 as well. Could you check if you have the iommu driver in kernel
enabled if it works for you, if the property is present in DT? (I used
5.16-rc1 + this series + [0]).
I have the iommu driver enabled and it works for me. I get this during
boot:
[0.263287] rockchip-vop2 fe040000.vop: Adding to iommu group 0
So I expect it is indeed used.
Also vop mmu seems to have the
power-domain missing in your series (same as downstream) - however
adding that doesn't help much currently.
Probably the power domain gets enabled anyway when the VOP is activated,
so adding it to the iommu won't help anything. Nevertheless it seems
correct to add the property, I'll do so in the next round.
As a sidenote: I verfied this with using Ezequiel's vpu addtion for
RK356x: It did only work when removing the iommu there as well (getting
tons of page faults otherwise) - so iommu driver really seems to broken,
at least for RK3566. (Or I'm a missing a option in kernel config, which
wasn't required for the older iommu version?)
I don't think so. I started from defconfig and disabled other
architectures and unneeded drivers, but I did not enable anything
specific to iommu.
I've found out now that I can make it work with iommu, by limiting the
available memory to something below 4G (I have a 8G board). So there is
something wrong in the driver or somewhere in memory mapping, iommu api
(since it works when using CMA), ... however: it does clearly not relate
to your patch.
FWIW it doesn't surprise me that there might still be bugs lurking in
the IOMMU driver's relatively recent changes for packing 40-bit physical
addresses into 32-bit pagetable entries and registers - that sort of
thing is always tricky to get right. You're correct that that's
something that wants debugging in its own right, though.
Robin.
