[PATCH] gpu: host1x: Do not setup DMA for virtual devices
Jon Hunter
jonathanh at nvidia.com
Wed Apr 3 10:07:43 UTC 2024
Hi Thierry,
On 15/03/2024 11:25, Jon Hunter wrote:
>
> On 14/03/2024 15:49, Thierry Reding wrote:
>> From: Thierry Reding <treding at nvidia.com>
>>
>> The host1x devices are virtual compound devices and do not perform DMA
>> accesses themselves, so they do not need to be set up for DMA.
>>
>> Ideally we would also not need to set up DMA masks for the virtual
>> devices, but we currently still need those for legacy support on old
>> hardware.
>>
>> Signed-off-by: Thierry Reding <treding at nvidia.com>
>> ---
>> drivers/gpu/host1x/bus.c | 8 --------
>> 1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
>> index 783975d1384f..7c52757a89db 100644
>> --- a/drivers/gpu/host1x/bus.c
>> +++ b/drivers/gpu/host1x/bus.c
>> @@ -351,11 +351,6 @@ static int host1x_device_uevent(const struct
>> device *dev,
>> return 0;
>> }
>> -static int host1x_dma_configure(struct device *dev)
>> -{
>> - return of_dma_configure(dev, dev->of_node, true);
>> -}
>> -
>> static const struct dev_pm_ops host1x_device_pm_ops = {
>> .suspend = pm_generic_suspend,
>> .resume = pm_generic_resume,
>> @@ -369,7 +364,6 @@ const struct bus_type host1x_bus_type = {
>> .name = "host1x",
>> .match = host1x_device_match,
>> .uevent = host1x_device_uevent,
>> - .dma_configure = host1x_dma_configure,
>> .pm = &host1x_device_pm_ops,
>> };
>> @@ -458,8 +452,6 @@ static int host1x_device_add(struct host1x *host1x,
>> device->dev.bus = &host1x_bus_type;
>> device->dev.parent = host1x->dev;
>> - of_dma_configure(&device->dev, host1x->dev->of_node, true);
>> -
>> device->dev.dma_parms = &device->dma_parms;
>> dma_set_max_seg_size(&device->dev, UINT_MAX);
>
>
> Tested-by: Jon Hunter <jonathanh at nvidia.com>
> Acked-by: Jon Hunter <jonathanh at nvidia.com>
I don't see this in -next yet?
Ideally, if we don't see any issues with this we should pull this into
v6.8.y stable branch because I am now seeing the warning there. Should
we apply a fixes tag to this?
Thanks
Jon
--
nvpublic
More information about the dri-devel
mailing list