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.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
