[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4b5d8872-64bc-34b0-c329-71aea734022a@foss.st.com>
Date: Tue, 13 Jun 2023 18:59:03 +0200
From: Philippe CORNU <philippe.cornu@...s.st.com>
To: Raphael Gallais-Pou <raphael.gallais-pou@...s.st.com>,
Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
CC: Dario Binacchi <dario.binacchi@...rulasolutions.com>,
<linux-kernel@...r.kernel.org>,
Amarula patchwork <linux-amarula@...rulasolutions.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...il.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Yannick Fertre <yannick.fertre@...s.st.com>,
<dri-devel@...ts.freedesktop.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [PATCH v3 4/4] drm/stm: add an option to change FB bpp
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@...s.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@...rulasolutions.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@...s.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 :-)
Powered by blists - more mailing lists