On 6/13/23 16:52, Michael Nazzareno Trimarchi wrote:

Hi

On Tue, Jun 13, 2023 at 4:41 PM Philippe CORNU
[off-list ref] wrote:

quoted

On 6/9/23 08:20, Dario Binacchi wrote:

quoted

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@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@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel