Message-ID: <4059e488-38fe-2b79-191c-6e921f262c9f@tronnes.org>
Date:   Thu, 16 Dec 2021 16:47:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.0
Subject: Re: [PATCH 11/60] drm/gud: Add support for the nomodeset kernel
 parameter
To:     Thomas Zimmermann <tzimmermann@suse.de>,
        Javier Martinez Canillas <javierm@redhat.com>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
References: <20211215010008.2545520-1-javierm@redhat.com>
 <20211215010008.2545520-12-javierm@redhat.com>
 <5b1d9578-1f74-a808-c4d4-6e8c38dd57fc@tronnes.org>
 <041430de-c0a0-d0eb-81d5-eeee3204ce23@suse.de>
From:   =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= <noralf@tronnes.org>
In-Reply-To: <041430de-c0a0-d0eb-81d5-eeee3204ce23@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


Den 16.12.2021 09.20, skrev Thomas Zimmermann:
> Hi
> 
> Am 15.12.21 um 22:37 schrieb Noralf Trønnes:
>>
>>
>> Den 15.12.2021 01.59, skrev Javier Martinez Canillas:
>>> According to disable Documentation/admin-guide/kernel-parameters.txt,
>>> this
>>> parameter can be used to disable kernel modesetting.
>>>
>>> DRM drivers will not perform display-mode changes or accelerated
>>> rendering
>>> and only the systewm system framebuffer will be available if it was
>>> set-up.
>>>
>>> But only a few DRM drivers currently check for nomodeset, make this
>>> driver
>>> to also support the command line parameter.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> ---
>>>
>>
>> I don't understand why this is applicable to USB drivers, there's no way
>> the firmware can setup a framebuffer and continue pushing pixels over
>> USB when Linux has been given control over the USB bus?
>>
>> The same argument goes for the SPI drivers in drm/tiny/ as well.
> 
> The intended semantics of the option is to disable every display output
> except for the buffer provided by the firmware.
> 

If that's the case this patch is:

Acked-by: Noralf Trønnes <noralf@tronnes.org>

> With USB it still would still disable the driver. That's useful if only
> for debugging. There are also systems with hard-wired USB displays where
> one cannot just unplug the adapter.
> 
> Admittedly, USB graphics is a bit of an odd use case, but neither is it
> too far fetched IMHO.
> 
> Best regards
> Thomas
> 
>>
>> Noralf.
>>
>>>   drivers/gpu/drm/gud/gud_drv.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/gud/gud_drv.c
>>> b/drivers/gpu/drm/gud/gud_drv.c
>>> index 3f9d4b9a1e3d..4d253d249512 100644
>>> --- a/drivers/gpu/drm/gud/gud_drv.c
>>> +++ b/drivers/gpu/drm/gud/gud_drv.c
>>> @@ -446,6 +446,9 @@ static int gud_probe(struct usb_interface *intf,
>>> const struct usb_device_id *id)
>>>       u32 *formats;
>>>       int ret, i;
>>>   +    if (drm_firmware_drivers_only())
>>> +        return -ENODEV;
>>> +
>>>       ret = usb_find_bulk_out_endpoint(intf->cur_altsetting, &bulk_out);
>>>       if (ret)
>>>           return ret;
>>>
>