On Fri, Jun 15, 2018 at 6:51 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/06/18 17:39, Vicente Bergas wrote:
>> On Wed, Jun 13, 2018 at 12:46 PM, JeffyChen <jeffy.chen at rock-chips.com> wrote:
>>> Hi Marc & Vicente,
>>>
>>> On 06/13/2018 06:26 PM, Marc Zyngier wrote:
>>>>>
>>>>>>
>>>>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>>>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>>>>> @@ -451,6 +451,7 @@
>>>>>> static struct platform_driver rockchip_drm_platform_driver = {
>>>>>> .probe = rockchip_drm_platform_probe,
>>>>>> .remove = rockchip_drm_platform_remove,
>>>>>> + .shutdown = (void (*)(struct platform_device
>>>>>> *))rockchip_drm_platform_remove,
>>>>
>>>> No, please...:-( Provide a wrapper that returns void instead.
>>>
>>>
>>> hmmm, this is just a test only hack, i am thinking maybe
>>> drm_atomic_helper_shutdown is enough for shutdown() ?
>>>
>>>
>>> something like:
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>> @@ -442,6 +442,14 @@ static int rockchip_drm_platform_remove(struct
>>> platform_device *pdev)
>>> return 0;
>>> }
>>>
>>> +static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
>>> +{
>>> + struct drm_device *drm = platform_get_drvdata(pdev);
>>> +
>>> + if (drm)
>>> + drm_atomic_helper_shutdown(drm);
>>> +}
>>> +
>>>
>> Hi,
>> I can confirm that rockchip_drm_platform_shutdown works as fine as
>> rockchip_drm_platform_remove.
>> Just a note: The first time I noticed this error was because it
>> appeared on display, now that the display is off, are we sure the
>> error is fixed?
>> Also, could there be other peripherals that need to be powered off
>> before the iommu?
>> For curiosity: why is the iommu disabled before kexec instead of
>> resetting it after kexec?
>
> Because by the time you're in the new kernel, you've corrupted the page
> tables, accessed peripheral address space, and set the system on fire.
>
> In general, having a DMA master active across something like kexec is a
> pretty fatal issue. And when your boot loader is a Linux kernel using
> kexec, you're really insisting that kexec works correctly.
Is it feasible to place the display memory at a virtual address that
matches the physical address?
