Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support

[Robin Murphy <robin.murphy@arm.com>]

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.