On 6/13/23 16:52, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Tue, Jun 13, 2023 at 4:41 PM Philippe CORNU
> <philippe.cornu@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
>>>
>>> ---
>>>
>>> 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@xxxxxxxxxxx>
>> 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
