[PATCH v3 4/4] drm/stm: add an option to change FB bpp

[Philippe CORNU]

On 6/13/23 17:26, Raphael Gallais-Pou wrote:
> 
> On 6/13/23 16:52, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Tue, Jun 13, 2023 at 4:41 PM Philippe CORNU
>> <philippe.cornu at foss.st.com> wrote:
>>>
>>>
>>> On 6/9/23 08:20, Dario Binacchi wrote:
>>>> Boards that use the STM32F{4,7} series have limited amounts of RAM. The
>>>> added parameter allows users to size, within certain limits, the memory
>>>> footprint required by the framebuffer.
>>>>
>>>> Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - drop [4/6] dt-bindings: display: simple: add Rocktech RK043FN48H
>>>>     Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next):
>>>>     https://cgit.freedesktop.org/drm/drm-misc/commit/?id=c42a37a27c777d63961dd634a30f7c887949491a
>>>> - drop [5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel
>>>>     Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
>>>>     https://cgit.freedesktop.org/drm/drm-misc/commit/?id=13cdd12a9f934158f4ec817cf048fcb4384aa9dc
>>>>
>>>>    drivers/gpu/drm/stm/drv.c | 8 +++++++-
>>>>    1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
>>>> index 422220df7d8c..65be2b442a6a 100644
>>>> --- a/drivers/gpu/drm/stm/drv.c
>>>> +++ b/drivers/gpu/drm/stm/drv.c
>>>> @@ -30,6 +30,11 @@
>>>>    #define STM_MAX_FB_WIDTH    2048
>>>>    #define STM_MAX_FB_HEIGHT   2048 /* same as width to handle orientation */
>>>>
>>>> +static uint stm_bpp = 16;
>>>> +
>>>> +MODULE_PARM_DESC(bpp, "bits-per-pixel (default: 16)");
>>>> +module_param_named(bpp, stm_bpp, uint, 0644);
>>>> +
>>>>    static const struct drm_mode_config_funcs drv_mode_config_funcs = {
>>>>        .fb_create = drm_gem_fb_create,
>>>>        .atomic_check = drm_atomic_helper_check,
>>>> @@ -93,6 +98,7 @@ static int drv_load(struct drm_device *ddev)
>>>>        ddev->mode_config.min_height = 0;
>>>>        ddev->mode_config.max_width = STM_MAX_FB_WIDTH;
>>>>        ddev->mode_config.max_height = STM_MAX_FB_HEIGHT;
>>>> +     ddev->mode_config.preferred_depth = stm_bpp;
>>>>        ddev->mode_config.funcs = &drv_mode_config_funcs;
>>>>        ddev->mode_config.normalize_zpos = true;
>>>>
>>>> @@ -203,7 +209,7 @@ static int stm_drm_platform_probe(struct platform_device *pdev)
>>>>        if (ret)
>>>>                goto err_put;
>>>>
>>>> -     drm_fbdev_dma_setup(ddev, 16);
>>>> +     drm_fbdev_dma_setup(ddev, stm_bpp);
>>>>
>>>>        return 0;
>>>>
>>> Acked-by: Philippe Cornu <philippe.cornu at foss.st.com>
>>> Many thanks,
>>> Philippe :-)
>>>
>> According to the latest review on usb patchset: "Please do not add new
>> module parameters, this is not the 1990's anymore.
>> We have per-device settings everywhere, this makes that impossible.
>> Just use a DT value, if it is wrong, then fix the DT value!  No need to
>> have the kernel override it, that's not what DT files are for."
> 
> 
> I actually am conflicted about this idea, but I still think that here the best
> option would be to put a device-tree property.
> 
> In which context here the module parameters could be used ? I think a module
> parameter would be quite troublesome for userspace applications in that case.
> 
> 
> Raphaël
> 
>>
>> I think it makes more sense to have dts parameters. Should maybe apply here too
>>
>> Michael

Hi Raphaël & Michael,

Many thanks for your comments.

Dario's usage of this stm driver is STM32 MCUs (STM32F4 & F7...) where, 
sometimes, old userland fbdev-based applications are used, and I imagine 
it is maybe "easier" to use a module parameter (through the kernel 
command line or whatever...) in these use cases (even if using dt is 
always better and not that complex).

Moreover, as I did not find any drm drivers with drm_fbdev_dma_setup() 
using a dt property "as example" (but always hard-coded value), then I 
decided to not block this proposal :)

Thanks to your feedback, I am reconsidering my position. And sorry 
Dario, hope you understand it will take more time for reviewing your patch.

Does anyone have an opinion to share on this point?

Many thanks,
Philippe :-)