Re: DRM FB emulation initialisation leaving the display disabled
Hi Dave
Am 11.10.23 um 17:52 schrieb Dave Stevenson:
Hi Thomas (and everyone else)
Maxime has suggested you're the person for DRM framebuffer emulation.
I'm getting some unexpected behaviour when there are multiple DRM
drivers in play. In this case it happens to be vc4 and the tiny
hx8357d SPI display driver, but this affects most of the tiny DRM
drivers and also the DSI and DPI outputs on the Pi5.
We get different behaviour depending on whether vc4 or hx8357d
initialises first.
If hx8357d loads first and registers as /dev/fb0 through the fb
emulation, then we get fbcon enabling the display and putting the
emulated framebuffer on it. vc4 then loads, registers /dev/fb1, and
through the hotplug handler it enables the display
(drm_fb_helper_hotplug_event calls, drm_fb_helper_set_par, which calls
__drm_fb_helper_restore_fbdev_mode_unlocked).
If vc4 loads first and claims /dev/fb0, fbcon initalises and enables
the display. hx8357d then loads and registers as /dev/fb1. fbcon is
not configured for that fb, and there is no subsequent hotplug event
(SPI displays aren't hotpluggable), so we have a fully configured
framebuffer exposed to userspace but the display itself isn't enabled
so we don't see anything :-(
Open and close /dev/dri/card1 and the lastclose hook calls
drm_fb_helper_restore_fbdev_mode_unlocked and we get the display
enabled.
What you're describing sounds like the recent bug report at
https://gitlab.freedesktop.org/drm/amd/-/issues/2649
which had similar symptoms with amdgpu. IIRC the console didn't
initialize if the DRM hotplugging event happened before fbdev emulation
was ready. DRM's fbdev code would then not see the hotplugged connector.
Do you have commit 27655b9bb9f0 ("drm/client: Send hotplug event after
registering a client") in your tree? (It's been ported into various
stable branches as well.)
Best regard
Thomas
Is it intentional that we're left in this limbo state with the display
not enabled if fbcon isn't enabled on a framebuffer?
We're trying to get people to transition from the fbdev drivers to DRM
equivalents, but this seems to be a backwards step if there is an
extra step required to get the display enabled. Many users are still
just using the framebuffer.
Any input is much appreciated.
Thanks,
Dave
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On 12/10/2023 08:54, Yong Wu (吴勇) wrote: > > Thanks Jeffrey for the addition. > > Hi Rob, krzysztof, > > Just a ping. Is Jeffrey's reply ok for you? I did not see any patch posted and I am way behind reviewing patches to review also non-patches-patches... Best regards, Krzysztof
Re: linux-next: build failure after merge of the drm-misc tree
On Thu, Oct 12, 2023 at 12:27:49PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 12 Oct 2023 12:22:09 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/usb/typec/altmodes/displayport.c: In function 'dp_altmode_vdm':
> > drivers/usb/typec/altmodes/displayport.c:309:33: error: too few arguments
> > to function 'drm_connector_oob_hotplug_event'
> > 309 |
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > | ^~~
> > In file included from drivers/usb/typec/altmodes/displayport.c:17:
> > include/drm/drm_connector.h:1984:6: note: declared here
> > 1984 | void drm_connector_oob_hotplug_event(struct fwnode_handle
> > *connector_fwnode,
> > | ^~~
> >
> > Caused by commit
> >
> > fc93835bb0d7 ("drm: Add HPD state to drm_connector_oob_hotplug_event()")
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > from the usb.current tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Thu, 12 Oct 2023 12:17:31 +1100
> > Subject: [PATCH] fix up for "drm: Add HPD state to
> > drm_connector_oob_hotplug_event()"
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/usb/typec/altmodes/displayport.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/typec/altmodes/displayport.c
> > b/drivers/usb/typec/altmodes/displayport.c
> > index ddfb5b6ace4f..eb0bf08fc97a 100644
> > --- a/drivers/usb/typec/altmodes/displayport.c
> > +++ b/drivers/usb/typec/altmodes/displayport.c
> > @@ -306,7 +306,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
> > dp->data.status = 0;
> > dp->data.conf = 0;
> > if (dp->hpd) {
> > -
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > +
> > drm_connector_oob_hotplug_event(dp->connector_fwnode
>
> Pretend that there is a comma at the end of the above line :-)
Looks good to me, thanks!
greg k-h
Re: [PATCH v2 5/6] dt-bindings: display: Split common Solomon properties in their own schema
On Thu, 12 Oct 2023 08:58:14 +0200, Javier Martinez Canillas wrote: > There are DT properties that can be shared across different Solomon OLED > Display Controller families. Split them into a separate common schema to > avoid these properties to be duplicated in different DT bindings schemas. > > Suggested-by: Rob Herring > Signed-off-by: Javier Martinez Canillas > --- > > (no changes since v1) > > .../bindings/display/solomon,ssd-common.yaml | 42 +++ > .../bindings/display/solomon,ssd1307fb.yaml | 28 + > MAINTAINERS | 1 + > 3 files changed, 44 insertions(+), 27 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd-common.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/solomon,ssd-common.yaml:42:27: [error] no new line character at the end of file (new-line-at-end-of-file) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231012065822.1007930-6-javi...@redhat.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 2/6] drm/ssd130x: Add a per controller family functions table
Hi Javier
Am 12.10.23 um 08:58 schrieb Javier Martinez Canillas:
[...]
+struct ssd130x_funcs {
+ int (*init)(struct ssd130x_device *ssd130x);
+ int (*set_buffer_sizes)(struct ssd130x_device *ssd130x);
+ void (*align_rect)(struct ssd130x_device *ssd130x, struct drm_rect
*rect);
+ int (*update_rect)(struct ssd130x_device *ssd130x, struct drm_rect
*rect,
+ u8 *buf, u8 *data_array);
+ void (*clear_screen)(struct ssd130x_device *ssd130x,
+u8 *data_array);
+ void (*fmt_convert)(struct iosys_map *dst, const unsigned int
*dst_pitch,
+ const struct iosys_map *src, const struct
drm_framebuffer *fb,
+ const struct drm_rect *clip);
+};
+
You are reinventing DRM's atomic helpers. I strongly advised against
doing that, as it often turns out bad. Maybe see my rant at [1] wrt to
another driver.
It's much better to create a separate mode-setting pipeline for the
ssd132x series and share the common code among pipelines. Your driver
will have a clean and readable implementation for each supported
chipset. Compare an old version of mgag200 [2] with the current driver
to see the difference.
Best regards
Thomas
[1]
https://lore.kernel.org/dri-devel/07cc89a5-5200-72e6-f078-694c5820a...@suse.de/
[2] https://elixir.bootlin.com/linux/v5.5/source/drivers/gpu/drm/mgag200
extern const struct ssd130x_deviceinfo ssd130x_variants[];
struct ssd130x_device *ssd130x_probe(struct device *dev, struct regmap *regmap);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH v10 02/16] drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common()
Re: [PATCH v10 01/16] drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters
Re: [PATCH] iosys-map: fix kernel-doc typos
Hi, sorry, I missed this patch at first. Am 01.10.23 um 00:14 schrieb Randy Dunlap: Correct spelling of "beginning". Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Reviewed-by: Thomas Zimmermann --- include/linux/iosys-map.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -426,7 +426,7 @@ static inline void iosys_map_memset(stru * iosys_map_rd_field - Read a member from a struct in the iosys_map * * @map__:The iosys_map structure - * @struct_offset__: Offset from the beggining of the map, where the struct + * @struct_offset__: Offset from the beginning of the map, where the struct *is located * @struct_type__:The struct describing the layout of the mapping * @field__: Member of the struct to read @@ -494,7 +494,7 @@ static inline void iosys_map_memset(stru * iosys_map_wr_field - Write to a member of a struct in the iosys_map * * @map__:The iosys_map structure - * @struct_offset__: Offset from the beggining of the map, where the struct + * @struct_offset__: Offset from the beginning of the map, where the struct *is located * @struct_type__:The struct describing the layout of the mapping * @field__: Member of the struct to read -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 4/6] drm/ssd130x: Add support for the SSD132x OLED controller family
Hi Javier,
On Thu, Oct 12, 2023 at 8:58 AM Javier Martinez Canillas
wrote:
> The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327)
> are used by 16 grayscale dot matrix OLED panels, extend the driver to also
> support this chip family.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes in v2:
> - Align the rectangle to the segment width (Geert Uytterhoeven).
Thanks for the update!
> --- a/drivers/gpu/drm/solomon/ssd130x.c
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> +static int ssd132x_update_rect(struct ssd130x_device *ssd130x,
> + struct drm_rect *rect, u8 *buf,
> + u8 *data_array)
> +{
> + unsigned int x = rect->x1;
> + unsigned int y = rect->y1;
> + unsigned int segment_width = SSD132X_SEGMENT_WIDTH;
> + unsigned int width = drm_rect_width(rect);
> + unsigned int height = drm_rect_height(rect);
> + unsigned int columns = DIV_ROUND_UP(width, segment_width);
> + unsigned int rows = height;
> + struct drm_device *drm = &ssd130x->drm;
> + u32 array_idx = 0;
> + int ret, i, j;
unsigned int i, j;
> +
> + drm_WARN_ONCE(drm, x % segment_width != 0, "x must be aligned to
> screen segment\n");
> +
> + /*
> +* The screen is divided in Segment and Common outputs, where
> +* COM0 to COM[N - 1] are the rows and SEG0 to SEG[M - 1] are
> +* the columns.
> +*
> +* Each Segment has a 4-bit pixel and each Common output has a
> +* row of pixels. When using the (default) horizontal address
> +* increment mode, each byte of data sent to the controller has
> +* two Segments (e.g: SEG0 and SEG1) that are stored in the lower
> +* and higher nibbles of a single byte representing one column.
> +* That is, the first byte are SEG0 (D0[3:0]) and SEG1 (D0[7:4]),
> +* the second byte are SEG2 (D1[3:0]) and SEG3 (D1[7:4]) and so on.
> +*/
> +
> + /* Set column start and end */
> + ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_COL_RANGE, x /
> segment_width, columns - 1);
> + if (ret < 0)
> + return ret;
> +
> + /* Set row start and end */
> + ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_ROW_RANGE, y, rows -
> 1);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; i < height; i++) {
> + /* Process pair of pixels and combine them into a single byte
> */
> + for (j = 0; j < width; j += segment_width) {
> + u8 n1 = buf[i * width + j];
> + u8 n2 = buf[i * width + j + 1];
> +
> + data_array[array_idx++] = (n2 << 4) | n1;
> + }
> + }
> +
> + /* Write out update in one go since horizontal addressing mode is
> used */
> + ret = ssd130x_write_data(ssd130x, data_array, columns * rows);
> +
> + return ret;
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 5/6] dt-bindings: display: Split common Solomon properties in their own schema
Hi Javier,
On Thu, Oct 12, 2023 at 8:58 AM Javier Martinez Canillas
wrote:
> There are DT properties that can be shared across different Solomon OLED
> Display Controller families. Split them into a separate common schema to
> avoid these properties to be duplicated in different DT bindings schemas.
>
> Suggested-by: Rob Herring
> Signed-off-by: Javier Martinez Canillas
> ---
>
> (no changes since v1)
New patch in v2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm: Do not overrun array in drm_gem_get_pages()
On čtvrtek 5. října 2023 15:56:47 CEST Matthew Wilcox (Oracle) wrote:
> If the shared memory object is larger than the DRM object that it backs,
> we can overrun the page array. Limit the number of pages we install
> from each folio to prevent this.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Reported-by: Oleksandr Natalenko
> Tested-by: Oleksandr Natalenko
> Link: https://lore.kernel.org/lkml/13360591.ulzwgnk...@natalenko.name/
> Fixes: 3291e09a4638 ("drm: convert drm_gem_put_pages() to use a folio_batch")
> Cc: sta...@vger.kernel.org # 6.5.x
> ---
> drivers/gpu/drm/drm_gem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6129b89bb366..44a948b80ee1 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -540,7 +540,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object
> *obj)
> struct page **pages;
> struct folio *folio;
> struct folio_batch fbatch;
> - int i, j, npages;
> + long i, j, npages;
>
> if (WARN_ON(!obj->filp))
> return ERR_PTR(-EINVAL);
> @@ -564,11 +564,13 @@ struct page **drm_gem_get_pages(struct drm_gem_object
> *obj)
>
> i = 0;
> while (i < npages) {
> + long nr;
> folio = shmem_read_folio_gfp(mapping, i,
> mapping_gfp_mask(mapping));
> if (IS_ERR(folio))
> goto fail;
> - for (j = 0; j < folio_nr_pages(folio); j++, i++)
> + nr = min(npages - i, folio_nr_pages(folio));
> + for (j = 0; j < nr; j++, i++)
> pages[i] = folio_file_page(folio, i);
>
> /* Make sure shmem keeps __GFP_DMA32 allocated pages in the
>
Gentle ping. It would be nice to have this picked so that it gets into the
stable kernel rather sooner than later.
Thanks.
--
Oleksandr Natalenko (post-factum)
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v2 2/6] drm/ssd130x: Add a per controller family functions table
Thomas Zimmermann writes:
Hello Thomas,
Thanks a lot for your feedback.
> Hi Javier
>
> Am 12.10.23 um 08:58 schrieb Javier Martinez Canillas:
> [...]
>>
>> +struct ssd130x_funcs {
>> +int (*init)(struct ssd130x_device *ssd130x);
>> +int (*set_buffer_sizes)(struct ssd130x_device *ssd130x);
>> +void (*align_rect)(struct ssd130x_device *ssd130x, struct drm_rect
>> *rect);
>> +int (*update_rect)(struct ssd130x_device *ssd130x, struct drm_rect
>> *rect,
>> + u8 *buf, u8 *data_array);
>> +void (*clear_screen)(struct ssd130x_device *ssd130x,
>> + u8 *data_array);
>> +void (*fmt_convert)(struct iosys_map *dst, const unsigned int
>> *dst_pitch,
>> +const struct iosys_map *src, const struct
>> drm_framebuffer *fb,
>> +const struct drm_rect *clip);
>> +};
>> +
>
> You are reinventing DRM's atomic helpers. I strongly advised against
> doing that, as it often turns out bad. Maybe see my rant at [1] wrt to
> another driver.
>
> It's much better to create a separate mode-setting pipeline for the
> ssd132x series and share the common code among pipelines. Your driver
> will have a clean and readable implementation for each supported
> chipset. Compare an old version of mgag200 [2] with the current driver
> to see the difference.
>
I see what you mean. The reason why I didn't go that route was to minimize
code duplication, but you are correct that each level of indirection makes
the driver harder to read, to reason about and fragile (modifying a common
callback could have undesired effects on other chip families as you said).
I'll give it a try to what you propose in v3, have separate modesetting
pipeline for SSD130x and SSD132x, even if this could lead to a little more
duplicated code.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v2 4/6] drm/ssd130x: Add support for the SSD132x OLED controller family
Geert Uytterhoeven writes: Hello Geert, Thanks for your feedback. > Hi Javier, > [...] >> + u32 array_idx = 0; >> + int ret, i, j; > > unsigned int i, j; > Right, I'll change that in v3. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v1] drm/tiny: correctly print `struct resource *` on error
Hi
Am 10.10.23 um 19:46 schrieb Joey Gouly:
The `res` variable is already a `struct resource *`, don't take the address of
it.
Fixes incorrect output:
simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not
acquire memory range [??? 0x4be88a387d00-0xfefffde0a240 flags 0x0]: -16
To be correct:
simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not
acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16
Signed-off-by: Joey Gouly
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
It's a bug fix. I'm going to merge this patch into drm-misc-fixes with
the following additional tags:
Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory
framebuffers")
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Best regards
Thomas
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index ff86ba1ae1b8..8ea120eb8674 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -745,7 +745,7 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
ret = devm_aperture_acquire_from_firmware(dev, res->start, resource_size(res));
if (ret) {
- drm_err(dev, "could not acquire memory range %pr: %d\n",
&res, ret);
+ drm_err(dev, "could not acquire memory range %pr:
%d\n", res, ret);
return ERR_PTR(ret);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 5/6] dt-bindings: display: Split common Solomon properties in their own schema
Geert Uytterhoeven writes: > Hi Javier, > > On Thu, Oct 12, 2023 at 8:58 AM Javier Martinez Canillas > wrote: >> There are DT properties that can be shared across different Solomon OLED >> Display Controller families. Split them into a separate common schema to >> avoid these properties to be duplicated in different DT bindings schemas. >> >> Suggested-by: Rob Herring >> Signed-off-by: Javier Martinez Canillas >> --- >> >> (no changes since v1) > > New patch in v2. > Yeah, I mention that in the cover letter. That "(no changes since...)" message is automatically added by the tool I use to post patches (patman) for all patches that don't have a change history, even for new patches in a series revision. And I don't know of a way to disable it... Maybe what I should do is to add a change history to new patches mentioned that is a new patch to prevent this message to appear. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v2 2/6] drm/ssd130x: Add a per controller family functions table
Hi Javier
Am 12.10.23 um 10:02 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Thanks a lot for your feedback.
Hi Javier
Am 12.10.23 um 08:58 schrieb Javier Martinez Canillas:
[...]
+struct ssd130x_funcs {
+ int (*init)(struct ssd130x_device *ssd130x);
+ int (*set_buffer_sizes)(struct ssd130x_device *ssd130x);
+ void (*align_rect)(struct ssd130x_device *ssd130x, struct drm_rect
*rect);
+ int (*update_rect)(struct ssd130x_device *ssd130x, struct drm_rect
*rect,
+ u8 *buf, u8 *data_array);
+ void (*clear_screen)(struct ssd130x_device *ssd130x,
+u8 *data_array);
+ void (*fmt_convert)(struct iosys_map *dst, const unsigned int
*dst_pitch,
+ const struct iosys_map *src, const struct
drm_framebuffer *fb,
+ const struct drm_rect *clip);
+};
+
You are reinventing DRM's atomic helpers. I strongly advised against
doing that, as it often turns out bad. Maybe see my rant at [1] wrt to
another driver.
It's much better to create a separate mode-setting pipeline for the
ssd132x series and share the common code among pipelines. Your driver
will have a clean and readable implementation for each supported
chipset. Compare an old version of mgag200 [2] with the current driver
to see the difference.
I see what you mean. The reason why I didn't go that route was to minimize
code duplication, but you are correct that each level of indirection makes
the driver harder to read, to reason about and fragile (modifying a common
callback could have undesired effects on other chip families as you said).
I'll give it a try to what you propose in v3, have separate modesetting
pipeline for SSD130x and SSD132x, even if this could lead to a little more
duplicated code.
Thanks a lot. I know you want to make a reference driver for others to
study. So I think at least trying the multi-pipeline way is worth it.
From the mgag200 and ast drivers, I found that the refactoring patch
sets can be large to the point where one wonders whether it's actually
worth it. But the end results turned out ok. (ast still needs more work
though.)
Best regards
Thomas
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/simpledrm: Fix power domain device link validity check
Hi
Am 11.10.23 um 16:32 schrieb Thierry Reding:
From: Thierry Reding
We need to check if a link is non-NULL before trying to delete it.
Signed-off-by: Thierry Reding
Reviewed-by: Thomas Zimmermann
I'm going to merge the patch into drm-misc-next with the additional
Fixes tag
Fixes: 61df9ca23107 ("drm/simpledrm: Add support for multiple
"power-domains"")
Best regards
Thomas
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 9c597461d1e2..8bdaf66044fc 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -506,7 +506,7 @@ static void simpledrm_device_detach_genpd(void *res)
return;
for (i = sdev->pwr_dom_count - 1; i >= 0; i--) {
- if (!sdev->pwr_dom_links[i])
+ if (sdev->pwr_dom_links[i])
device_link_del(sdev->pwr_dom_links[i]);
if (!IS_ERR_OR_NULL(sdev->pwr_dom_devs[i]))
dev_pm_domain_detach(sdev->pwr_dom_devs[i], true);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[PATCH v7 00/16] introduce more MDP3 components in MT8195
Changes since v6: - Rebase on v6.6-rc5. - Dependent dtsi files: https://patchwork.kernel.org/project/linux-mediatek/list/?series=792079 - Depends on: Message ID = 20231006073831.10402-5-shawn.s...@mediatek.com - Discard splitting RDMA's common properties and instead use 'allOf' to isolate different platform features. - Revise the incorrect properties in FG, HDR, STITCH, TCC and TDAP bindings. - Adding SoC-specific compatible string to components, like WROT and RSZ, that are inherited from MT8183. - Fixed typos in TCC patch and enhancing its hardware description. Changes since v5: - Rebase on v6.6-rc2. - Dependent dtsi files: https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511 - Depends on: Message ID = 20230911074233.31556-5-shawn.s...@mediatek.com - Split out common propertis for RDMA. - Split each component into independent patches. Changes since v4: - Rebase on v6.6-rc1 - Organize identical hardware components into their respective files. Hi, The purpose of this patch is to separate the MDP3-related bindings from the original mailing list mentioned below: https://lore.kernel.org/all/20230208092209.19472-1-moudy...@mediatek.com/ Those binding files describe additional components that are present in the mt8195. Moudy Ho (16): dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT dt-bindings: media: mediatek: mdp3: add component FG for MT8195 dt-bindings: media: mediatek: mdp3: add component HDR for MT8195 dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195 dt-bindings: media: mediatek: mdp3: add component TCC for MT8195 dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195 dt-bindings: display: mediatek: aal: add compatible for MT8195 dt-bindings: display: mediatek: color: add compatible for MT8195 dt-bindings: display: mediatek: merge: add compatible for MT8195 dt-bindings: display: mediatek: ovl: add compatible for MT8195 dt-bindings: display: mediatek: split: add compatible for MT8195 dt-bindings: display: mediatek: padding: add compatible for MT8195 .../display/mediatek/mediatek,aal.yaml| 1 + .../display/mediatek/mediatek,color.yaml | 1 + .../display/mediatek/mediatek,mdp-rdma.yaml | 88 -- .../display/mediatek/mediatek,merge.yaml | 1 + .../display/mediatek/mediatek,ovl.yaml| 1 + .../display/mediatek/mediatek,padding.yaml| 4 +- .../display/mediatek/mediatek,split.yaml | 27 + .../bindings/media/mediatek,mdp3-fg.yaml | 61 ++ .../bindings/media/mediatek,mdp3-hdr.yaml | 60 ++ .../bindings/media/mediatek,mdp3-rdma.yaml| 108 ++ .../bindings/media/mediatek,mdp3-rsz.yaml | 6 +- .../bindings/media/mediatek,mdp3-stitch.yaml | 61 ++ .../bindings/media/mediatek,mdp3-tcc.yaml | 62 ++ .../bindings/media/mediatek,mdp3-tdshp.yaml | 61 ++ .../bindings/media/mediatek,mdp3-wrot.yaml| 29 +++-- 15 files changed, 449 insertions(+), 122 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml -- 2.18.0
[PATCH v7 01/16] dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.
Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek
MDP3 components")
Signed-off-by: Moudy Ho
Acked-by: Rob Herring
---
.../bindings/media/mediatek,mdp3-rdma.yaml| 29 +++
.../bindings/media/mediatek,mdp3-wrot.yaml| 23 +--
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 7032c7e15039..3e128733ef53 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -61,6 +61,9 @@ properties:
- description: used for 1st data pipe from RDMA
- description: used for 2nd data pipe from RDMA
+ '#dma-cells':
+const: 1
+
required:
- compatible
- reg
@@ -70,6 +73,7 @@ required:
- clocks
- iommus
- mboxes
+ - '#dma-cells'
additionalProperties: false
@@ -80,16 +84,17 @@ examples:
#include
#include
-mdp3_rdma0: mdp3-rdma0@14001000 {
- compatible = "mediatek,mt8183-mdp3-rdma";
- reg = <0x14001000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400 0x1000 0x1000>;
- mediatek,gce-events = ,
-;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MDP_RSZ1>;
- iommus = <&iommu>;
- mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
- <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+dma-controller@14001000 {
+compatible = "mediatek,mt8183-mdp3-rdma";
+reg = <0x14001000 0x1000>;
+mediatek,gce-client-reg = <&gce SUBSYS_1400 0x1000 0x1000>;
+mediatek,gce-events = ,
+ ;
+power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MDP_RSZ1>;
+iommus = <&iommu>;
+mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+#dma-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 0baa77198fa2..64ea98aa0592 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -50,6 +50,9 @@ properties:
iommus:
maxItems: 1
+ '#dma-cells':
+const: 1
+
required:
- compatible
- reg
@@ -58,6 +61,7 @@ required:
- power-domains
- clocks
- iommus
+ - '#dma-cells'
additionalProperties: false
@@ -68,13 +72,14 @@ examples:
#include
#include
-mdp3_wrot0: mdp3-wrot0@14005000 {
- compatible = "mediatek,mt8183-mdp3-wrot";
- reg = <0x14005000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400 0x5000 0x1000>;
- mediatek,gce-events = ,
-;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- iommus = <&iommu>;
+dma-controller@14005000 {
+compatible = "mediatek,mt8183-mdp3-wrot";
+reg = <0x14005000 0x1000>;
+mediatek,gce-client-reg = <&gce SUBSYS_1400 0x5000 0x1000>;
+mediatek,gce-events = ,
+ ;
+power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+clocks = <&mmsys CLK_MM_MDP_WROT0>;
+iommus = <&iommu>;
+#dma-cells = <1>;
};
--
2.18.0
[PATCH v7 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195
Add the fundamental hardware configuration of component FG,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-fg.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
new file mode 100644
index ..82f4c182c77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 FG
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to add film grain
+ according to AV1 spec.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-fg
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14002000 {
+compatible = "mediatek,mt8195-mdp3-fg";
+reg = <0x14002000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x2000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_FG>;
+};
--
2.18.0
[PATCH v7 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
To simplify maintenance and avoid branches, the identical component
should be merged and placed in the path belonging to the MDP
(from display/* to media/*).
In addition, currently only MDP utilizes RDMA through CMDQ, and the
necessary properties for "mediatek,gce-events", and "mboxes" have been
set up for this purpose.
Within DISP, it directly receives component interrupt signals.
Signed-off-by: Moudy Ho
---
.../display/mediatek/mediatek,mdp-rdma.yaml | 88 ---
.../bindings/media/mediatek,mdp3-rdma.yaml| 55 +---
2 files changed, 45 insertions(+), 98 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
deleted file mode 100644
index dd12e2ff685c..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ /dev/null
@@ -1,88 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek MDP RDMA
-
-maintainers:
- - Chun-Kuang Hu
- - Philipp Zabel
-
-description:
- The MediaTek MDP RDMA stands for Read Direct Memory Access.
- It provides real time data to the back-end panel driver, such as DSI,
- DPI and DP_INTF.
- It contains one line buffer to store the sufficient pixel data.
- RDMA device node must be siblings to the central MMSYS_CONFIG node.
- For a description of the MMSYS_CONFIG binding, see
- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for
details.
-
-properties:
- compatible:
-const: mediatek,mt8195-vdo1-rdma
-
- reg:
-maxItems: 1
-
- interrupts:
-maxItems: 1
-
- power-domains:
-maxItems: 1
-
- clocks:
-items:
- - description: RDMA Clock
-
- iommus:
-maxItems: 1
-
- mediatek,gce-client-reg:
-description:
- The register of display function block to be set by gce. There are 4
arguments,
- such as gce node, subsys id, offset and register size. The subsys id
that is
- mapping to the register of display function blocks is defined in the gce
header
- include/dt-bindings/gce/-gce.h of each chips.
-$ref: /schemas/types.yaml#/definitions/phandle-array
-items:
- items:
-- description: phandle of GCE
-- description: GCE subsys id
-- description: register offset
-- description: register size
-maxItems: 1
-
-required:
- - compatible
- - reg
- - power-domains
- - clocks
- - iommus
- - mediatek,gce-client-reg
-
-additionalProperties: false
-
-examples:
- - |
-#include
-#include
-#include
-#include
-#include
-
-soc {
-#address-cells = <2>;
-#size-cells = <2>;
-
-rdma@1c104000 {
-compatible = "mediatek,mt8195-vdo1-rdma";
-reg = <0 0x1c104000 0 0x1000>;
-interrupts = ;
-clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
-power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
-iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
-mediatek,gce-client-reg = <&gce0 SUBSYS_1c10 0x4000 0x1000>;
-};
-};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 3e128733ef53..c043204cf210 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -20,8 +20,9 @@ description: |
properties:
compatible:
-items:
- - const: mediatek,mt8183-mdp3-rdma
+enum:
+ - mediatek,mt8183-mdp3-rdma
+ - mediatek,mt8195-vdo1-rdma
reg:
maxItems: 1
@@ -49,17 +50,18 @@ properties:
maxItems: 1
clocks:
-items:
- - description: RDMA clock
- - description: RSZ clock
+minItems: 1
+maxItems: 2
iommus:
maxItems: 1
mboxes:
-items:
- - description: used for 1st data pipe from RDMA
- - description: used for 2nd data pipe from RDMA
+minItems: 1
+maxItems: 2
+
+ interrupts:
+maxItems: 1
'#dma-cells':
const: 1
@@ -68,13 +70,46 @@ required:
- compatible
- reg
- mediatek,gce-client-reg
- - mediatek,gce-events
- power-domains
- clocks
- iommus
- - mboxes
- '#dma-cells'
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: mediatek,mt8183-mdp3-rdma
+
+then:
+ properties:
+clocks:
+ items:
+- description: RDMA clock
+- description: RSZ clock (shared SRAM with RDMA)
+
+mboxes:
+ items:
+- description: used for 1st data pipe from RDMA
+- description: used for 2nd data pipe fro
[PATCH v7 07/16] dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
Add the fundamental hardware configuration of component HDR,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-hdr.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
new file mode 100644
index ..98db6cb4d03a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-hdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 HDR
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to perform HDR to SDR
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-hdr
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14004000 {
+compatible = "mediatek,mt8195-mdp3-hdr";
+reg = <0x14004000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x4000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_HDR>;
+};
--
2.18.0
[PATCH v7 05/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
MT8195 WROT inherited from MT8183, add the corresponding compatible name to it. Signed-off-by: Moudy Ho --- .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml index 64ea98aa0592..53a679338402 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml @@ -15,9 +15,13 @@ description: | properties: compatible: -items: +oneOf: - enum: - mediatek,mt8183-mdp3-wrot + - items: + - enum: + - mediatek,mt8195-mdp3-wrot + - const: mediatek,mt8183-mdp3-wrot reg: maxItems: 1 -- 2.18.0
[PATCH v7 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
Add a compatible string for the COLOR block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index f21e44092043..b886ca0d89ea 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt2701-disp-color - mediatek,mt8167-disp-color - mediatek,mt8173-disp-color + - mediatek,mt8195-mdp3-color - items: - enum: - mediatek,mt7623-disp-color -- 2.18.0
[PATCH v7 14/16] dt-bindings: display: mediatek: ovl: add compatible for MT8195
Add a compatible string for the OVL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 3e1069b00b56..c471a181d125 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8173-disp-ovl - mediatek,mt8183-disp-ovl - mediatek,mt8192-disp-ovl + - mediatek,mt8195-mdp3-ovl - items: - enum: - mediatek,mt7623-disp-ovl -- 2.18.0
[PATCH v7 09/16] dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
Add the fundamental hardware configuration of component TCC,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-tcc.yaml | 62 +++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
new file mode 100644
index ..f134160f85b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 TCC
+
+maintainers:
+ - Matthias Brugger
+
+description:
+ Tone Curve Conversion (TCC) is one of Media Profile Path 3 (MDP3) components.
+ It is used to handle the tone mapping of various gamma curves in order to
+ achieve HDR10 effects. This helps adapt the content to the color and
+ brightness range that standard display devices typically support.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-tcc
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@1400b000 {
+compatible = "mediatek,mt8195-mdp3-tcc";
+reg = <0x1400b000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0xb000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_TCC>;
+};
--
2.18.0
[PATCH v7 04/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
MT8195 RSZ inherited from MT8183, add the corresponding compatible name to it. Signed-off-by: Moudy Ho --- .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml| 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml index 78f9de6192ef..f5676bec4326 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml @@ -15,9 +15,13 @@ description: | properties: compatible: -items: +oneOf: - enum: - mediatek,mt8183-mdp3-rsz + - items: + - enum: + - mediatek,mt8195-mdp3-rsz + - const: mediatek,mt8183-mdp3-rsz reg: maxItems: 1 -- 2.18.0
[PATCH v7 08/16] dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-stitch.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
new file mode 100644
index ..d815bea29154
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-stitch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 STITCH
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to combine multiple video
frame
+ with overlapping fields of view to produce a segmented panorame.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-stitch
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14003000 {
+compatible = "mediatek,mt8195-mdp3-stitch";
+reg = <0x14003000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x3000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_STITCH>;
+};
--
2.18.0
[PATCH v7 16/16] dt-bindings: display: mediatek: padding: add compatible for MT8195
Add a compatible string for the PAD block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../bindings/display/mediatek/mediatek,padding.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml index db24801ebc48..636b69133acc 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml @@ -20,7 +20,9 @@ description: properties: compatible: -const: mediatek,mt8188-padding +enum: + - mediatek,mt8188-padding + - mediatek,mt8195-mdp3-pad reg: maxItems: 1 -- 2.18.0
[PATCH v7 11/16] dt-bindings: display: mediatek: aal: add compatible for MT8195
Add a compatible string for the AAL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho Acked-by: Conor Dooley --- .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 7fd42c8fdc32..b4c28e96dd55 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-aal - mediatek,mt8183-disp-aal + - mediatek,mt8195-mdp3-aal - items: - enum: - mediatek,mt2712-disp-aal -- 2.18.0
[PATCH v7 03/16] dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
Added the configuration for MT8195 RDMA. In comparison to MT8183, it no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox. Signed-off-by: Moudy Ho --- .../bindings/media/mediatek,mdp3-rdma.yaml| 26 ++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml index c043204cf210..504334a76fb3 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml @@ -22,6 +22,7 @@ properties: compatible: enum: - mediatek,mt8183-mdp3-rdma + - mediatek,mt8195-mdp3-rdma - mediatek,mt8195-vdo1-rdma reg: @@ -58,7 +59,7 @@ properties: mboxes: minItems: 1 -maxItems: 2 +maxItems: 5 interrupts: maxItems: 1 @@ -98,6 +99,29 @@ allOf: - mboxes - mediatek,gce-events + - if: + properties: +compatible: + contains: +const: mediatek,mt8195-mdp3-rdma + +then: + properties: +clocks: + items: +- description: RDMA clock + +mboxes: + items: +- description: used for 1st data pipe from RDMA +- description: used for 2nd data pipe from RDMA +- description: used for 3rd data pipe from RDMA +- description: used for 4th data pipe from RDMA +- description: used for the data pipe from SPLIT + + required: +- mediatek,gce-events + - if: properties: compatible: -- 2.18.0
[PATCH v7 15/16] dt-bindings: display: mediatek: split: add compatible for MT8195
Add compatible string and GCE property for MT8195 SPLIT, of which is operated by MDP3. Signed-off-by: Moudy Ho --- .../display/mediatek/mediatek,split.yaml | 27 +++ 1 file changed, 27 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index a8a5c9608598..e4affc854f3d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -23,6 +23,7 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-split + - mediatek,mt8195-mdp3-split - items: - const: mediatek,mt6795-disp-split - const: mediatek,mt8173-disp-split @@ -38,6 +39,21 @@ properties: the power controller specified by phandle. See Documentation/devicetree/bindings/power/power-domain.yaml for details. + mediatek,gce-client-reg: +description: + The register of display function block to be set by gce. There are 4 arguments, + such as gce node, subsys id, offset and register size. The subsys id that is + mapping to the register of display function blocks is defined in the gce header + include/dt-bindings/gce/-gce.h of each chips. +$ref: /schemas/types.yaml#/definitions/phandle-array +items: + items: +- description: phandle of GCE +- description: GCE subsys id +- description: register offset +- description: register size +maxItems: 1 + clocks: items: - description: SPLIT Clock @@ -48,6 +64,17 @@ required: - power-domains - clocks +allOf: + - if: + properties: +compatible: + contains: +const: mediatek,mt8195-mdp3-split + +then: + required: +- mediatek,gce-client-reg + additionalProperties: false examples: -- 2.18.0
[PATCH v7 13/16] dt-bindings: display: mediatek: merge: add compatible for MT8195
Add a compatible string for the MERGE block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index eead5cb8636e..401498523404 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-merge - mediatek,mt8195-disp-merge + - mediatek,mt8195-mdp3-merge - items: - const: mediatek,mt6795-disp-merge - const: mediatek,mt8173-disp-merge -- 2.18.0
[PATCH v7 10/16] dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
new file mode 100644
index ..92e1547e7c7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 TDSHP
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to improve image
+ sharpness and contrast.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-tdshp
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14007000 {
+compatible = "mediatek,mt8195-mdp3-tdshp";
+reg = <0x14007000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x7000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_TDSHP>;
+};
--
2.18.0
[PATCH v2 1/1] drm: panel-simple: add missing bus flags for Tianma tm070jvhg[30/33]
From: Markus Niebel
The DE signal is active high on this display, fill in the missing
bus_flags. This aligns panel_desc with its display_timing.
Fixes: 9a2654c0f62a ("drm/panel: Add and fill drm_panel type field")
Fixes: b3bfcdf8a3b6 ("drm/panel: simple: add Tianma TM070JVHG33")
Signed-off-by: Markus Niebel
Signed-off-by: Alexander Stein
Reviewed-by: Sam Ravnborg
---
Changes in v2:
* Collected Sam's R-b
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 07c627de70534..b5b79f1789519 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3867,6 +3867,7 @@ static const struct panel_desc tianma_tm070jdhg30 = {
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
};
static const struct panel_desc tianma_tm070jvhg33 = {
@@ -3879,6 +3880,7 @@ static const struct panel_desc tianma_tm070jvhg33 = {
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
};
static const struct display_timing tianma_tm070rvhg71_timing = {
--
2.34.1
Re: (subset) [PATCH] drm: Do not overrun array in drm_gem_get_pages()
On Thu, 05 Oct 2023 14:56:47 +0100, Matthew Wilcox (Oracle) wrote: > If the shared memory object is larger than the DRM object that it backs, > we can overrun the page array. Limit the number of pages we install > from each folio to prevent this. > > Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Re: [PATCH] drm/tidss: Power up attached PM domains on probe
Hi Maxime,
On 09/10/23 16:40, Devarsh Thakkar wrote:
Hi Maxime,
Thanks for the review.
On 09/10/23 14:53, Maxime Ripard wrote:
Hi Devarsh,
On Mon, Oct 09, 2023 at 01:20:18PM +0530, Devarsh Thakkar wrote:
Some SoC's such as AM62P have dedicated power domains
for OLDI which need to be powered on separetely along
with display controller.
So during driver probe, power up all attached PM domains
enumerated in devicetree node for DSS.
This also prepares base to add display support for AM62P.
Signed-off-by: Devarsh Thakkar
---
drivers/gpu/drm/tidss/tidss_drv.c | 76 +++
drivers/gpu/drm/tidss/tidss_drv.h | 5 ++
2 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index 4d063eb9cd0b..a703a27d17bf 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -114,6 +115,72 @@ static const struct drm_driver tidss_driver = {
.minor = 0,
};
+static int tidss_detach_pm_domains(struct tidss_device *tidss)
+{
+ int i;
+
+ if (tidss->num_domains <= 1)
+ return 0;
+
+ for (i = 0; i < tidss->num_domains; i++) {
+ if (tidss->pd_link[i] && !IS_ERR(tidss->pd_link[i]))
+ device_link_del(tidss->pd_link[i]);
+ if (tidss->pd_dev[i] && !IS_ERR(tidss->pd_dev[i]))
+ dev_pm_domain_detach(tidss->pd_dev[i], true);
+ tidss->pd_dev[i] = NULL;
+ tidss->pd_link[i] = NULL;
+ }
+
+ return 0;
+}
+
+static int tidss_attach_pm_domains(struct tidss_device *tidss)
+{
+ struct device *dev = tidss->dev;
+ int i;
+ int ret;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct device_node *np = pdev->dev.of_node;
+
+ tidss->num_domains = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+ if (tidss->num_domains <= 1) {
+ dev_dbg(dev, "One or less power domains, no need to do attach
domains\n");
+ return 0;
+ }
+
+ tidss->pd_dev = devm_kmalloc_array(dev, tidss->num_domains,
+ sizeof(*tidss->pd_dev), GFP_KERNEL);
+ if (!tidss->pd_dev)
+ return -ENOMEM;
+
+ tidss->pd_link = devm_kmalloc_array(dev, tidss->num_domains,
+ sizeof(*tidss->pd_link),
GFP_KERNEL);
+ if (!tidss->pd_link)
+ return -ENOMEM;
+
+ for (i = 0; i < tidss->num_domains; i++) {
+ tidss->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
+ if (IS_ERR(tidss->pd_dev[i])) {
+ ret = PTR_ERR(tidss->pd_dev[i]);
+ goto fail;
+ }
+
+ tidss->pd_link[i] = device_link_add(dev, tidss->pd_dev[i],
+ DL_FLAG_STATELESS |
+ DL_FLAG_PM_RUNTIME |
DL_FLAG_RPM_ACTIVE);
+ if (!tidss->pd_link[i]) {
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ return 0;
+fail:
+ tidss_detach_pm_domains(tidss);
+ return ret;
+}
My understanding is that this will be done automatically at probe time.
Why do we need to roll our own there? A comment on top of the function
and the commit log would help.
By default, the TI SCI power domain controller driver only powers up one power
domain associated with device, With AM62P, we now have separate power domains
for OLDI Tx ports (for more efficient power-saving control) which is different
from core DSS device power domain, so this patch powers on the associated
power domains too if enumerated in device-tree.
My bad, I think it is not the ti sci power domain controller driver but
the kernel core itself which seems to have a check to only allow one
power domain per device (thanks to Vignesh for pointing out) :
/*
* Devices with multiple PM domains must be attached separately,
* as we can only attach one PM domain per device.
*/
if (of_count_phandle_with_args(dev->of_node, "power-domains",
"#power-domain-cells") != 1)
return 0;
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/base/power/domain.c?h=next-20231012#n2828
But anyways, I talked to team internally and there are some plans to
have separate OLDI bridge driver which would inherit these new power
domains, so I guess we may not need this patch at all.
Regards
Devarsh
Regards
Devarsh
Thanks!
Maxime
Re: [PATCH v1] dynamic_debug: add support for logs destination
On Wed, 11 Oct 2023 11:42:24 +0200 Daniel Vetter wrote: > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote: > > On Tue, 10 Oct 2023 10:06:02 -0600 > > jim.cro...@gmail.com wrote: > > > > > since I name-dropped you all, > > > > Hi everyone, > > > > I'm really happy to see this topic being developed! I've practically > > forgot about it myself, but the need for it has not diminished at all. > > > > I didn't understand much of the conversation, so I'll just reiterate > > what I would use it for, as a Wayland compositor developer. > > > > I added a few more cc's to get better coverage of DRM and Wayland > > compositor developers. > > > > > On Tue, Oct 10, 2023 at 10:01 AM wrote: > > > > > > > > On Mon, Oct 9, 2023 at 4:47 PM Łukasz Bartosik > > > > wrote: > > > > ... > > > > > > > I don't have a real life use case to configure different trace > > > > > instance for each callsite. > > > > > I just tried to be as much flexible as possible. > > > > > > > > > > > > > Ive come around to agree - I looked back at some old threads > > > > (that I was a part of, and barely remembered :-} > > > > > > > > At least Sean Paul, Lyude, Simon Ser, Pekka Paalanen > > > > have expressed a desire for a "flight-recorder" > > > > it'd be hard to say now that 2-3 such buffers would always be enough, > > > > esp as theres a performance reason for having your own. > > > > A Wayland compositor has roughly three important things where the kernel > > debugs might come in handy: > > - input > > - DRM KMS > > - DRM GPU rendering > > > > DRM KMS is the one I've been thinking of in the flight recorder context > > the most, because KMS hardware varies a lot, and there is plenty of > > room for both KMS drivers and KMS userspace to go wrong. The usual > > result is your display doesn't work, so the system is practically > > unusable to the end user. In the wild, the simplest or maybe the only > > way out of that may be a reboot, maybe an automated one (e.g. digital > > signage). In order to debug such problems, we would need both > > compositor logs and the relevant kernel debug messages. > > > > For example, Weston already has a flight recorder framework of its own, > > so we have the compositor debug logs. It would be useful to get the > > selected kernel debug logs in the same place. It could be used for > > automated or semi-manual bug reporting, for example, making the > > administrator or end user life much easier reporting issues. > > > > Since this is usually a production environment, and the Wayland > > compositor runs without root privileges, we need something that works > > with that. We would likely want the kernel debug messages in the > > compositor to combine and order them properly with the compositor debug > > messages. > > > > It's quite likely that developers would like to pick and choose which > > kernel debug messages might be interesting enough to record, to avoid > > excessive log flooding. The flight recorder in Weston is fixed size to > > avoid running out of memory or disk space. I can also see that Weston > > could have debugging options that affect which kernel debug messages it > > subscribes to. We can have a reasonable default setup that allows us to > > pinpoint the problem area and figure out most problems, and if needed, > > we could ask the administrator pass another debug option to Weston. It > > helps if there is just one place to configure everything about the > > compositor. > > > > This implies that it would be really nice to have userspace subscriber > > specific debug message streams from the kernel, or a good way to filter > > the messages we want. A Wayland compositor would not be interested in > > file system or wireless debugs for example, but another system > > component might be. There is also a security aspect of which component is > > allowed to see which messages in case they could contain anything > > sensitive (input debug could contain typed passwords). > > > > Configuring the kernel debug message selection for our debug message > > stream can and probably should require elevated privileges, and we can > > likely solve that in userspace with a daemon or such, to allow the > > Wayland compositor to run as a regular user. > > > > Thinking of desktop systems, and especially physically multi-seat systems: > > - there can be multiple different Wayland compositors running simultaneously > > - each of them may want debug messages only from a specific DRM KMS > > device instance, and not from others > > - each of them may have a different idea of which debug messages are > > important > > - because DRM KMS leasing is a thing, different compositor instances > > could be using the same DRM KMS device instance simultaneously; since > > this is specific to DRM KMS, and it should be harmless to get a > > little too much DRM KMS debug (that is, from the whole device instead > > of just the leased parts), it may not be worth to consider sp
[PATCH v3 1/5] drm/msm/dpu: create a dpu_hw_clk_force_ctrl() helper
Add an helper to setup the force clock control as it will
be used in multiple HW files.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 23 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 21 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 4
3 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
index cff48763ce25..24e734768a72 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
@@ -66,34 +66,13 @@ static void dpu_hw_setup_split_pipe(struct dpu_hw_mdp *mdp,
static bool dpu_hw_setup_clk_force_ctrl(struct dpu_hw_mdp *mdp,
enum dpu_clk_ctrl_type clk_ctrl, bool enable)
{
- struct dpu_hw_blk_reg_map *c;
- u32 reg_off, bit_off;
- u32 reg_val, new_val;
- bool clk_forced_on;
-
if (!mdp)
return false;
- c = &mdp->hw;
-
if (clk_ctrl <= DPU_CLK_CTRL_NONE || clk_ctrl >= DPU_CLK_CTRL_MAX)
return false;
- reg_off = mdp->caps->clk_ctrls[clk_ctrl].reg_off;
- bit_off = mdp->caps->clk_ctrls[clk_ctrl].bit_off;
-
- reg_val = DPU_REG_READ(c, reg_off);
-
- if (enable)
- new_val = reg_val | BIT(bit_off);
- else
- new_val = reg_val & ~BIT(bit_off);
-
- DPU_REG_WRITE(c, reg_off, new_val);
-
- clk_forced_on = !(reg_val & BIT(bit_off));
-
- return clk_forced_on;
+ return dpu_hw_clk_force_ctrl(&mdp->hw, &mdp->caps->clk_ctrls[clk_ctrl],
enable);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
index 9d2273fd2fed..18b16b2d2bf5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
@@ -546,3 +546,24 @@ void dpu_setup_cdp(struct dpu_hw_blk_reg_map *c, u32
offset,
DPU_REG_WRITE(c, offset, cdp_cntl);
}
+
+bool dpu_hw_clk_force_ctrl(struct dpu_hw_blk_reg_map *c,
+ const struct dpu_clk_ctrl_reg *clk_ctrl_reg,
+ bool enable)
+{
+ u32 reg_val, new_val;
+ bool clk_forced_on;
+
+ reg_val = DPU_REG_READ(c, clk_ctrl_reg->reg_off);
+
+ if (enable)
+ new_val = reg_val | BIT(clk_ctrl_reg->bit_off);
+ else
+ new_val = reg_val & ~BIT(clk_ctrl_reg->bit_off);
+
+ DPU_REG_WRITE(c, clk_ctrl_reg->reg_off, new_val);
+
+ clk_forced_on = !(reg_val & BIT(clk_ctrl_reg->bit_off));
+
+ return clk_forced_on;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index 1f6079f47071..4bea139081bc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -367,4 +367,8 @@ int dpu_hw_collect_misr(struct dpu_hw_blk_reg_map *c,
u32 misr_signature_offset,
u32 *misr_value);
+bool dpu_hw_clk_force_ctrl(struct dpu_hw_blk_reg_map *c,
+ const struct dpu_clk_ctrl_reg *clk_ctrl_reg,
+ bool enable);
+
#endif /* _DPU_HW_UTIL_H */
--
2.34.1
[PATCH v3 0/5] drm/msm/dpu: correctly implement SSPP & WB Clock Control Split
Starting with the SM8550 platform, the SSPP & WB Clock Controls are no more in the MDP TOP registers, but in the SSPP & WB register space. Add the corresponding SSPP & WB ops and use them before/after calling the QoS and OT limit setup functions. WB tested with: $ modetest -M msm -a -s 40@103:1024x768 -o test.d -P 47@103:1024x768 Signed-off-by: Neil Armstrong --- Changes in v3: - Collected reviews - Add static const to clk_ctrl struct in sspp/wb - Link to v2: https://lore.kernel.org/r/20231011-topic-sm8550-graphics-sspp-split-clk-v2-0-b219c945d...@linaro.org Changes in v2: - moved all force_clk_ctrl code out of vbif - use major ver test to add force_clk_ctrl op - do not add clk_ctrl reg into sspp/wb cap struct - add WB2 on sm8550 - Link to v1: https://lore.kernel.org/r/20231009-topic-sm8550-graphics-sspp-split-clk-v1-0-806c0dee4...@linaro.org --- Neil Armstrong (5): drm/msm/dpu: create a dpu_hw_clk_force_ctrl() helper drm/msm/dpu: add setup_clk_force_ctrl() op to sspp & wb drm/msm/dpu: move setup_force_clk_ctrl handling into plane and wb drm/msm/dpu: sm8550: remove unused VIG and DMA clock controls entries drm/msm/dpu: enable writeback on SM8550 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 36 +-- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 37 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 21 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 12 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 23 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c| 21 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 4 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 20 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 7 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 42 +++--- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 4 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 30 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.h | 4 --- 13 files changed, 173 insertions(+), 88 deletions(-) --- base-commit: 9119cf579b4432b36be9d33a92f4331922067d92 change-id: 20231009-topic-sm8550-graphics-sspp-split-clk-43c32e37b6aa Best regards, -- Neil Armstrong
[PATCH v3 3/5] drm/msm/dpu: move setup_force_clk_ctrl handling into plane and wb
Now SSPP and WB can have setup_force_clk_ctrl() ops, it's simpler to call
them from the plane and wb code and call into the mdp ops if not present.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 37 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 42 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 30 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.h | 4 ---
4 files changed, 77 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 78037a697633..8802e007f8e2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -34,6 +34,23 @@ static bool dpu_encoder_phys_wb_is_master(struct
dpu_encoder_phys *phys_enc)
return true;
}
+static bool _dpu_encoder_phys_wb_clk_force_ctrl(struct dpu_hw_wb *wb,
+ struct dpu_hw_mdp *mdp,
+ bool enable, bool *forced_on)
+{
+ if (wb->ops.setup_clk_force_ctrl) {
+ *forced_on = wb->ops.setup_clk_force_ctrl(wb, enable);
+ return true;
+ }
+
+ if (mdp->ops.setup_clk_force_ctrl) {
+ *forced_on = mdp->ops.setup_clk_force_ctrl(mdp,
wb->caps->clk_ctrl, enable);
+ return true;
+ }
+
+ return false;
+}
+
/**
* dpu_encoder_phys_wb_set_ot_limit - set OT limit for writeback interface
* @phys_enc: Pointer to physical encoder
@@ -43,6 +60,7 @@ static void dpu_encoder_phys_wb_set_ot_limit(
{
struct dpu_hw_wb *hw_wb = phys_enc->hw_wb;
struct dpu_vbif_set_ot_params ot_params;
+ bool forced_on = false;
memset(&ot_params, 0, sizeof(ot_params));
ot_params.xin_id = hw_wb->caps->xin_id;
@@ -52,10 +70,17 @@ static void dpu_encoder_phys_wb_set_ot_limit(
ot_params.is_wfd = true;
ot_params.frame_rate = drm_mode_vrefresh(&phys_enc->cached_mode);
ot_params.vbif_idx = hw_wb->caps->vbif_idx;
- ot_params.clk_ctrl = hw_wb->caps->clk_ctrl;
ot_params.rd = false;
+ if (!_dpu_encoder_phys_wb_clk_force_ctrl(hw_wb,
phys_enc->dpu_kms->hw_mdp,
+true, &forced_on))
+ return;
+
dpu_vbif_set_ot_limit(phys_enc->dpu_kms, &ot_params);
+
+ if (forced_on)
+ _dpu_encoder_phys_wb_clk_force_ctrl(hw_wb,
phys_enc->dpu_kms->hw_mdp,
+ false, &forced_on);
}
/**
@@ -67,6 +92,7 @@ static void dpu_encoder_phys_wb_set_qos_remap(
{
struct dpu_hw_wb *hw_wb;
struct dpu_vbif_set_qos_params qos_params;
+ bool forced_on = false;
if (!phys_enc || !phys_enc->parent || !phys_enc->parent->crtc) {
DPU_ERROR("invalid arguments\n");
@@ -83,7 +109,6 @@ static void dpu_encoder_phys_wb_set_qos_remap(
memset(&qos_params, 0, sizeof(qos_params));
qos_params.vbif_idx = hw_wb->caps->vbif_idx;
qos_params.xin_id = hw_wb->caps->xin_id;
- qos_params.clk_ctrl = hw_wb->caps->clk_ctrl;
qos_params.num = hw_wb->idx - WB_0;
qos_params.is_rt = false;
@@ -92,7 +117,15 @@ static void dpu_encoder_phys_wb_set_qos_remap(
qos_params.vbif_idx,
qos_params.xin_id, qos_params.is_rt);
+ if (!_dpu_encoder_phys_wb_clk_force_ctrl(hw_wb,
phys_enc->dpu_kms->hw_mdp,
+true, &forced_on))
+ return;
+
dpu_vbif_set_qos_remap(phys_enc->dpu_kms, &qos_params);
+
+ if (forced_on)
+ _dpu_encoder_phys_wb_clk_force_ctrl(hw_wb,
phys_enc->dpu_kms->hw_mdp,
+ false, &forced_on);
}
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..c63cae8fb35c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -333,6 +333,23 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane
*plane,
enable);
}
+static bool _dpu_plane_sspp_clk_force_ctrl(struct dpu_hw_sspp *sspp,
+ struct dpu_hw_mdp *mdp,
+ bool enable, bool *forced_on)
+{
+ if (sspp->ops.setup_clk_force_ctrl) {
+ *forced_on = sspp->ops.setup_clk_force_ctrl(sspp, enable);
+ return true;
+ }
+
+ if (mdp->ops.setup_clk_force_ctrl) {
+ *forced_on = mdp->ops.setup_clk_force_ctrl(mdp,
sspp->cap->clk_ctrl, enable);
+ return true;
+ }
+
+ return false;
+}
+
/**
* _dpu_plane_set_ot_limit - set OT limit for the g
[PATCH v3 4/5] drm/msm/dpu: sm8550: remove unused VIG and DMA clock controls entries
The SM8550 has the SSPP clk_ctrl in the SSPP registers, remove the
duplicate clock controls from the MDP top.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 7bed819dfc39..4590a01c1252 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -24,16 +24,6 @@ static const struct dpu_mdp_cfg sm8550_mdp = {
.base = 0, .len = 0x494,
.features = BIT(DPU_MDP_PERIPH_0_REMOVED),
.clk_ctrls = {
- [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x4330, .bit_off = 0 },
- [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x6330, .bit_off = 0 },
- [DPU_CLK_CTRL_VIG2] = { .reg_off = 0x8330, .bit_off = 0 },
- [DPU_CLK_CTRL_VIG3] = { .reg_off = 0xa330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x24330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x26330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x28330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2a330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA4] = { .reg_off = 0x2c330, .bit_off = 0 },
- [DPU_CLK_CTRL_DMA5] = { .reg_off = 0x2e330, .bit_off = 0 },
[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
},
};
@@ -81,7 +71,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_vig_sblk_0,
.xin_id = 0,
.type = SSPP_TYPE_VIG,
- .clk_ctrl = DPU_CLK_CTRL_VIG0,
}, {
.name = "sspp_1", .id = SSPP_VIG1,
.base = 0x6000, .len = 0x344,
@@ -89,7 +78,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_vig_sblk_1,
.xin_id = 4,
.type = SSPP_TYPE_VIG,
- .clk_ctrl = DPU_CLK_CTRL_VIG1,
}, {
.name = "sspp_2", .id = SSPP_VIG2,
.base = 0x8000, .len = 0x344,
@@ -97,7 +85,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_vig_sblk_2,
.xin_id = 8,
.type = SSPP_TYPE_VIG,
- .clk_ctrl = DPU_CLK_CTRL_VIG2,
}, {
.name = "sspp_3", .id = SSPP_VIG3,
.base = 0xa000, .len = 0x344,
@@ -105,7 +92,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_vig_sblk_3,
.xin_id = 12,
.type = SSPP_TYPE_VIG,
- .clk_ctrl = DPU_CLK_CTRL_VIG3,
}, {
.name = "sspp_8", .id = SSPP_DMA0,
.base = 0x24000, .len = 0x344,
@@ -113,7 +99,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sdm845_dma_sblk_0,
.xin_id = 1,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA0,
}, {
.name = "sspp_9", .id = SSPP_DMA1,
.base = 0x26000, .len = 0x344,
@@ -121,7 +106,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sdm845_dma_sblk_1,
.xin_id = 5,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA1,
}, {
.name = "sspp_10", .id = SSPP_DMA2,
.base = 0x28000, .len = 0x344,
@@ -129,7 +113,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sdm845_dma_sblk_2,
.xin_id = 9,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA2,
}, {
.name = "sspp_11", .id = SSPP_DMA3,
.base = 0x2a000, .len = 0x344,
@@ -137,7 +120,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sdm845_dma_sblk_3,
.xin_id = 13,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA3,
}, {
.name = "sspp_12", .id = SSPP_DMA4,
.base = 0x2c000, .len = 0x344,
@@ -145,7 +127,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_dma_sblk_4,
.xin_id = 14,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA4,
}, {
.name = "sspp_13", .id = SSPP_DMA5,
.base = 0x2e000, .len = 0x344,
@@ -153,7 +134,6 @@ static const struct dpu_sspp_cfg sm8550_sspp[] = {
.sblk = &sm8550_dma_sblk_5,
.xin_id = 15,
.type = SSPP_TYPE_DMA,
- .clk_ctrl = DPU_CLK_CTRL_DMA5,
},
};
--
2.34.1
[PATCH v3 2/5] drm/msm/dpu: add setup_clk_force_ctrl() op to sspp & wb
Starting from SM8550, the SSPP & WB clock controls are moved
the SSPP and WB register range, as it's called "VBIF_CLK_SPLIT"
downstream.
Implement setup_clk_force_ctrl() only starting from major version 9
which corresponds to SM8550 MDSS.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 21 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 12 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 20 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 7 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 4 ++--
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index f2192de93713..8e3c65989c49 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -69,6 +69,7 @@
#define SSPP_EXCL_REC_XY_REC1 0x188
#define SSPP_EXCL_REC_SIZE 0x1B4
#define SSPP_EXCL_REC_XY 0x1B8
+#define SSPP_CLK_CTRL 0x330
/* SSPP_SRC_OP_MODE & OP_MODE_REC1 */
#define MDSS_MDP_OP_DEINTERLACEBIT(22)
@@ -581,8 +582,18 @@ static void dpu_hw_sspp_setup_cdp(struct dpu_sw_pipe *pipe,
dpu_setup_cdp(&ctx->hw, cdp_cntl_offset, fmt, enable);
}
+static bool dpu_hw_sspp_setup_clk_force_ctrl(struct dpu_hw_sspp *ctx, bool
enable)
+{
+ static const struct dpu_clk_ctrl_reg sspp_clk_ctrl = {
+ .reg_off = SSPP_CLK_CTRL,
+ .bit_off = 0
+ };
+
+ return dpu_hw_clk_force_ctrl(&ctx->hw, &sspp_clk_ctrl, enable);
+}
+
static void _setup_layer_ops(struct dpu_hw_sspp *c,
- unsigned long features)
+ unsigned long features, const struct dpu_mdss_version *mdss_rev)
{
c->ops.setup_format = dpu_hw_sspp_setup_format;
c->ops.setup_rects = dpu_hw_sspp_setup_rects;
@@ -612,6 +623,9 @@ static void _setup_layer_ops(struct dpu_hw_sspp *c,
if (test_bit(DPU_SSPP_CDP, &features))
c->ops.setup_cdp = dpu_hw_sspp_setup_cdp;
+
+ if (mdss_rev->core_major_ver >= 9)
+ c->ops.setup_clk_force_ctrl = dpu_hw_sspp_setup_clk_force_ctrl;
}
#ifdef CONFIG_DEBUG_FS
@@ -672,7 +686,8 @@ int _dpu_hw_sspp_init_debugfs(struct dpu_hw_sspp *hw_pipe,
struct dpu_kms *kms,
#endif
struct dpu_hw_sspp *dpu_hw_sspp_init(const struct dpu_sspp_cfg *cfg,
- void __iomem *addr, const struct msm_mdss_data *mdss_data)
+ void __iomem *addr, const struct msm_mdss_data *mdss_data,
+ const struct dpu_mdss_version *mdss_rev)
{
struct dpu_hw_sspp *hw_pipe;
@@ -690,7 +705,7 @@ struct dpu_hw_sspp *dpu_hw_sspp_init(const struct
dpu_sspp_cfg *cfg,
hw_pipe->ubwc = mdss_data;
hw_pipe->idx = cfg->id;
hw_pipe->cap = cfg;
- _setup_layer_ops(hw_pipe, hw_pipe->cap->features);
+ _setup_layer_ops(hw_pipe, hw_pipe->cap->features, mdss_rev);
return hw_pipe;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index cbf4f95ff0fd..f93969fddb22 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -271,6 +271,14 @@ struct dpu_hw_sspp_ops {
void (*setup_qos_ctrl)(struct dpu_hw_sspp *ctx,
bool danger_safe_en);
+ /**
+* setup_clk_force_ctrl - setup clock force control
+* @ctx: Pointer to pipe context
+* @enable: enable clock force if true
+*/
+ bool (*setup_clk_force_ctrl)(struct dpu_hw_sspp *ctx,
+bool enable);
+
/**
* setup_histogram - setup histograms
* @ctx: Pointer to pipe context
@@ -334,9 +342,11 @@ struct dpu_kms;
* @cfg: Pipe catalog entry for which driver object is required
* @addr: Mapped register io address of MDP
* @mdss_data: UBWC / MDSS configuration data
+ * @mdss_rev: dpu core's major and minor versions
*/
struct dpu_hw_sspp *dpu_hw_sspp_init(const struct dpu_sspp_cfg *cfg,
- void __iomem *addr, const struct msm_mdss_data *mdss_data);
+ void __iomem *addr, const struct msm_mdss_data *mdss_data,
+ const struct dpu_mdss_version *mdss_rev);
/**
* dpu_hw_sspp_destroy(): Destroys SSPP driver context
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
index ebc416400382..9668fb97c047 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -43,6 +43,7 @@
#define WB_MUX0x150
#define WB_CROP_CTRL 0x154
#define WB_CROP_OFFSET0x158
+#define WB_CLK_CTRL 0x178
#define WB_CSC_BASE 0x260
#define WB_D
[PATCH v3 5/5] drm/msm/dpu: enable writeback on SM8550
Enable WB2 hardware block, enabling writeback support on this platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 4590a01c1252..d83a68a2cc0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -321,6 +321,20 @@ static const struct dpu_dsc_cfg sm8550_dsc[] = {
},
};
+static const struct dpu_wb_cfg sm8550_wb[] = {
+ {
+ .name = "wb_2", .id = WB_2,
+ .base = 0x65000, .len = 0x2c8,
+ .features = WB_SM8250_MASK,
+ .format_list = wb2_formats,
+ .num_formats = ARRAY_SIZE(wb2_formats),
+ .xin_id = 6,
+ .vbif_idx = VBIF_RT,
+ .maxlinewidth = 4096,
+ .intr_wb_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 4),
+ },
+};
+
static const struct dpu_intf_cfg sm8550_intf[] = {
{
.name = "intf_0", .id = INTF_0,
@@ -418,6 +432,8 @@ const struct dpu_mdss_cfg dpu_sm8550_cfg = {
.dsc = sm8550_dsc,
.merge_3d_count = ARRAY_SIZE(sm8550_merge_3d),
.merge_3d = sm8550_merge_3d,
+ .wb_count = ARRAY_SIZE(sm8550_wb),
+ .wb = sm8550_wb,
.intf_count = ARRAY_SIZE(sm8550_intf),
.intf = sm8550_intf,
.vbif_count = ARRAY_SIZE(sm8550_vbif),
--
2.34.1
Re: [PATCH v11 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Biju,
On Mon, Oct 2, 2023 at 2:28 PM Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the blending of two picture layers and
> raster operations (ROPs).
>
> The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> alike SoCs.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> v9->v10:
> * Added rzg2l_du_write() wrapper function.
> --- /dev/null
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> +static inline void rzg2l_du_write(struct rzg2l_du_device *rcdu, u32 reg, u32
> data)
> +{
> + writel(data, rcdu->mmio + reg);
> +}
What is the added value of this wrapper?
The order of the reg/data parameters is the inverse of the
standard writel() operation...
> + rzg2l_du_write(rcdu, DU_DITR0, ditr0);
... and using it actually needs one more keystroke than open-coding it:
- writel(ditr0, rcdu->mmio + DU_DITR0);
Sorry for missing this before.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4] backlight: pwm_bl: Disable PWM on shutdown, suspend and remove
On Mon, 09 Oct 2023 11:32:23 +0200, Uwe Kleine-König wrote:
> Since commit 00e7e698bff1 ("backlight: pwm_bl: Configure pwm only once
> per backlight toggle") calling pwm_backlight_power_off() doesn't disable
> the PWM any more. However this is necessary to suspend because PWM
> drivers usually refuse to suspend if they are still enabled.
>
> Also adapt shutdown and remove callbacks to disable the PWM for similar
> reasons.
>
> [...]
Applied, thanks!
[1/1] backlight: pwm_bl: Disable PWM on shutdown, suspend and remove
commit: 40da4737717b252fd01d92ff38d3b95a491167cc
--
Lee Jones [李琼斯]
[PULL] drm-misc-next
drm-misc-next-2023-10-12: drm-misc-next for v6.7-rc1: Contains the previous pull request drm-misc-next-2023-10-06 + following: Cross-subsystem Changes: - Rename fb_pgprot to pgprot_framebuffer and remove file argument/ - Update iosys-map documentation typos. Core Changes: - Assorted fixes to drm/panel. - Add HPD state to drm_connector_oob_hotplug_event(), and implement oob hotplug events in bridge connector. - Replace drm_framebuffer_plane_width/height with calls to drm_format_info_plane_width/height. Driver Changes: - Clock and debug fixes for bridge/samsung-dsim. - More btree -> maple tree conversions. - Assorted bugfixes in rockchip, panel-tpo-tpg110, - Add LTK050H3148W-CTA6 panel support. - Assorted small fixes in host1x, tegra, simpledrm. - Suspend fixes for host1x. The following changes since commit 389af786f92ecdff35883551d54bf4e507ffcccb: Merge tag 'drm-intel-next-2023-09-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-10-04 13:55:19 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-10-12 for you to fetch changes up to c395c83aafbb9cdbe4230f044d5b8eaf9080c0c5: drm/simpledrm: Fix power domain device link validity check (2023-10-12 10:39:48 +0200) drm-misc-next for v6.7-rc1: Contains the previous pull request drm-misc-next-2023-10-06 + following: Cross-subsystem Changes: - Rename fb_pgprot to pgprot_framebuffer and remove file argument/ - Update iosys-map documentation typos. Core Changes: - Assorted fixes to drm/panel. - Add HPD state to drm_connector_oob_hotplug_event(), and implement oob hotplug events in bridge connector. - Replace drm_framebuffer_plane_width/height with calls to drm_format_info_plane_width/height. Driver Changes: - Clock and debug fixes for bridge/samsung-dsim. - More btree -> maple tree conversions. - Assorted bugfixes in rockchip, panel-tpo-tpg110, - Add LTK050H3148W-CTA6 panel support. - Assorted small fixes in host1x, tegra, simpledrm. - Suspend fixes for host1x. Adrián Larumbe (6): drm/panfrost: Add cycle count GPU register definitions drm/panfrost: Add fdinfo support GPU load metrics drm/panfrost: Add fdinfo support for memory stats drm/drm_file: Add DRM obj's RSS reporting function for fdinfo drm/panfrost: Implement generic DRM object RSS reporting function Documentation/gpu: fix Panfrost documentation build warnings André Almeida (1): drm/doc: Document DRM device reset expectations Arnd Bergmann (1): drm/nouveau/kms/nv50: hide unused variables Arthur Grillo (2): drm/tests: Add calls to drm_fb_blit() on supported format conversion tests drm/tests: Add new format conversion tests to better cover drm_fb_blit() Bjorn Andersson (1): drm: Add HPD state to drm_connector_oob_hotplug_event() Carlos Eduardo Gallo Filho (2): drm: Remove plane hsub/vsub alignment requirement for core helpers drm: Replace drm_framebuffer plane size functions with its equivalents Chris Morgan (2): dt-bindings: display: newvision,nv3051d: Add Anbernic 351V drm/panel: nv3051d: Add Support for Anbernic 351V Christophe JAILLET (1): drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe() Danilo Krummrich (1): drm/gpuvm: doc: fix filename references Dmitry Baryshkov (2): drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb() drm/bridge_connector: implement oob_hotplug_event Douglas Anderson (1): MAINTAINERS: Document that the NXP i.MX 8MQ DCSS driver goes thru drm-misc Jani Nikula (3): drm/bridge: use drm_bridge_get_edid() instead of using ->get_edid directly drm/bridge: lt9611uxc: use drm_bridge_get_edid() instead of using ->get_edid directly drm/dp: switch drm_dp_downstream_*() helpers to struct drm_edid Johannes Zink (3): dt-bindings: display: move LVDS data-mapping definition to separate file dt-bindings: display: simple: support non-default data-mapping drm/panel-simple: allow LVDS format override Johnny Liu (1): gpu: host1x: Correct allocated size for contexts Justin Stitt (1): drm/gma500: refactor deprecated strncpy Kees Cook (9): drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by drm/i915/selftests: Annotate struct perf_series with __counted_by drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by drm/vc4: Annotate struct vc4_perfmon with __counted_by drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by drm/v3d: Annotate str
RE: [PATCH v11 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Geert Uytterhoeven,
Thanks for the feedback.
> Subject: Re: [PATCH v11 3/4] drm: renesas: Add RZ/G2L DU Support
>
> Hi Biju,
>
> On Mon, Oct 2, 2023 at 2:28 PM Biju Das
> wrote:
> > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> > along with 2 RPFs to support the blending of two picture layers and
> > raster operations (ROPs).
> >
> > The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> > alike SoCs.
> >
> > Signed-off-by: Biju Das
>
> Thanks for your patch!
>
> > v9->v10:
>
> > * Added rzg2l_du_write() wrapper function.
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
>
> > +static inline void rzg2l_du_write(struct rzg2l_du_device *rcdu, u32
> > +reg, u32 data) {
> > + writel(data, rcdu->mmio + reg); }
>
> What is the added value of this wrapper?
I think, for debugging we can add some prints here and check reg values. Other
than I don't see
any benefit here. Laurent/ Jacopo please confirm.
> The order of the reg/data parameters is the inverse of the standard
> writel() operation...
OK.
>
> > + rzg2l_du_write(rcdu, DU_DITR0, ditr0);
>
> ... and using it actually needs one more keystroke than open-coding it:
>
> - writel(ditr0, rcdu->mmio + DU_DITR0);
>
> Sorry for missing this before.
I have changed this based on review comment from Laurent and Jacopo. If the
wrapper
is not adding value, I am happy to use writel instead.
Please confirm.
Cheers,
Biju
[bug report] drm/panfrost: Add support for devcoredump
Hello Adrián Larumbe,
The patch 730c2bf4ad39: "drm/panfrost: Add support for devcoredump"
from Jul 29, 2022 (linux-next), leads to the following Smatch static
checker warning:
drivers/gpu/drm/panfrost/panfrost_dump.c:226 panfrost_core_dump()
warn: 'page' isn't an ERR_PTR
drivers/gpu/drm/panfrost/panfrost_dump.c
223 for_each_sgtable_page(bo->base.sgt, &page_iter, 0) {
224 struct page *page =
sg_page_iter_page(&page_iter);
225
--> 226 if (!IS_ERR(page)) {
^
I think this check is unnecessary. Most callers don't check. Only one
other caller does check which is rvt_reg_user_mr() and it assumes that
sg_page_iter_page() returns NULL on error.
227 *bomap++ = page_to_phys(page);
228 } else {
229 dev_err(pfdev->dev, "Panfrost Dump:
wrong page\n");
230 *bomap++ = 0;
231 }
232 }
233
234 iter.hdr->bomap.iova = mapping->mmnode.start <<
PAGE_SHIFT;
235
236 vaddr = map.vaddr;
237 memcpy(iter.data, vaddr, bo->base.base.size);
238
239 drm_gem_vunmap_unlocked(&bo->base.base, &map);
240
241 iter.hdr->bomap.valid = 1;
242
243 dump_header:panfrost_core_dump_header(&iter,
PANFROSTDUMP_BUF_BO, iter.data +
regards,
dan carpenter
[bug report] drm/exynos/iommu: merge IOMMU and DMA code
Hello Andrzej Hajda,
The patch 67fbf3a3ef84: "drm/exynos/iommu: merge IOMMU and DMA code"
from Oct 12, 2018 (linux-next), leads to the following Smatch static
checker warning:
drivers/gpu/drm/exynos/exynos_drm_dma.c:120 exynos_drm_register_dma()
warn: 'mapping' isn't an ERR_PTR
drivers/gpu/drm/exynos/exynos_drm_dma.c
95 int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
96 void **dma_priv)
97 {
98 struct exynos_drm_private *priv = drm->dev_private;
99
100 if (!priv->dma_dev) {
101 priv->dma_dev = dev;
102 DRM_INFO("Exynos DRM: using %s device for DMA mapping
operations\n",
103 dev_name(dev));
104 }
105
106 if (!IS_ENABLED(CONFIG_EXYNOS_IOMMU))
107 return 0;
108
109 if (!priv->mapping) {
110 void *mapping;
111
112 if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
113 mapping =
arm_iommu_create_mapping(&platform_bus_type,
114 EXYNOS_DEV_ADDR_START,
EXYNOS_DEV_ADDR_SIZE);
115 else if (IS_ENABLED(CONFIG_IOMMU_DMA))
116 mapping =
iommu_get_domain_for_dev(priv->dma_dev);
arm_iommu_create_mapping() and iommu_get_domain_for_dev() seem to return
NULL on error.
117 else
118 mapping = ERR_PTR(-ENODEV);
119
--> 120 if (IS_ERR(mapping))
121 return PTR_ERR(mapping);
Smatch uses the pre-compiled code so it says that mapping is always NULL
on this config...
122 priv->mapping = mapping;
123 }
124
125 return drm_iommu_attach_device(drm, dev, dma_priv);
126 }
regards,
dan carpenter
Re: [PATCH v1] dynamic_debug: add support for logs destination
On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote: > On Wed, 11 Oct 2023 11:42:24 +0200 > Daniel Vetter wrote: > > > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote: > > > On Tue, 10 Oct 2023 10:06:02 -0600 > > > jim.cro...@gmail.com wrote: > > > > > > > since I name-dropped you all, > > > > > > Hi everyone, > > > > > > I'm really happy to see this topic being developed! I've practically > > > forgot about it myself, but the need for it has not diminished at all. > > > > > > I didn't understand much of the conversation, so I'll just reiterate > > > what I would use it for, as a Wayland compositor developer. > > > > > > I added a few more cc's to get better coverage of DRM and Wayland > > > compositor developers. > > > > > > > On Tue, Oct 10, 2023 at 10:01 AM wrote: > > > > > > > > > > On Mon, Oct 9, 2023 at 4:47 PM Łukasz Bartosik > > > > > wrote: > > > > > > ... > > > > > > > > > I don't have a real life use case to configure different trace > > > > > > instance for each callsite. > > > > > > I just tried to be as much flexible as possible. > > > > > > > > > > > > > > > > Ive come around to agree - I looked back at some old threads > > > > > (that I was a part of, and barely remembered :-} > > > > > > > > > > At least Sean Paul, Lyude, Simon Ser, Pekka Paalanen > > > > > have expressed a desire for a "flight-recorder" > > > > > it'd be hard to say now that 2-3 such buffers would always be enough, > > > > > esp as theres a performance reason for having your own. > > > > > > A Wayland compositor has roughly three important things where the kernel > > > debugs might come in handy: > > > - input > > > - DRM KMS > > > - DRM GPU rendering > > > > > > DRM KMS is the one I've been thinking of in the flight recorder context > > > the most, because KMS hardware varies a lot, and there is plenty of > > > room for both KMS drivers and KMS userspace to go wrong. The usual > > > result is your display doesn't work, so the system is practically > > > unusable to the end user. In the wild, the simplest or maybe the only > > > way out of that may be a reboot, maybe an automated one (e.g. digital > > > signage). In order to debug such problems, we would need both > > > compositor logs and the relevant kernel debug messages. > > > > > > For example, Weston already has a flight recorder framework of its own, > > > so we have the compositor debug logs. It would be useful to get the > > > selected kernel debug logs in the same place. It could be used for > > > automated or semi-manual bug reporting, for example, making the > > > administrator or end user life much easier reporting issues. > > > > > > Since this is usually a production environment, and the Wayland > > > compositor runs without root privileges, we need something that works > > > with that. We would likely want the kernel debug messages in the > > > compositor to combine and order them properly with the compositor debug > > > messages. > > > > > > It's quite likely that developers would like to pick and choose which > > > kernel debug messages might be interesting enough to record, to avoid > > > excessive log flooding. The flight recorder in Weston is fixed size to > > > avoid running out of memory or disk space. I can also see that Weston > > > could have debugging options that affect which kernel debug messages it > > > subscribes to. We can have a reasonable default setup that allows us to > > > pinpoint the problem area and figure out most problems, and if needed, > > > we could ask the administrator pass another debug option to Weston. It > > > helps if there is just one place to configure everything about the > > > compositor. > > > > > > This implies that it would be really nice to have userspace subscriber > > > specific debug message streams from the kernel, or a good way to filter > > > the messages we want. A Wayland compositor would not be interested in > > > file system or wireless debugs for example, but another system > > > component might be. There is also a security aspect of which component is > > > allowed to see which messages in case they could contain anything > > > sensitive (input debug could contain typed passwords). > > > > > > Configuring the kernel debug message selection for our debug message > > > stream can and probably should require elevated privileges, and we can > > > likely solve that in userspace with a daemon or such, to allow the > > > Wayland compositor to run as a regular user. > > > > > > Thinking of desktop systems, and especially physically multi-seat systems: > > > - there can be multiple different Wayland compositors running > > > simultaneously > > > - each of them may want debug messages only from a specific DRM KMS > > > device instance, and not from others > > > - each of them may have a different idea of which debug messages are > > > important > > > - because DRM KMS leasing is a thing, different compositor instances > > > could be using
[PATCH v11 00/16] MediaTek DDP GAMMA - 12-bit LUT support
Changes in v11: - As per previous conversation with CK: - Definitions for default LUT bits were removed - Specifying number of bits per LUT component was merged into the commit adding support for 12-bit LUT - MT8195 support was moved to a new commit - Other spare changes - Added missing AAL_GAMMA_LUT_EN bit setting to mtk_aal_gamma_set() - Rebased over next-20231012 Changes in v10: - Moved snippet from patch [7/15] to patch [6/15] as that was intended to be there instead; fixes build issue for patch [6/15] as pointed out by the kernel text robot (oops, sorry!) Changes in v9: - As per previous conversation with CK Hu, added a commit that de-commonizes the gamma setting function that was used in both DISP_AAL and DISP_GAMMA, now each of them have their own .gamma_set() callback (mtk_disp_gamma_set_common() has been removed). - Added a change to use bitfield macros in mtk_disp_aal.c - Added a change to compress of_device_id entries in mtk_disp_aal.c - Tested again on MT6795, MT8173, MT8186, MT8192, MT8195 Changes in v8: - Changed lut_size to be a mtk_disp_gamma_set_common() function parameter to pass lut size from AAL Changes in v7: - Added check for NULL dev for AAL-gamma case - Added get_lut_size callback for AAL-gamma - Added comment to clarify SoC 10/12 bits support and old vs new register layout as suggested by Alexandre M. Changes in v6: - Fixed smatch warning in patch 11/11, ref.: https://lore.kernel.org/all/202306101458.lrxhee0z-...@intel.com/ Changes in v5: - Removed incorrect comment on default LUT size and bits - Removed useless check for num_lut_banks - Added comment about CMDQ implementation on patch 5 - Evaluated passing lut size/bits from AAL, idea discarded as the implementation would be rather tricky while bringing no benefits. Changes in v4: - Fixed assignment typo appeared in v3 Changes in v3: - Fixed issues due to variables renaming during cleanup (oops) - This is actually the right series, since v2 was taken from the wrong kernel tree :-) Changes in v2: - Added explicit inclusion of linux/bitfield.h in patch [06/11] This series adds support for GAMMA IP requiring and/or supporting a 12-bits LUT using a slightly different register layout and programming sequence for multiple LUT banks: this IP version is currently found on a number of SoCs, not only including the Chromebook/IoT oriented Kompanio 1200/1380 MT8195/MT8195T, but also Smartphone chips such as the Dimensity 9200 (MT6985) and others. This series was tested on MT8195, MT8192, MT8173, MT6795: * MT6795, MT8192, MT8173: No regression, works fine. * MT8195: Color correction is finally working! AngeloGioacchino Del Regno (15): drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common() drm/mediatek: gamma: Support SoC specific LUT size drm/mediatek: gamma: Improve and simplify HW LUT calculation drm/mediatek: gamma: Enable the Gamma LUT table only after programming drm/mediatek: gamma: Use bitfield macros drm/mediatek: aal: Use bitfield macros drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set functions drm/mediatek: gamma: Support multi-bank gamma LUT drm/mediatek: gamma: Add support for 12-bit LUT drm/mediatek: gamma: Add support for MT8195 drm/mediatek: gamma: Make sure relay mode is disabled drm/mediatek: gamma: Program gamma LUT type for descending or rising drm/mediatek: aal: Add kerneldoc for struct mtk_disp_aal drm/mediatek: gamma: Add kerneldoc for struct mtk_disp_gamma drm/mediatek: aal: Compress of_device_id entries and add sentinel Jason-JH.Lin (1): drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters drivers/gpu/drm/mediatek/mtk_disp_aal.c | 86 - drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 +- drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 203 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 + 7 files changed, 260 insertions(+), 52 deletions(-) -- 2.42.0
[PATCH v11 01/16] drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters
From: "Jason-JH.Lin"
Adjust the parameters in mtk_drm_gamma_set_common()
- add (struct device *dev) to get lut_diff from gamma's driver data
- remove (bool lut_diff) and use false as default value in the function
Signed-off-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 18 --
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index ce2da1ccec6f..662c5d03ee43 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -61,7 +61,7 @@ void mtk_aal_gamma_set(struct device *dev, struct
drm_crtc_state *state)
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
if (aal->data && aal->data->has_gamma)
- mtk_gamma_set_common(aal->regs, state, false);
+ mtk_gamma_set_common(NULL, aal->regs, state);
}
void mtk_aal_start(struct device *dev)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 2254038519e1..75045932353e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -54,7 +54,7 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state,
bool lut_diff);
+void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index e9242249884b..68e2565b88a5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -54,14 +54,24 @@ void mtk_gamma_clk_disable(struct device *dev)
clk_disable_unprepare(gamma->clk);
}
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state,
bool lut_diff)
+void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
+ struct mtk_disp_gamma *gamma;
unsigned int i, reg;
struct drm_color_lut *lut;
void __iomem *lut_base;
+ bool lut_diff;
u32 word;
u32 diff[3] = {0};
+ /* If we're called from AAL, dev is NULL */
+ gamma = dev ? dev_get_drvdata(dev) : NULL;
+
+ if (gamma && gamma->data)
+ lut_diff = gamma->data->lut_diff;
+ else
+ lut_diff = false;
+
if (state->gamma_lut) {
reg = readl(regs + DISP_GAMMA_CFG);
reg = reg | GAMMA_LUT_EN;
@@ -91,12 +101,8 @@ void mtk_gamma_set_common(void __iomem *regs, struct
drm_crtc_state *state, bool
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
- bool lut_diff = false;
-
- if (gamma->data)
- lut_diff = gamma->data->lut_diff;
- mtk_gamma_set_common(gamma->regs, state, lut_diff);
+ mtk_gamma_set_common(dev, gamma->regs, state);
}
void mtk_gamma_config(struct device *dev, unsigned int w,
--
2.42.0
[PATCH v11 02/16] drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common()
Invert the check for state->gamma_lut and move it at the beginning
of the function to reduce indentation: this prepares the code for
keeping readability on later additions.
This commit brings no functional changes.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 45 ---
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 68e2565b88a5..63840e25416b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -64,6 +64,10 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
u32 word;
u32 diff[3] = {0};
+ /* If there's no gamma lut there's nothing to do here. */
+ if (!state->gamma_lut)
+ return;
+
/* If we're called from AAL, dev is NULL */
gamma = dev ? dev_get_drvdata(dev) : NULL;
@@ -72,29 +76,26 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
else
lut_diff = false;
- if (state->gamma_lut) {
- reg = readl(regs + DISP_GAMMA_CFG);
- reg = reg | GAMMA_LUT_EN;
- writel(reg, regs + DISP_GAMMA_CFG);
- lut_base = regs + DISP_GAMMA_LUT;
- lut = (struct drm_color_lut *)state->gamma_lut->data;
- for (i = 0; i < MTK_LUT_SIZE; i++) {
-
- if (!lut_diff || (i % 2 == 0)) {
- word = (((lut[i].red >> 6) & LUT_10BIT_MASK) <<
20) +
- (((lut[i].green >> 6) & LUT_10BIT_MASK)
<< 10) +
- ((lut[i].blue >> 6) & LUT_10BIT_MASK);
- } else {
- diff[0] = (lut[i].red >> 6) - (lut[i - 1].red
>> 6);
- diff[1] = (lut[i].green >> 6) - (lut[i -
1].green >> 6);
- diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue
>> 6);
-
- word = ((diff[0] & LUT_10BIT_MASK) << 20) +
- ((diff[1] & LUT_10BIT_MASK) << 10) +
- (diff[2] & LUT_10BIT_MASK);
- }
- writel(word, (lut_base + i * 4));
+ reg = readl(regs + DISP_GAMMA_CFG);
+ reg = reg | GAMMA_LUT_EN;
+ writel(reg, regs + DISP_GAMMA_CFG);
+ lut_base = regs + DISP_GAMMA_LUT;
+ lut = (struct drm_color_lut *)state->gamma_lut->data;
+ for (i = 0; i < MTK_LUT_SIZE; i++) {
+ if (!lut_diff || (i % 2 == 0)) {
+ word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
+ (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
+ ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+ } else {
+ diff[0] = (lut[i].red >> 6) - (lut[i - 1].red >> 6);
+ diff[1] = (lut[i].green >> 6) - (lut[i - 1].green >> 6);
+ diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue >> 6);
+
+ word = ((diff[0] & LUT_10BIT_MASK) << 20) +
+ ((diff[1] & LUT_10BIT_MASK) << 10) +
+ (diff[2] & LUT_10BIT_MASK);
}
+ writel(word, (lut_base + i * 4));
}
}
--
2.42.0
[PATCH v11 04/16] drm/mediatek: gamma: Improve and simplify HW LUT calculation
Use drm_color_lut_extract() to avoid open-coding the bits reduction
calculations for each color channel and use a struct drm_color_lut
to temporarily store the information instead of an array of u32.
Also, slightly improve the precision of the HW LUT calculation in the
LUT DIFF case by performing the subtractions on the 16-bits values and
doing the 10 bits conversion later.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 32 ++-
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index bb237523d4b7..8506b9a0a811 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -23,8 +23,6 @@
#define DISP_GAMMA_SIZE0x0030
#define DISP_GAMMA_LUT 0x0700
-#define LUT_10BIT_MASK 0x03ff
-
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
@@ -73,7 +71,6 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
bool lut_diff;
u16 lut_size;
u32 word;
- u32 diff[3] = {0};
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -96,18 +93,29 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
for (i = 0; i < lut_size; i++) {
+ struct drm_color_lut diff, hwlut;
+
+ hwlut.red = drm_color_lut_extract(lut[i].red, 10);
+ hwlut.green = drm_color_lut_extract(lut[i].green, 10);
+ hwlut.blue = drm_color_lut_extract(lut[i].blue, 10);
+
if (!lut_diff || (i % 2 == 0)) {
- word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
- (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
- ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+ word = hwlut.red << 20 +
+ hwlut.green << 10 +
+ hwlut.red;
} else {
- diff[0] = (lut[i].red >> 6) - (lut[i - 1].red >> 6);
- diff[1] = (lut[i].green >> 6) - (lut[i - 1].green >> 6);
- diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue >> 6);
+ diff.red = lut[i].red - lut[i - 1].red;
+ diff.red = drm_color_lut_extract(diff.red, 10);
+
+ diff.green = lut[i].green - lut[i - 1].green;
+ diff.green = drm_color_lut_extract(diff.green, 10);
+
+ diff.blue = lut[i].blue - lut[i - 1].blue;
+ diff.blue = drm_color_lut_extract(diff.blue, 10);
- word = ((diff[0] & LUT_10BIT_MASK) << 20) +
- ((diff[1] & LUT_10BIT_MASK) << 10) +
- (diff[2] & LUT_10BIT_MASK);
+ word = diff.blue << 20 +
+ diff.green << 10 +
+ diff.red;
}
writel(word, (lut_base + i * 4));
}
--
2.42.0
[PATCH v11 08/16] drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set functions
In preparation for adding a 12-bits gamma support for the DISP_GAMMA
IP, remove the mtk_gamma_set_common() function and move the relevant
bits in mtk_gamma_set() for DISP_GAMMA and mtk_aal_gamma_set() for
DISP_AAL: since the latter has no more support for gamma manipulation
(being moved to a different IP) in newer revisions, those functions
are about to diverge and it makes no sense to keep a common one (with
all the complications of passing common data and making exclusions
for device driver data) for just a few bits.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 41 +--
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 -
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 34 ---
3 files changed, 46 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 05f9be23fa47..a618be9b3dba 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -17,10 +17,17 @@
#define DISP_AAL_EN0x
#define AAL_EN BIT(0)
+#define DISP_AAL_CFG 0x0020
+#define AAL_GAMMA_LUT_EN BIT(1)
#define DISP_AAL_SIZE 0x0030
#define DISP_AAL_SIZE_HSIZEGENMASK(28, 16)
#define DISP_AAL_SIZE_VSIZEGENMASK(12, 0)
#define DISP_AAL_OUTPUT_SIZE 0x04d8
+#define DISP_AAL_GAMMA_LUT 0x0700
+#define DISP_AAL_GAMMA_LUT_R GENMASK(29, 20)
+#define DISP_AAL_GAMMA_LUT_G GENMASK(19, 10)
+#define DISP_AAL_GAMMA_LUT_B GENMASK(9, 0)
+#define DISP_AAL_LUT_BITS 10
#define DISP_AAL_LUT_SIZE 512
struct mtk_disp_aal_data {
@@ -80,9 +87,39 @@ unsigned int mtk_aal_gamma_get_lut_size(struct device *dev)
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+ struct drm_color_lut *lut;
+ unsigned int i;
+ u32 cfg_val;
+
+ /* If gamma is not supported in AAL, go out immediately */
+ if (!(aal->data && aal->data->has_gamma))
+ return;
+
+ /* Also, if there's no gamma lut there's nothing to do here. */
+ if (!state->gamma_lut)
+ return;
+
+ lut = (struct drm_color_lut *)state->gamma_lut->data;
+ for (i = 0; i < DISP_AAL_LUT_SIZE; i++) {
+ struct drm_color_lut hwlut = {
+ .red = drm_color_lut_extract(lut[i].red,
DISP_AAL_LUT_BITS),
+ .green = drm_color_lut_extract(lut[i].green,
DISP_AAL_LUT_BITS),
+ .blue = drm_color_lut_extract(lut[i].blue,
DISP_AAL_LUT_BITS)
+ };
+ u32 word;
+
+ word = FIELD_PREP(DISP_AAL_GAMMA_LUT_R, hwlut.red);
+ word |= FIELD_PREP(DISP_AAL_GAMMA_LUT_G, hwlut.green);
+ word |= FIELD_PREP(DISP_AAL_GAMMA_LUT_B, hwlut.blue);
+ writel(word, aal->regs + DISP_AAL_GAMMA_LUT + i * 4);
+ }
- if (aal->data && aal->data->has_gamma)
- mtk_gamma_set_common(NULL, aal->regs, state);
+ cfg_val = readl(aal->regs + DISP_AAL_CFG);
+
+ /* Enable the gamma table */
+ cfg_val |= FIELD_PREP(AAL_GAMMA_LUT_EN, 1);
+
+ writel(cfg_val, aal->regs + DISP_AAL_CFG);
}
void mtk_aal_start(struct device *dev)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index ca377265e5eb..54d3712e2afd 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -56,7 +56,6 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
unsigned int mtk_gamma_get_lut_size(struct device *dev);
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
-void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 81c04518a5eb..0929f8830d6d 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -69,41 +69,28 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
return 0;
}
-void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
+void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
- struct mtk_disp_gamma *gamma;
+ struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
unsigned int i;
[PATCH v11 14/16] drm/mediatek: aal: Add kerneldoc for struct mtk_disp_aal
The kerneldoc for struct mtk_disp_aal is missing: write one and
document this structure.
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 15f91cea9f20..7b3e1c275056 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -35,6 +35,13 @@ struct mtk_disp_aal_data {
bool has_gamma;
};
+ /**
+ * struct mtk_disp_aal - Display Adaptive Ambient Light driver structure
+ * @clk: clock for DISP_AAL controller
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform specific data for DISP_AAL
+ */
struct mtk_disp_aal {
struct clk *clk;
void __iomem *regs;
--
2.42.0
[PATCH v11 07/16] drm/mediatek: aal: Use bitfield macros
Make the code more robust and improve readability by using bitfield
macros instead of open coding bit operations.
Reviewed-by: CK Hu
Reviewed-by: Nícolas F. R. A. Prado
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index dc26ddce0c6e..05f9be23fa47 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -18,6 +18,8 @@
#define DISP_AAL_EN0x
#define AAL_EN BIT(0)
#define DISP_AAL_SIZE 0x0030
+#define DISP_AAL_SIZE_HSIZEGENMASK(28, 16)
+#define DISP_AAL_SIZE_VSIZEGENMASK(12, 0)
#define DISP_AAL_OUTPUT_SIZE 0x04d8
#define DISP_AAL_LUT_SIZE 512
@@ -51,9 +53,13 @@ void mtk_aal_config(struct device *dev, unsigned int w,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+ u32 sz;
- mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs,
DISP_AAL_SIZE);
- mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs,
DISP_AAL_OUTPUT_SIZE);
+ sz = FIELD_PREP(DISP_AAL_SIZE_HSIZE, w);
+ sz |= FIELD_PREP(DISP_AAL_SIZE_VSIZE, h);
+
+ mtk_ddp_write(cmdq_pkt, sz, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
+ mtk_ddp_write(cmdq_pkt, sz, &aal->cmdq_reg, aal->regs,
DISP_AAL_OUTPUT_SIZE);
}
/**
--
2.42.0
[PATCH v11 15/16] drm/mediatek: gamma: Add kerneldoc for struct mtk_disp_gamma
The mtk_disp_gamma structure was completely undocumented: add some
kerneldoc documentation to it.
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 0f116c0e51b5..52c752bc5f41 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -50,8 +50,12 @@ struct mtk_disp_gamma_data {
u8 lut_bits;
};
-/*
- * struct mtk_disp_gamma - DISP_GAMMA driver structure
+/**
+ * struct mtk_disp_gamma - Display Gamma driver structure
+ * @clk: clock for DISP_GAMMA block
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform data for DISP_GAMMA
*/
struct mtk_disp_gamma {
struct clk *clk;
--
2.42.0
[PATCH v11 11/16] drm/mediatek: gamma: Add support for MT8195
Now that this driver supports 12-bit LUTs, we can add support for the
DISP_GAMMA found on the MT8195 SoC: add its driver data and compatible.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 6305cd95e6d4..bcc33aeca885 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -279,11 +279,20 @@ static const struct mtk_disp_gamma_data
mt8183_gamma_driver_data = {
.lut_size = 512,
};
+static const struct mtk_disp_gamma_data mt8195_gamma_driver_data = {
+ .lut_bank_size = 256,
+ .lut_bits = 12,
+ .lut_diff = true,
+ .lut_size = 1024,
+};
+
static const struct of_device_id mtk_disp_gamma_driver_dt_match[] = {
{ .compatible = "mediatek,mt8173-disp-gamma",
.data = &mt8173_gamma_driver_data},
{ .compatible = "mediatek,mt8183-disp-gamma",
.data = &mt8183_gamma_driver_data},
+ { .compatible = "mediatek,mt8195-disp-gamma",
+ .data = &mt8195_gamma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
--
2.42.0
[PATCH v11 10/16] drm/mediatek: gamma: Add support for 12-bit LUT
New SoCs, like MT8195, not only may support bigger lookup tables, but
have got a different register layout to support bigger precision:
support specifying the number of `lut_bits` for each SoC and use it
in mtk_gamma_set_common() to perform the right calculations and add
support for 12-bit gamma lookup tables.
While at it, also reorder the variables in mtk_gamma_set_common()
and rename `lut_base` to `lut0_base` to improve readability.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 83 +--
1 file changed, 64 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 911468984ad5..6305cd95e6d4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -26,17 +26,26 @@
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
#define DISP_GAMMA_BANK0x0100
#define DISP_GAMMA_BANK_BANK GENMASK(1, 0)
+#define DISP_GAMMA_BANK_DATA_MODE BIT(2)
#define DISP_GAMMA_LUT 0x0700
+#define DISP_GAMMA_LUT10x0b00
+/* For 10 bit LUT layout, R/G/B are in the same register */
#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
#define DISP_GAMMA_LUT_10BIT_G GENMASK(19, 10)
#define DISP_GAMMA_LUT_10BIT_B GENMASK(9, 0)
+/* For 12 bit LUT layout, R/G are in LUT, B is in LUT1 */
+#define DISP_GAMMA_LUT_12BIT_R GENMASK(11, 0)
+#define DISP_GAMMA_LUT_12BIT_G GENMASK(23, 12)
+#define DISP_GAMMA_LUT_12BIT_B GENMASK(11, 0)
+
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
u16 lut_bank_size;
u16 lut_size;
+ u8 lut_bits;
};
/*
@@ -72,28 +81,48 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
return 0;
}
+/*
+ * SoCs supporting 12-bits LUTs are using a new register layout that does
+ * always support (by HW) both 12-bits and 10-bits LUT but, on those, we
+ * ignore the support for 10-bits in this driver and always use 12-bits.
+ *
+ * Summarizing:
+ * - SoC HW support 9/10-bits LUT only
+ * - Old register layout
+ * - 10-bits LUT supported
+ * - 9-bits LUT not supported
+ * - SoC HW support both 10/12bits LUT
+ * - New register layout
+ * - 12-bits LUT supported
+ * - 10-its LUT not supported
+ */
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
- unsigned int i;
- struct drm_color_lut *lut;
- void __iomem *lut_base;
- u32 cfg_val, lbank_val, word;
+ void __iomem *lut0_base = gamma->regs + DISP_GAMMA_LUT;
+ void __iomem *lut1_base = gamma->regs + DISP_GAMMA_LUT1;
+ u32 cfg_val, data_mode, lbank_val, word[2];
+ u8 lut_bits = gamma->data->lut_bits;
int cur_bank, num_lut_banks;
+ struct drm_color_lut *lut;
+ unsigned int i;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
return;
num_lut_banks = gamma->data->lut_size / gamma->data->lut_bank_size;
- lut_base = gamma->regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
+ /* Switch to 12 bits data mode if supported */
+ data_mode = FIELD_PREP(DISP_GAMMA_BANK_DATA_MODE, !!(lut_bits == 12));
+
for (cur_bank = 0; cur_bank < num_lut_banks; cur_bank++) {
/* Switch gamma bank and set data mode before writing LUT */
if (num_lut_banks > 1) {
lbank_val = FIELD_PREP(DISP_GAMMA_BANK_BANK, cur_bank);
+ lbank_val |= data_mode;
writel(lbank_val, gamma->regs + DISP_GAMMA_BANK);
}
@@ -101,29 +130,43 @@ void mtk_gamma_set(struct device *dev, struct
drm_crtc_state *state)
int n = cur_bank * gamma->data->lut_bank_size + i;
struct drm_color_lut diff, hwlut;
- hwlut.red = drm_color_lut_extract(lut[n].red, 10);
- hwlut.green = drm_color_lut_extract(lut[n].green, 10);
- hwlut.blue = drm_color_lut_extract(lut[n].blue, 10);
+ hwlut.red = drm_color_lut_extract(lut[n].red, lut_bits);
+ hwlut.green = drm_color_lut_extract(lut[n].green,
lut_bits);
+ hwlut.blue = drm_color_lut_extract(lut[n].blue,
lut_bits);
if (!gamma->data->lut_diff || (i % 2 == 0)) {
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R,
hwlut.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G,
hwlut.green)
[PATCH v11 12/16] drm/mediatek: gamma: Make sure relay mode is disabled
Disable relay mode at the end of LUT programming to make sure that the processed image goes through in both DISP_GAMMA and DISP_AAL for gamma setting. Reviewed-by: Jason-JH.Lin Reviewed-by: Alexandre Mergnat Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_disp_aal.c | 4 drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c index a618be9b3dba..15f91cea9f20 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c @@ -18,6 +18,7 @@ #define DISP_AAL_EN0x #define AAL_EN BIT(0) #define DISP_AAL_CFG 0x0020 +#define AAL_RELAY_MODE BIT(0) #define AAL_GAMMA_LUT_EN BIT(1) #define DISP_AAL_SIZE 0x0030 #define DISP_AAL_SIZE_HSIZEGENMASK(28, 16) @@ -119,6 +120,9 @@ void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state) /* Enable the gamma table */ cfg_val |= FIELD_PREP(AAL_GAMMA_LUT_EN, 1); + /* Disable RELAY mode to pass the processed image */ + cfg_val &= ~AAL_RELAY_MODE; + writel(cfg_val, aal->regs + DISP_AAL_CFG); } diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c index bcc33aeca885..6746033615db 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c @@ -19,6 +19,7 @@ #define DISP_GAMMA_EN 0x #define GAMMA_EN BIT(0) #define DISP_GAMMA_CFG 0x0020 +#define GAMMA_RELAY_MODE BIT(0) #define GAMMA_LUT_EN BIT(1) #define GAMMA_DITHERINGBIT(2) #define DISP_GAMMA_SIZE0x0030 @@ -175,6 +176,9 @@ void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state) /* Enable the gamma table */ cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1); + /* Disable RELAY mode to pass the processed image */ + cfg_val &= ~GAMMA_RELAY_MODE; + writel(cfg_val, gamma->regs + DISP_GAMMA_CFG); } -- 2.42.0
[PATCH v11 03/16] drm/mediatek: gamma: Support SoC specific LUT size
Newer SoCs support a bigger Gamma LUT table: wire up a callback
to retrieve the correct LUT size for each different Gamma IP.
Co-developed-by: Jason-JH.Lin
Signed-off-by: Jason-JH.Lin
[Angelo: Rewritten commit message/description + porting]
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 17 +++-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 ++
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 22 ++---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++--
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 +
7 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 662c5d03ee43..dc26ddce0c6e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -19,7 +19,7 @@
#define AAL_EN BIT(0)
#define DISP_AAL_SIZE 0x0030
#define DISP_AAL_OUTPUT_SIZE 0x04d8
-
+#define DISP_AAL_LUT_SIZE 512
struct mtk_disp_aal_data {
bool has_gamma;
@@ -56,6 +56,21 @@ void mtk_aal_config(struct device *dev, unsigned int w,
mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs,
DISP_AAL_OUTPUT_SIZE);
}
+/**
+ * mtk_aal_gamma_get_lut_size() - Get gamma LUT size for AAL
+ * @dev: Pointer to struct device
+ *
+ * Return: 0 if gamma control not supported in AAL or gamma LUT size
+ */
+unsigned int mtk_aal_gamma_get_lut_size(struct device *dev)
+{
+ struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+ if (aal->data && aal->data->has_gamma)
+ return DISP_AAL_LUT_SIZE;
+ return 0;
+}
+
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 75045932353e..ca377265e5eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -17,6 +17,7 @@ void mtk_aal_clk_disable(struct device *dev);
void mtk_aal_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+unsigned int mtk_aal_gamma_get_lut_size(struct device *dev);
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
void mtk_aal_start(struct device *dev);
void mtk_aal_stop(struct device *dev);
@@ -53,6 +54,7 @@ void mtk_gamma_clk_disable(struct device *dev);
void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+unsigned int mtk_gamma_get_lut_size(struct device *dev);
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 63840e25416b..bb237523d4b7 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -28,6 +28,7 @@
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
+ u16 lut_size;
};
/*
@@ -54,6 +55,15 @@ void mtk_gamma_clk_disable(struct device *dev)
clk_disable_unprepare(gamma->clk);
}
+unsigned int mtk_gamma_get_lut_size(struct device *dev)
+{
+ struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
+
+ if (gamma && gamma->data)
+ return gamma->data->lut_size;
+ return 0;
+}
+
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma;
@@ -61,6 +71,7 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
struct drm_color_lut *lut;
void __iomem *lut_base;
bool lut_diff;
+ u16 lut_size;
u32 word;
u32 diff[3] = {0};
@@ -71,17 +82,20 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
/* If we're called from AAL, dev is NULL */
gamma = dev ? dev_get_drvdata(dev) : NULL;
- if (gamma && gamma->data)
+ if (gamma && gamma->data) {
lut_diff = gamma->data->lut_diff;
- else
+ lut_size = gamma->data->lut_size;
+ } else {
lut_diff = false;
+ lut_size = 512;
+ }
reg = readl(regs + DISP_GAMMA_CFG);
reg = reg | GAMMA_LUT_EN;
writel(reg, regs
[PATCH v11 13/16] drm/mediatek: gamma: Program gamma LUT type for descending or rising
All of the SoCs that don't have dithering control in the gamma IP
have got a GAMMA_LUT_TYPE bit that tells to the IP if the LUT is
"descending" (bit set) or "rising" (bit cleared): make sure to set
it correctly after programming the LUT.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 6746033615db..0f116c0e51b5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -22,6 +22,7 @@
#define GAMMA_RELAY_MODE BIT(0)
#define GAMMA_LUT_EN BIT(1)
#define GAMMA_DITHERINGBIT(2)
+#define GAMMA_LUT_TYPE BIT(2)
#define DISP_GAMMA_SIZE0x0030
#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
@@ -82,6 +83,17 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
return 0;
}
+static bool mtk_gamma_lut_is_descending(struct drm_color_lut *lut, u32
lut_size)
+{
+ u64 first, last;
+ int last_entry = lut_size - 1;
+
+ first = lut[0].red + lut[0].green + lut[0].blue;
+ last = lut[last_entry].red + lut[last_entry].green +
lut[last_entry].blue;
+
+ return !!(first > last);
+}
+
/*
* SoCs supporting 12-bits LUTs are using a new register layout that does
* always support (by HW) both 12-bits and 10-bits LUT but, on those, we
@@ -173,6 +185,14 @@ void mtk_gamma_set(struct device *dev, struct
drm_crtc_state *state)
cfg_val = readl(gamma->regs + DISP_GAMMA_CFG);
+ if (!gamma->data->has_dither) {
+ /* Descending or Rising LUT */
+ if (mtk_gamma_lut_is_descending(lut, gamma->data->lut_size - 1))
+ cfg_val |= FIELD_PREP(GAMMA_LUT_TYPE, 1);
+ else
+ cfg_val &= ~GAMMA_LUT_TYPE;
+ }
+
/* Enable the gamma table */
cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1);
--
2.42.0
Re: [EXTERNAL] Re: [PATCH v7 02/20] drm/gpuvm: Helper to get range of unmap from a remap op.
Hi Danilo,
Thanks for the feedback. The change has been made and will be in the next
version.
Thanks,
Donald
On Tue, 2023-10-10 at 18:31 +0200, Danilo Krummrich wrote:
> *** CAUTION: This email originates from a source not known to Imagination
> Technologies. Think before you click a link or open an attachment ***
>
> On 10/10/23 15:37, Sarah Walker wrote:
> > From: Donald Robson
> >
> > Determining the start and range of the unmap stage of a remap op is a
> > common piece of code currently implemented by multiple drivers. Add a
> > helper for this.
> >
> > Changes since v6:
> > - Remove use of __always_inline
> >
> > Signed-off-by: Donald Robson
> > Signed-off-by: Sarah Walker
> > ---
> > include/drm/drm_gpuvm.h | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
> > index c7ed6bf441d4..932e942da921 100644
> > --- a/include/drm/drm_gpuvm.h
> > +++ b/include/drm/drm_gpuvm.h
> > @@ -702,4 +702,31 @@ void drm_gpuva_remap(struct drm_gpuva *prev,
> >
> > void drm_gpuva_unmap(struct drm_gpuva_op_unmap *op);
> >
> > +/**
> > + * drm_gpuva_op_remap_get_unmap_range() - Helper to get the start and
> > range of
>
> Not a strong opinion on that, but maybe drm_gpuva_op_remap_to_unmap_range()
> would
> be a bit better.
>
> > + * the unmap stage of a remap op.
> > + * @op: Remap op.
> > + * @start_addr: Output pointer for the start of the required unmap.
> > + * @range: Output pointer for the length of the required unmap.
> > + *
> > + * These parameters can then be used by the caller to unmap memory pages
> > that
> > + * are no longer required.
>
> I think we should be a bit more precise on what this is good for. Maybe
> something
> like: "The given start address and range will be set such that they represent
> the
> range of the address space that was previously covered by the mapping getting
> re-mapped, but is empty now."
>
> > + */
> > +static inline void
> > +drm_gpuva_op_remap_get_unmap_range(const struct drm_gpuva_op_remap *op,
> > + u64 *start_addr, u64 *range)
> > +{
> > + const u64 va_start = op->prev ?
> > +op->prev->va.addr + op->prev->va.range :
> > +op->unmap->va->va.addr;
> > + const u64 va_end = op->next ?
> > + op->next->va.addr :
> > + op->unmap->va->va.addr + op->unmap->va->va.range;
> > +
> > + if (start_addr)
> > + *start_addr = va_start;
> > + if (range)
> > + *range = va_end - va_start;
> > +}
> > +
> > #endif /* __DRM_GPUVM_H__ */
[PATCH v11 16/16] drm/mediatek: aal: Compress of_device_id entries and add sentinel
Compress the entry for mediatek,mt8173-disp-aal, as it fits in one
line, and fix the style; while at it, also add the usual sentinel
comment to the last entry.
This commit brings no functional changes.
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 7b3e1c275056..677e7d378e7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -209,10 +209,9 @@ static const struct mtk_disp_aal_data
mt8173_aal_driver_data = {
};
static const struct of_device_id mtk_disp_aal_driver_dt_match[] = {
- { .compatible = "mediatek,mt8173-disp-aal",
- .data = &mt8173_aal_driver_data},
- { .compatible = "mediatek,mt8183-disp-aal"},
- {},
+ { .compatible = "mediatek,mt8173-disp-aal", .data =
&mt8173_aal_driver_data },
+ { .compatible = "mediatek,mt8183-disp-aal" },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
--
2.42.0
[PATCH v11 05/16] drm/mediatek: gamma: Enable the Gamma LUT table only after programming
Move the write to DISP_GAMMA_CFG to enable the Gamma LUT to after
programming the actual table to avoid potential visual glitches during
table modification.
Note:
GAMMA should get enabled in between vblanks, but this requires many
efforts in order to make this happen, as that requires migrating all
of the writes to make use of CMDQ instead of cpu writes and that's
not trivial. For this reason, this patch only moves the LUT enable.
The CMDQ rework will come at a later time.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 8506b9a0a811..d35eaf6dbc2d 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -65,12 +65,12 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma;
- unsigned int i, reg;
+ unsigned int i;
struct drm_color_lut *lut;
void __iomem *lut_base;
bool lut_diff;
u16 lut_size;
- u32 word;
+ u32 cfg_val, word;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -87,9 +87,6 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
lut_size = 512;
}
- reg = readl(regs + DISP_GAMMA_CFG);
- reg = reg | GAMMA_LUT_EN;
- writel(reg, regs + DISP_GAMMA_CFG);
lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
for (i = 0; i < lut_size; i++) {
@@ -119,6 +116,13 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
}
writel(word, (lut_base + i * 4));
}
+
+ cfg_val = readl(regs + DISP_GAMMA_CFG);
+
+ /* Enable the gamma table */
+ cfg_val |= GAMMA_LUT_EN;
+
+ writel(cfg_val, regs + DISP_GAMMA_CFG);
}
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
--
2.42.0
[PATCH v11 06/16] drm/mediatek: gamma: Use bitfield macros
Make the code more robust and improve readability by using bitfield
macros instead of open coding bit operations.
While at it, also add a definition for LUT_BITS_DEFAULT.
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 28 +++
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index d35eaf6dbc2d..81c04518a5eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -3,6 +3,7 @@
* Copyright (c) 2021 MediaTek Inc.
*/
+#include
#include
#include
#include
@@ -21,8 +22,14 @@
#define GAMMA_LUT_EN BIT(1)
#define GAMMA_DITHERINGBIT(2)
#define DISP_GAMMA_SIZE0x0030
+#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
+#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
#define DISP_GAMMA_LUT 0x0700
+#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
+#define DISP_GAMMA_LUT_10BIT_G GENMASK(19, 10)
+#define DISP_GAMMA_LUT_10BIT_B GENMASK(9, 0)
+
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
@@ -97,9 +104,9 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
hwlut.blue = drm_color_lut_extract(lut[i].blue, 10);
if (!lut_diff || (i % 2 == 0)) {
- word = hwlut.red << 20 +
- hwlut.green << 10 +
- hwlut.red;
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, hwlut.green);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, hwlut.blue);
} else {
diff.red = lut[i].red - lut[i - 1].red;
diff.red = drm_color_lut_extract(diff.red, 10);
@@ -110,9 +117,9 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
diff.blue = lut[i].blue - lut[i - 1].blue;
diff.blue = drm_color_lut_extract(diff.blue, 10);
- word = diff.blue << 20 +
- diff.green << 10 +
- diff.red;
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, diff.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, diff.green);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, diff.blue);
}
writel(word, (lut_base + i * 4));
}
@@ -120,7 +127,7 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
cfg_val = readl(regs + DISP_GAMMA_CFG);
/* Enable the gamma table */
- cfg_val |= GAMMA_LUT_EN;
+ cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1);
writel(cfg_val, regs + DISP_GAMMA_CFG);
}
@@ -137,9 +144,12 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
+ u32 sz;
+
+ sz = FIELD_PREP(DISP_GAMMA_SIZE_HSIZE, w);
+ sz |= FIELD_PREP(DISP_GAMMA_SIZE_VSIZE, h);
- mtk_ddp_write(cmdq_pkt, h << 16 | w, &gamma->cmdq_reg, gamma->regs,
- DISP_GAMMA_SIZE);
+ mtk_ddp_write(cmdq_pkt, sz, &gamma->cmdq_reg, gamma->regs,
DISP_GAMMA_SIZE);
if (gamma->data && gamma->data->has_dither)
mtk_dither_set_common(gamma->regs, &gamma->cmdq_reg, bpc,
DISP_GAMMA_CFG, GAMMA_DITHERING,
cmdq_pkt);
--
2.42.0
[PATCH v11 09/16] drm/mediatek: gamma: Support multi-bank gamma LUT
Newer Gamma IP have got multiple LUT banks: support specifying the
size of the LUT banks and handle bank-switching before programming
the LUT in mtk_gamma_set_common() in preparation for adding support
for MT8195 and newer SoCs.
Suggested-by: Jason-JH.Lin
[Angelo: Refactored original commit]
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 70 ++-
1 file changed, 44 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 0929f8830d6d..911468984ad5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -24,6 +24,8 @@
#define DISP_GAMMA_SIZE0x0030
#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
+#define DISP_GAMMA_BANK0x0100
+#define DISP_GAMMA_BANK_BANK GENMASK(1, 0)
#define DISP_GAMMA_LUT 0x0700
#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
@@ -33,6 +35,7 @@
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
+ u16 lut_bank_size;
u16 lut_size;
};
@@ -75,40 +78,53 @@ void mtk_gamma_set(struct device *dev, struct
drm_crtc_state *state)
unsigned int i;
struct drm_color_lut *lut;
void __iomem *lut_base;
- u32 cfg_val, word;
+ u32 cfg_val, lbank_val, word;
+ int cur_bank, num_lut_banks;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
return;
+ num_lut_banks = gamma->data->lut_size / gamma->data->lut_bank_size;
lut_base = gamma->regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
- for (i = 0; i < gamma->data->lut_size; i++) {
- struct drm_color_lut diff, hwlut;
-
- hwlut.red = drm_color_lut_extract(lut[i].red, 10);
- hwlut.green = drm_color_lut_extract(lut[i].green, 10);
- hwlut.blue = drm_color_lut_extract(lut[i].blue, 10);
-
- if (!gamma->data->lut_diff || (i % 2 == 0)) {
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, hwlut.green);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, hwlut.blue);
- } else {
- diff.red = lut[i].red - lut[i - 1].red;
- diff.red = drm_color_lut_extract(diff.red, 10);
-
- diff.green = lut[i].green - lut[i - 1].green;
- diff.green = drm_color_lut_extract(diff.green, 10);
-
- diff.blue = lut[i].blue - lut[i - 1].blue;
- diff.blue = drm_color_lut_extract(diff.blue, 10);
-
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, diff.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, diff.green);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, diff.blue);
+
+ for (cur_bank = 0; cur_bank < num_lut_banks; cur_bank++) {
+
+ /* Switch gamma bank and set data mode before writing LUT */
+ if (num_lut_banks > 1) {
+ lbank_val = FIELD_PREP(DISP_GAMMA_BANK_BANK, cur_bank);
+ writel(lbank_val, gamma->regs + DISP_GAMMA_BANK);
+ }
+
+ for (i = 0; i < gamma->data->lut_bank_size; i++) {
+ int n = cur_bank * gamma->data->lut_bank_size + i;
+ struct drm_color_lut diff, hwlut;
+
+ hwlut.red = drm_color_lut_extract(lut[n].red, 10);
+ hwlut.green = drm_color_lut_extract(lut[n].green, 10);
+ hwlut.blue = drm_color_lut_extract(lut[n].blue, 10);
+
+ if (!gamma->data->lut_diff || (i % 2 == 0)) {
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R,
hwlut.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G,
hwlut.green);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B,
hwlut.blue);
+ } else {
+ diff.red = lut[n].red - lut[n - 1].red;
+ diff.red = drm_color_lut_extract(diff.red, 10);
+
+ diff.green = lut[n].green - lut[n - 1].green;
+ diff.green = drm_color_lut_extract(diff.green,
10);
+
+ diff.blue = lut[n].blue - lut[n - 1].blue;
+ diff.blue = drm_color_lut_extract(diff.blue,
10);
+
+ word = FIELD_PREP(DISP_GAMMA_LUT_10B
Re: [PATCH v4 1/3] drm/bridge: add transparent bridge helper
On Wed, Oct 11, 2023 at 02:10:16AM +0300, Dmitry Baryshkov wrote:
> Define a helper for creating simple transparent bridges which serve the
> only purpose of linking devices into the bridge chain up to the last
> bridge representing the connector. This is especially useful for
> DP/USB-C bridge chains, which can span across several devices, but do
> not require any additional functionality from the intermediate bridges.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/Kconfig | 9 ++
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/aux-bridge.c | 132
> include/drm/bridge/aux-bridge.h | 19
> 4 files changed, 161 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c
> create mode 100644 include/drm/bridge/aux-bridge.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ba82a1142adf..f12eab62799f 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -12,6 +12,15 @@ config DRM_PANEL_BRIDGE
> help
> DRM bridge wrapper of DRM panels
>
> +config DRM_AUX_BRIDGE
> + tristate
> + depends on DRM_BRIDGE && OF
> + select AUXILIARY_BUS
> + select DRM_PANEL_BRIDGE
> + help
> + Simple transparent bridge that is used by several non-DRM drivers to
> + build bridges chain.
> +
> menu "Display Interface Bridges"
> depends on DRM && DRM_BRIDGE
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 2b892b7ed59e..918e3bfff079 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
> obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
> diff --git a/drivers/gpu/drm/bridge/aux-bridge.c
> b/drivers/gpu/drm/bridge/aux-bridge.c
> new file mode 100644
> index ..13fe794592f2
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/aux-bridge.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + *
> + * Author: Dmitry Baryshkov
> + */
> +#include
> +#include
> +
> +#include
> +#include
> +
> +static DEFINE_IDA(aux_bridge_ida);
> +
> +static void drm_aux_bridge_release(struct device *dev)
> +{
> + struct auxiliary_device *adev = to_auxiliary_dev(dev);
> +
> + ida_free(&aux_bridge_ida, adev->id);
> +
> + kfree(adev);
> +}
> +
> +static void drm_aux_bridge_unregister_adev(void *_adev)
> +{
> + struct auxiliary_device *adev = _adev;
> +
> + auxiliary_device_delete(adev);
> + auxiliary_device_uninit(adev);
> +}
> +
> +int drm_aux_bridge_register(struct device *parent)
> +{
> + struct auxiliary_device *adev;
> + int ret;
> +
> + adev = kzalloc(sizeof(*adev), GFP_KERNEL);
> + if (!adev)
> + return -ENOMEM;
> +
> + ret = ida_alloc(&aux_bridge_ida, GFP_KERNEL);
> + if (ret < 0) {
> + kfree(adev);
> + return ret;
> + }
> +
> + adev->id = ret;
> + adev->name = "aux_bridge";
> + adev->dev.parent = parent;
> +#ifdef CONFIG_OF
> + adev->dev.of_node = parent->of_node;
> +#endif
> + adev->dev.release = drm_aux_bridge_release;
> +
> + ret = auxiliary_device_init(adev);
> + if (ret) {
> + ida_free(&aux_bridge_ida, adev->id);
> + kfree(adev);
> + return ret;
> + }
> +
> + ret = auxiliary_device_add(adev);
> + if (ret) {
> + auxiliary_device_uninit(adev);
> + return ret;
> + }
> +
> + return devm_add_action_or_reset(parent, drm_aux_bridge_unregister_adev,
> adev);
> +}
> +EXPORT_SYMBOL_GPL(drm_aux_bridge_register);
kerneldoc for new interfaces please (you can wait if you're not sure
whether this design will land or not, but for merging we really want all
drm interfaces exposed to drivers documented). Ideally with enough links
to other interfaces/structs/docs so that people can understand what this
does and why.
Thanks, Sima
> +
> +struct drm_aux_bridge_data {
> + struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
> + struct device *dev;
> +};
> +
> +static int drm_aux_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
> +{
> + struct drm_aux_bridge_data *data;
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + return -EINVAL;
> +
> + data = container_of(bridge, struct drm_aux_bridge_data, bridge);
> +
> + return drm_bridge_attach(bridge->encoder, data->next_bridge, bridge,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +}
> +
> +static const struct drm_bridge_funcs drm_aux_bridge_funcs = {
> + .attach = drm_aux_bridge_attach,
> +};
>
Re: [PATCH v7 14/16] dt-bindings: display: mediatek: ovl: add compatible for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add a compatible string for the OVL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 13/16] dt-bindings: display: mediatek: merge: add compatible for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add a compatible string for the MERGE block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 11/16] dt-bindings: display: mediatek: aal: add compatible for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add a compatible string for the AAL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho Acked-by: Conor Dooley Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add a compatible string for the COLOR block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 10/16] dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto:
Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
new file mode 100644
index ..92e1547e7c7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 TDSHP
Please unroll it
MediaTek Media Data Path 3 Two-Dimensional Sharpness
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to improve image
+ sharpness and contrast.
Two-Dimensional Sharpness (TDSHP) is a MDP3 component used to perform
image edge sharpening and enhance vividness and contrast.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-tdshp
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14007000 {
+compatible = "mediatek,mt8195-mdp3-tdshp";
+reg = <0x14007000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x7000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_TDSHP>;
+};
Re: [PATCH v7 09/16] dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add the fundamental hardware configuration of component TCC, which is controlled by MDP3 on MT8195. Signed-off-by: Moudy Ho --- .../bindings/media/mediatek,mdp3-tcc.yaml | 62 +++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml new file mode 100644 index ..f134160f85b9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,mdp3-tcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Media Data Path 3 TCC MediaTek Media Data Path 3 Tone Curve Conversion after which: Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 07/16] dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add the fundamental hardware configuration of component HDR, which is controlled by MDP3 on MT8195. Signed-off-by: Moudy Ho --- .../bindings/media/mediatek,mdp3-hdr.yaml | 60 +++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml new file mode 100644 index ..98db6cb4d03a --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,mdp3-hdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Media Data Path 3 HDR Remapping + +maintainers: + - Matthias Brugger + - Moudy Ho + +description: + One of Media Data Path 3 (MDP3) components used to perform HDR to SDR A Media Data Path 3 (MDP3) component used to perform conversion from High Dynamic Range (HDR) to Standard Dynamic Range (SDR). after which Reviewed-by: AngeloGioacchino Del Regno
Re: [Intel-gfx] [PATCH] drm/i915/guc: Suppress 'ignoring reset notification' message
On 21/09/2023 19:20, john.c.harri...@intel.com wrote:
From: John Harrison
If an active context has been banned (e.g. Ctrl+C killed) then it is
likely to be reset as part of evicting it from the hardware. That
results in a 'ignoring context reset notification: banned = 1'
message at info level. This confuses/concerns people and makes them
thing something has gone wrong when it hasn't.
Noticed the "confuses/concerns people" part while preparing the 6.7 pull
request, and the fact there is no Fixes: tag. Is this something that
would be worth sending to stable (manually and if yes could you do that
please? If there were actual user bugs filed I guess.
Regards,
Tvrtko
There is already a debug level message with essentially the same
information. So drop the 'ignore' info level one and just add the
'ignore' flag to the debug level one instead (which will therefore not
appear by default but will still show up in CI runs).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index cabdc645fcddb..da7331346df1f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4770,19 +4770,19 @@ static void guc_context_replay(struct intel_context *ce)
static void guc_handle_context_reset(struct intel_guc *guc,
struct intel_context *ce)
{
+ bool capture = intel_context_is_schedulable(ce);
+
trace_intel_context_reset(ce);
- guc_dbg(guc, "Got context reset notification: 0x%04X on %s, exiting = %s, banned = %s\n",
+ guc_dbg(guc, "%s context reset notification: 0x%04X on %s, exiting = %s,
banned = %s\n",
+ capture ? "Got" : "Ignoring",
ce->guc_id.id, ce->engine->name,
str_yes_no(intel_context_is_exiting(ce)),
str_yes_no(intel_context_is_banned(ce)));
- if (likely(intel_context_is_schedulable(ce))) {
+ if (capture) {
capture_error_state(guc, ce);
guc_context_replay(ce);
- } else {
- guc_info(guc, "Ignoring context reset notification of exiting
context 0x%04X on %s",
-ce->guc_id.id, ce->engine->name);
}
}
Re: [PATCH v7 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195
Il 12/10/23 10:40, Moudy Ho ha scritto: Add the fundamental hardware configuration of component FG, which is controlled by MDP3 on MT8195. Signed-off-by: Moudy Ho --- .../bindings/media/mediatek,mdp3-fg.yaml | 61 +++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml new file mode 100644 index ..82f4c182c77a --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Media Data Path 3 FG MediaTek Media Data Path 3 Film Grain + +maintainers: + - Matthias Brugger + - Moudy Ho + +description: Film Grain (FG) is a Media Data Path 3 (MDP3) component used to add the film grain according to the AOMedia Video 1 (AV1) standard after which Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 05/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
Il 12/10/23 10:40, Moudy Ho ha scritto: MT8195 WROT inherited from MT8183, add the corresponding compatible name to it. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 04/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
Il 12/10/23 10:40, Moudy Ho ha scritto: MT8195 RSZ inherited from MT8183, add the corresponding compatible name to it. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v7 03/16] dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
Il 12/10/23 10:40, Moudy Ho ha scritto: Added the configuration for MT8195 RDMA. In comparison to MT8183, it no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox. Signed-off-by: Moudy Ho Reviewed-by: AngeloGioacchino Del Regno
[PULL] drm-intel-gt-next
Hi Dave, Daniel, Here is the second pull request for 6.7. I say second and not final because there is a very small chance we might be doing another one next week, to bring Meteorlake out of force probe status, which was quite close this week but apparently not quite there. At the moment it looks like chances are low, with some last minute findings putting a spanner in the works so this will likely end up the final pull request after all. In terms of content there is not much in this one. Mostly more work on enabling Meteorlake and some minor fixes here and there. Regards, Tvrtko drm-intel-gt-next-2023-10-12: Driver Changes: Fixes/improvements/new stuff: - Register engines early to avoid type confusion (Mathias Krause) - Suppress 'ignoring reset notification' message [guc] (John Harrison) - Update 'recommended' version to 70.12.1 for DG2/ADL-S/ADL-P/MTL [guc] (John Harrison) - Enable WA 14018913170 [guc, dg2] (Daniele Ceraolo Spurio) Future platform enablement: - Clean steer semaphore on resume (Nirmoy Das) - Skip MCR ops for ring fault register [mtl] (Nirmoy Das) - Make i915_gem_shrinker multi-gt aware [gem] (Jonathan Cavitt) - Enable GGTT updates with binder in MTL (Nirmoy Das, Chris Wilson) - Invalidate the TLBs on each GT (Chris Wilson) Miscellaneous: - Clarify type evolution of uabi_node/uabi_engines (Mathias Krause) - Annotate struct ct_incoming_msg with __counted_by [guc] (Kees Cook) - More use of GT specific print helpers [gt] (John Harrison) The following changes since commit 03d681412b38558aefe4fb0f46e36efa94bb21ef: drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux inval (2023-09-28 11:39:30 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-10-12 for you to fetch changes up to 039adf3947252693f7c882607dac2dc67e7f7ab2: drm/i915: More use of GT specific print helpers (2023-10-10 15:40:26 -0700) Driver Changes: Fixes/improvements/new stuff: - Register engines early to avoid type confusion (Mathias Krause) - Suppress 'ignoring reset notification' message [guc] (John Harrison) - Update 'recommended' version to 70.12.1 for DG2/ADL-S/ADL-P/MTL [guc] (John Harrison) - Enable WA 14018913170 [guc, dg2] (Daniele Ceraolo Spurio) Future platform enablement: - Clean steer semaphore on resume (Nirmoy Das) - Skip MCR ops for ring fault register [mtl] (Nirmoy Das) - Make i915_gem_shrinker multi-gt aware [gem] (Jonathan Cavitt) - Enable GGTT updates with binder in MTL (Nirmoy Das, Chris Wilson) - Invalidate the TLBs on each GT (Chris Wilson) Miscellaneous: - Clarify type evolution of uabi_node/uabi_engines (Mathias Krause) - Annotate struct ct_incoming_msg with __counted_by [guc] (Kees Cook) - More use of GT specific print helpers [gt] (John Harrison) Chris Wilson (2): drm/i915: Lift runtime-pm acquire callbacks out of intel_wakeref.mutex drm/i915: Invalidate the TLBs on each GT Daniele Ceraolo Spurio (1): drm/i915/guc: Enable WA 14018913170 John Harrison (4): drm/i915/guc: Suppress 'ignoring reset notification' message drm/i915/guc: Update 'recommended' version to 70.12.1 for DG2/ADL-S/ADL-P/MTL drm/i915/gt: More use of GT specific print helpers drm/i915: More use of GT specific print helpers Jonathan Cavitt (1): drm/i915/gem: Make i915_gem_shrinker multi-gt aware Kees Cook (1): drm/i915/guc: Annotate struct ct_incoming_msg with __counted_by Mathias Krause (2): drm/i915: Register engines early to avoid type confusion drm/i915: Clarify type evolution of uabi_node/uabi_engines Nirmoy Das (10): drm/i915: Introduce intel_gt_mcr_lock_sanitize() drm/i915: Introduce the intel_gt_resume_early() drm/i915: Clean steer semaphore on resume drm/i915/mtl: Skip MCR ops for ring fault register drm/i915: Create a kernel context for GGTT updates drm/i915: Implement for_each_sgt_daddr_next drm/i915: Parameterize binder context creation drm/i915: Implement GGTT update method with MI_UPDATE_GTT drm/i915: Toggle binder context ready status drm/i915: Enable GGTT updates with binder in MTL drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 42 ++-- drivers/gpu/drm/i915/gt/intel_engine.h| 2 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 69 +-- drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 +- drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 235 ++ drivers/gpu/drm/i915/gt/intel_gsc.c | 11 +- drivers/gpu/drm/i915/gt/intel_gt.c| 62 +- drivers/gpu/drm/i915/gt/intel_gt.h| 3 + drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 22 ++ drivers/gpu
Re: [PATCH v7 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
Il 12/10/23 10:40, Moudy Ho ha scritto: To simplify maintenance and avoid branches, the identical component should be merged and placed in the path belonging to the MDP (from display/* to media/*). In addition, currently only MDP utilizes RDMA through CMDQ, and the necessary properties for "mediatek,gce-events", and "mboxes" have been set up for this purpose. Within DISP, it directly receives component interrupt signals. Signed-off-by: Moudy Ho I agree in that this belongs to bindings/media and not bindings/display, as the display-specific RDMA component is display/mediatek/mediatek,rdma.yaml. The merge looks good to me, so... Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH drm-misc-next 2/3] drm/gpuva_mgr: generalize dma_resv/extobj handling and GEM validation
On Wed, 11 Oct 2023 at 17:07, Christian König wrote: > > Am 10.10.23 um 22:23 schrieb Dave Airlie: > >> I think we're then optimizing for different scenarios. Our compute > >> driver will use mostly external objects only, and if shared, I don't > >> forsee them bound to many VMs. What saves us currently here is that in > >> compute mode we only really traverse the extobj list after a preempt > >> fence wait, or when a vm is using a new context for the first time. So > >> vm's extobj list is pretty large. Each bo's vma list will typically be > >> pretty small. > > Can I ask why we are optimising for this userspace, this seems > > incredibly broken. > > > > We've has this sort of problem in the past with Intel letting the tail > > wag the horse, does anyone remember optimising relocations for a > > userspace that didn't actually need to use relocations? > > > > We need to ask why this userspace is doing this, can we get some > > pointers to it? compute driver should have no reason to use mostly > > external objects, the OpenCL and level0 APIs should be good enough to > > figure this out. > > Well that is pretty normal use case, AMD works the same way. > > In a multi GPU compute stack you have mostly all the data shared between > different hardware devices. > > As I said before looking at just the Vulcan use case is not a good idea > at all. > It's okay, I don't think anyone is doing that, some of the these use-cases are buried in server land and you guys don't communicate them very well. multi-gpu compute would I'd hope be moving towards HMM/SVM type solutions though? I'm also not into looking at use-cases that used to be important but might not as important going forward. Dave. > Christian. > > > > > Dave. >
Re: [PATCH v7 01/16] dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
Il 12/10/23 10:40, Moudy Ho ha scritto:
The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.
Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek MDP3
components")
Signed-off-by: Moudy Ho
Acked-by: Rob Herring
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v1] dynamic_debug: add support for logs destination
On Thu, 12 Oct 2023 11:53:52 +0200 Daniel Vetter wrote: > On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote: > > On Wed, 11 Oct 2023 11:42:24 +0200 > > Daniel Vetter wrote: > > > > > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote: ... > > > > - all selections tailored separately for each userspace subscriber > > > > (- per open device file description selection of messages) > > > > > > Again this feels like a userspace problem. Sessions could register what > > > kind of info they need for their session, and something like journald can > > > figure out how to record it all. > > > > Only if the kernel actually attaches all the required information to > > the debug messages *in machine readable form* so that userspace > > actually can do the filtering. And that makes *that* information UABI. > > Maybe that's fine? I wouldn't know. > > Well if you configure the filters to go into separate ringbuffers for each > session (or whatever you want to split) it also becomes uapi. It's a different UAPI: filter configuration vs. message structure. I don't mind which it is, I just suspect one is easier to maintain and extend than the other. > Also I'd say that for the first cut just getting the logs out on demand > should be good enough, multi-gpu (or multi-compositor) systems are a step > further. We can figure those out when we get there. This reminds me of what you recently said in IRC about a very different topic: swick[m], tell this past me roughly 10 years ago, would have been easy to add into the design back when there was no driver code yet I just want to mention today everything I can see as useful. It's up to the people doing the actual work to decide what they include and how. Thanks, pq pgpGben6913p0.pgp Description: OpenPGP digital signature
Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On Thu, 2023-10-12 at 09:07 +0200, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 12/10/2023 08:54, Yong Wu (吴勇) wrote: > > > > Thanks Jeffrey for the addition. > > > > Hi Rob, krzysztof, > > > > Just a ping. Is Jeffrey's reply ok for you? > > I did not see any patch posted and I am way behind reviewing patches > to > review also non-patches-patches... Sorry, I haven't sent a new version yet. I plan to prepare the new version after having a conclusion here. In Jeffrey's help reply, this memory range is defined in TEE firmware, thus this looks could be ok for a binding, right? Thanks. > > Best regards, > Krzysztof >
Re: [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)
Hi, On 10/11/23 15:05, Jani Nikula wrote: > On Sun, 08 Oct 2023, Hans de Goede wrote: >> Hi All, >> >> Ping what is the status of this now? This v3 addresses all review >> remarks from previous versions (specifically the request to file >> + link gitlab issues). >> >> So AFAICT this is ready for merging ? >> >> But I'm waiting for an ack for this before pushing it >> do drm-intel-next myself ... > > There are maybe one or two things I could nitpick about, such as casting > away the const in there, but then I just don't have the time to look > into this much deeper, it's all fairly isolated, and, let's be honest, > you of all people probably have the best idea how well the vlv dsi code > works out in the real world. > > Thanks for fixing all this stuff, and please just merge. > > Acked-by: Jani Nikula Thank you, I've pushed this to drm-intel-next now. Regards, Hans
[PULL] drm-misc-fixes
Hi Dave and Daniel, here's the PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2023-10-12: Short summary of fixes pull: * atomic-helper: Relax checks for unregistered connectors * dma-buf: Work around race condition when retrieving fence timestamp * gem: Avoid OOB access in BO memory range * panel: * boe-tv101wun-ml6: Fix flickering * simpledrm: Fix error output * vwmgfx: * Fix size calculation in texture-state code * Ref GEM BOs in surfaces The following changes since commit d59e75eef52d89201aaf5342a3ac23ddf3e9b112: drm/nouveau: exec: report max pushs through getparam (2023-10-04 00:10:18 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-10-12 for you to fetch changes up to c1165df2be2fffe3adeeaa68f4ee4325108c5e4e: drm/tiny: correctly print `struct resource *` on error (2023-10-12 10:57:07 +0200) Short summary of fixes pull: * atomic-helper: Relax checks for unregistered connectors * dma-buf: Work around race condition when retrieving fence timestamp * gem: Avoid OOB access in BO memory range * panel: * boe-tv101wun-ml6: Fix flickering * simpledrm: Fix error output * vwmgfx: * Fix size calculation in texture-state code * Ref GEM BOs in surfaces Christian König (1): dma-buf: add dma_fence_timestamp helper Joey Gouly (1): drm/tiny: correctly print `struct resource *` on error Konstantin Meskhidze (1): drm/vmwgfx: fix typo of sizeof argument Matthew Wilcox (Oracle) (1): drm: Do not overrun array in drm_gem_get_pages() Ruihai Zhou (1): drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP term Simon Ser (1): drm/atomic-helper: relax unregistered connector check Zack Rusin (1): drm/vmwgfx: Keep a gem reference to user bos in surfaces drivers/dma-buf/dma-fence-unwrap.c | 13 --- drivers/dma-buf/sync_file.c| 9 +++- drivers/gpu/drm/drm_atomic_helper.c| 17 ++ drivers/gpu/drm/drm_gem.c | 6 +++-- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 4 +--- drivers/gpu/drm/scheduler/sched_main.c | 2 +- drivers/gpu/drm/tiny/simpledrm.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 7 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 17 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 6 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_gem.c| 18 --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 6 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 31 ++ include/linux/dma-fence.h | 19 19 files changed, 115 insertions(+), 76 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Re: [PATCH] drm/tidss: Power up attached PM domains on probe
On 09/10/23 13:20, Devarsh Thakkar wrote:
Some SoC's such as AM62P have dedicated power domains
for OLDI which need to be powered on separetely along
with display controller.
So during driver probe, power up all attached PM domains
enumerated in devicetree node for DSS.
This also prepares base to add display support for AM62P.
NAK, for this patch, as discussed with team there are already plans
to have separate OLDI bridge driver which should eventually handle
the additional power domains.
Sorry for the noise.
Regards
Devarsh
Signed-off-by: Devarsh Thakkar > ---
drivers/gpu/drm/tidss/tidss_drv.c | 76 +++
drivers/gpu/drm/tidss/tidss_drv.h | 5 ++
2 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index 4d063eb9cd0b..a703a27d17bf 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -114,6 +115,72 @@ static const struct drm_driver tidss_driver = {
.minor = 0,
};
+static int tidss_detach_pm_domains(struct tidss_device *tidss)
+{
+ int i;
+
+ if (tidss->num_domains <= 1)
+ return 0;
+
+ for (i = 0; i < tidss->num_domains; i++) {
+ if (tidss->pd_link[i] && !IS_ERR(tidss->pd_link[i]))
+ device_link_del(tidss->pd_link[i]);
+ if (tidss->pd_dev[i] && !IS_ERR(tidss->pd_dev[i]))
+ dev_pm_domain_detach(tidss->pd_dev[i], true);
+ tidss->pd_dev[i] = NULL;
+ tidss->pd_link[i] = NULL;
+ }
+
+ return 0;
+}
+
+static int tidss_attach_pm_domains(struct tidss_device *tidss)
+{
+ struct device *dev = tidss->dev;
+ int i;
+ int ret;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct device_node *np = pdev->dev.of_node;
+
+ tidss->num_domains = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+ if (tidss->num_domains <= 1) {
+ dev_dbg(dev, "One or less power domains, no need to do attach
domains\n");
+ return 0;
+ }
+
+ tidss->pd_dev = devm_kmalloc_array(dev, tidss->num_domains,
+ sizeof(*tidss->pd_dev), GFP_KERNEL);
+ if (!tidss->pd_dev)
+ return -ENOMEM;
+
+ tidss->pd_link = devm_kmalloc_array(dev, tidss->num_domains,
+ sizeof(*tidss->pd_link),
GFP_KERNEL);
+ if (!tidss->pd_link)
+ return -ENOMEM;
+
+ for (i = 0; i < tidss->num_domains; i++) {
+ tidss->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
+ if (IS_ERR(tidss->pd_dev[i])) {
+ ret = PTR_ERR(tidss->pd_dev[i]);
+ goto fail;
+ }
+
+ tidss->pd_link[i] = device_link_add(dev, tidss->pd_dev[i],
+ DL_FLAG_STATELESS |
+ DL_FLAG_PM_RUNTIME |
DL_FLAG_RPM_ACTIVE);
+ if (!tidss->pd_link[i]) {
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ return 0;
+fail:
+ tidss_detach_pm_domains(tidss);
+ return ret;
+}
+
static int tidss_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -136,6 +203,13 @@ static int tidss_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, tidss);
+ /* powering up associated OLDI domains */
+ ret = tidss_attach_pm_domains(tidss);
+ if (ret < 0) {
+ dev_err(dev, "failed to attach power domains %d\n", ret);
+ return ret;
+ }
+
ret = dispc_init(tidss);
if (ret) {
dev_err(dev, "failed to initialize dispc: %d\n", ret);
@@ -193,6 +267,7 @@ static int tidss_probe(struct platform_device *pdev)
dispc_runtime_suspend(tidss->dispc);
#endif
pm_runtime_disable(dev);
+ tidss_detach_pm_domains(tidss);
return ret;
}
@@ -220,6 +295,7 @@ static void tidss_remove(struct platform_device *pdev)
/* devm allocated dispc goes away with the dev so mark it NULL */
dispc_remove(tidss);
+ tidss_detach_pm_domains(tidss);
dev_dbg(dev, "%s done\n", __func__);
}
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h b/drivers/gpu/drm/tidss/tidss_drv.h
index d7f27b0b0315..3c8b37b3aba6 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.h
+++ b/drivers/gpu/drm/tidss/tidss_drv.h
@@ -31,6 +31,11 @@ struct tidss_device {
spinlock_t wait_lock; /* protects the irq masks */
dispc_irq_t irq_mask; /* enabled irqs in addition to wait_list */
+
+ int num_domains; /* Handle attached PM domains */
+
Re: [PATCH v2 5/6] dt-bindings: display: Split common Solomon properties in their own schema
On Thu, Oct 12, 2023 at 08:58:14AM +0200, Javier Martinez Canillas wrote: > There are DT properties that can be shared across different Solomon OLED > Display Controller families. Split them into a separate common schema to > avoid these properties to be duplicated in different DT bindings schemas. > > Suggested-by: Rob Herring > Signed-off-by: Javier Martinez Canillas > --- > > (no changes since v1) > > .../bindings/display/solomon,ssd-common.yaml | 42 +++ > .../bindings/display/solomon,ssd1307fb.yaml | 28 + > MAINTAINERS | 1 + > 3 files changed, 44 insertions(+), 27 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd-common.yaml > > diff --git > a/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml > b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml > new file mode 100644 > index ..677fd2b90960 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml > @@ -0,0 +1,42 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/solomon,ssd-common.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common properties for Solomon OLED Display Controllers > + > +maintainers: > + - Javier Martinez Canillas > + > +properties: > + reg: > +maxItems: 1 > + > + reset-gpios: > +maxItems: 1 > + > + # Only required for SPI > + dc-gpios: > +description: > + GPIO connected to the controller's D/C# (Data/Command) pin, > + that is needed for 4-wire SPI to tell the controller if the > + data sent is for a command register or the display data RAM > +maxItems: 1 > + > + solomon,height: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Height in pixel of the screen driven by the controller. > + The default value is controller-dependent. > + > + solomon,width: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Width in pixel of the screen driven by the controller. > + The default value is controller-dependent. > + > +allOf: > + - $ref: /schemas/spi/spi-peripheral-props.yaml# > + > +additionalProperties: true > \ No newline at end of file With this fixed, Reviewed-by: Rob Herring
Re: [PATCH v2 6/6] dt-bindings: display: Add SSD132x OLED controllers
On Thu, Oct 12, 2023 at 08:58:15AM +0200, Javier Martinez Canillas wrote: > Add a Device Tree binding schema for the OLED panels based on the Solomon > SSD132x family of controllers. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v2: > - Remove unnecessary 'oneOf' in the SSD132x DT binding schema (Conor Dooley). > - Remove unused DT nodes labels in the binding schema examples (Conor Dooley). > - Split out common Solomon properties into a separate schema (Rob Herring). > > .../bindings/display/solomon,ssd132x.yaml | 89 +++ > MAINTAINERS | 2 +- > 2 files changed, 90 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd132x.yaml Reviewed-by: Rob Herring
Re: [PATCH 2/2] fbdev/simplefb: Add support for generic power-domains
Hi Thierry,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip linus/master v6.6-rc5 next-20231012]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thierry-Reding/fbdev-simplefb-Support-memory-region-property/20231011-223908
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231011143809.1108034-3-thierry.reding%40gmail.com
patch subject: [PATCH 2/2] fbdev/simplefb: Add support for generic power-domains
config: sparc64-randconfig-001-20231012
(https://download.01.org/0day-ci/archive/20231012/202310121911.nusbphr5-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231012/202310121911.nusbphr5-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202310121911.nusbphr5-...@intel.com/
All errors (new ones prefixed by >>):
drivers/video/fbdev/simplefb.c: In function 'simplefb_probe':
>> drivers/video/fbdev/simplefb.c:637:9: error: implicit declaration of
>> function 'simplefb_detach_genpds'; did you mean 'simplefb_attach_genpd'?
>> [-Werror=implicit-function-declaration]
637 | simplefb_detach_genpds(par);
| ^~
| simplefb_attach_genpd
cc1: some warnings being treated as errors
vim +637 drivers/video/fbdev/simplefb.c
517
518 static int simplefb_probe(struct platform_device *pdev)
519 {
520 int ret;
521 struct simplefb_params params;
522 struct fb_info *info;
523 struct simplefb_par *par;
524 struct resource *res, *mem;
525
526 if (fb_get_options("simplefb", NULL))
527 return -ENODEV;
528
529 ret = -ENODEV;
530 if (dev_get_platdata(&pdev->dev))
531 ret = simplefb_parse_pd(pdev, ¶ms);
532 else if (pdev->dev.of_node)
533 ret = simplefb_parse_dt(pdev, ¶ms);
534
535 if (ret)
536 return ret;
537
538 if (params.memory.start == 0 && params.memory.end == 0) {
539 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
540 if (!res) {
541 dev_err(&pdev->dev, "No memory resource\n");
542 return -EINVAL;
543 }
544 } else {
545 res = ¶ms.memory;
546 }
547
548 mem = request_mem_region(res->start, resource_size(res),
"simplefb");
549 if (!mem) {
550 /*
551 * We cannot make this fatal. Sometimes this comes from
magic
552 * spaces our resource handlers simply don't know
about. Use
553 * the I/O-memory resource as-is and try to map that
instead.
554 */
555 dev_warn(&pdev->dev, "simplefb: cannot reserve video
memory at %pR\n", res);
556 mem = res;
557 }
558
559 info = framebuffer_alloc(sizeof(struct simplefb_par),
&pdev->dev);
560 if (!info) {
561 ret = -ENOMEM;
562 goto error_release_mem_region;
563 }
564 platform_set_drvdata(pdev, info);
565
566 par = info->par;
567
568 info->fix = simplefb_fix;
569 info->fix.smem_start = mem->start;
570 info->fix.smem_len = resource_size(mem);
571 info->fix.line_length = params.stride;
572
573 info->var = simplefb_var;
574 info->var.xres = params.width;
575 info->var.yres = params.height;
576 info->var.xres_virtual = params.width;
577 info->var.yres_virtual = params.height;
578 info->var.bits_per_pixel = params.format->bits_per_pixel;
579 info->var.red = params.format->red;
580 info->var.green = params.format->green;
581 info->var.blue = params.format->blue;
582 info->var.transp = params.format->transp;
583
584 par->base = info->fix.smem_start;
585 par->size = info-&
Re: [v1 2/2] drm/panel: ili9882t: Avoid blurred screen from fast sleep
Hi, On Wed, Oct 11, 2023 at 3:11 AM Doug Anderson wrote: > > Hi, > > On Tue, Oct 10, 2023 at 4:36 AM cong yang > wrote: > > > > Hi, > > > > On Tue, Oct 10, 2023 at 4:44 AM Doug Anderson wrote: > > > > > > Hi, > > > > > > On Fri, Oct 6, 2023 at 11:07 PM Cong Yang > > > wrote: > > > > > > > > At present, we have found that there may be a problem of blurred > > > > screen during fast sleep/resume. The direct cause of the blurred > > > > screen is that the IC does not receive 0x28/0x10. Because of the > > > > particularity of the IC, before the panel enters sleep hid must > > > > stop scanning, i2c_hid_core_suspend before ili9882t_disable. > > > > This doesn't look very spec-compliant. > > > > > > Presumably you could be more spec compliant if we used > > > "panel_follower" in this case? Would that be a better solution? > > > > In the "panel_follower" solution, the phenomenon is the same. > > The current order is > > ili9882t_disable=>i2c_hid_core_suspend=>elan_i2c_hid_power_down=>ili9882t_unprepare, > > ili9882t need touchpanel stop scanning,i2c_hid_core_suspend before > > ili9882t_disable. > > Ugh, that's unfortunate. Though is there a reason why you couldn't > just move the `ili9882t_enter_sleep_mode()` to `ili9882t_unprepare()`? > That seems like it should be OK and even perhaps makes it more > symmetric with thue enable? It looks like the test will still fail, because the touchpanel reset was already pulled low before the panel enter sleep, which did not seem to meet the timing requirements. I will explain this in the V3 cover letter. Thanks. > > > > > > @@ -507,7 +526,7 @@ static int ili9882t_prepare(struct drm_panel *panel) > > > > gpiod_set_value(ili->enable_gpio, 1); > > > > usleep_range(1000, 2000); > > > > gpiod_set_value(ili->enable_gpio, 0); > > > > - usleep_range(1000, 2000); > > > > + usleep_range(4, 5); > > > > > > nit: use 4, 41000 instead of 4, 5. Linux almost always > > > uses the longer delay, so that'll save ~9 ms. The only reason for the > > > range is to optimize kernel wakeups which is really not a concern > > > here. > > > > We need 50ms delay to meet the requirement. > > I'll respond to your v2, but if you need 50 ms then your current delay is > wrong. > > > -Doug
[v3 0/3] Break out as separate driver from boe-tv101wum-nl6 panel driver
Linus series proposed to break out ili9882t as separate driver, but he didn't have time for that extensive rework of the driver. As discussed by Linus and Doug [1], keep macro using the "struct panel_init_cmd" until we get some resolution about the binary size issue. [1]: https://lore.kernel.org/all/20230703-fix-boe-tv101wum-nl6-v3-0-bd6e9432c...@linaro.org In [v1 2/2], Doug suggested move the ili9882t_enter_sleep_mode function to ili9882t_unprepare. I tried this scheme and the test failed, because the touchpanel reset was already pulled low before the panel enter sleep, which did not seem to meet the timing requirements. I hoped that the current adding delay solution can be apply to solve the special requirements of this IC. [v1 2/2] https://lore.kernel.org/all/CAD=FV=XtqPJ77dx8uRb0=tmvc3cvgh5x+7mujexgcg228kz...@mail.gmail.com/ Changes in v3: - PATCH 1/3: Remove "init_cmd_length" and "linux/of_device.h" . - PATCH 2/3: Change usleep_range(5,51000). - PATCH 3/3: Add a little background for commit. - Link to v2: https://lore.kernel.org/all/20231010121402.3687948-1-yangco...@huaqin.corp-partner.google.com/ Changes in v2: - PATCH 1/3: fix Doug comments,define "_INIT_SWITCH_PAGE_CMD" and remove the "shutdown". - PATCH 2/3: Modify ili9882t_switch_page function instead of hardcoding. - PATCH 3/3: Enable new config in defconfig. - Link to v1: https://lore.kernel.org/all/20231007060639.725350-1-yangco...@huaqin.corp-partner.google.com/ Cong Yang (3): drm/panel: ili9882t: Break out as separate driver drm/panel: ili9882t: Avoid blurred screen from fast sleep arm64: defconfig: Enable ILITEK_ILI9882T panel arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 - drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 779 ++ 5 files changed, 790 insertions(+), 371 deletions(-) create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c -- 2.25.1
[v3 1/3] drm/panel: ili9882t: Break out as separate driver
The Starry ILI9882t-based panel should never have been part of the boe
tv101wum driver, it is clearly based on the Ilitek ILI9882t display
controller and if you look at the custom command sequences for the
panel these clearly contain the signature Ilitek page switch (0xff)
commands. The hardware has nothing in common with the other panels
supported by this driver.
Break this out into a separate driver and config symbol instead.
If the placement here is out of convenience for using similar code,
we should consider creating a helper library instead.
Co-developed-by: Linus Walleij
Signed-off-by: Linus Walleij
Reviewed-by: Linus Walleij
Reviewed-by: Douglas Anderson
Signed-off-by: Cong Yang
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 -
drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 759 ++
4 files changed, 769 insertions(+), 371 deletions(-)
create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ecb22ea326cb..99e14dc212ec 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -203,6 +203,15 @@ config DRM_PANEL_ILITEK_ILI9881C
Say Y if you want to enable support for panels based on the
Ilitek ILI9881c controller.
+config DRM_PANEL_ILITEK_ILI9882T
+ tristate "Ilitek ILI9882t-based panels"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9882t controller.
+
config DRM_PANEL_INNOLUX_EJ030NA
tristate "Innolux EJ030NA 320x480 LCD panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e14ce55a0875..d10c3de51c6d 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JADARD_JD9365DA_H3) += panel-jadard-jd9365da-h3.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 5ac926281d2c..4f370bc6dca8 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1370,346 +1370,6 @@ static const struct panel_init_cmd
starry_himax83102_j02_init_cmd[] = {
{},
};
-static const struct panel_init_cmd starry_ili9882t_init_cmd[] = {
- _INIT_DELAY_CMD(5),
- _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x01),
- _INIT_DCS_CMD(0x00, 0x42),
- _INIT_DCS_CMD(0x01, 0x11),
- _INIT_DCS_CMD(0x02, 0x00),
- _INIT_DCS_CMD(0x03, 0x00),
-
- _INIT_DCS_CMD(0x04, 0x01),
- _INIT_DCS_CMD(0x05, 0x11),
- _INIT_DCS_CMD(0x06, 0x00),
- _INIT_DCS_CMD(0x07, 0x00),
-
- _INIT_DCS_CMD(0x08, 0x80),
- _INIT_DCS_CMD(0x09, 0x81),
- _INIT_DCS_CMD(0x0A, 0x71),
- _INIT_DCS_CMD(0x0B, 0x00),
-
- _INIT_DCS_CMD(0x0C, 0x00),
- _INIT_DCS_CMD(0x0E, 0x1A),
-
- _INIT_DCS_CMD(0x24, 0x00),
- _INIT_DCS_CMD(0x25, 0x00),
- _INIT_DCS_CMD(0x26, 0x00),
- _INIT_DCS_CMD(0x27, 0x00),
-
- _INIT_DCS_CMD(0x2C, 0xD4),
- _INIT_DCS_CMD(0xB9, 0x40),
-
- _INIT_DCS_CMD(0xB0, 0x11),
-
- _INIT_DCS_CMD(0xE6, 0x32),
- _INIT_DCS_CMD(0xD1, 0x30),
-
- _INIT_DCS_CMD(0xD6, 0x55),
-
- _INIT_DCS_CMD(0xD0, 0x01),
- _INIT_DCS_CMD(0xE3, 0x93),
- _INIT_DCS_CMD(0xE4, 0x00),
- _INIT_DCS_CMD(0xE5, 0x80),
-
- _INIT_DCS_CMD(0x31, 0x07),
- _INIT_DCS_CMD(0x32, 0x07),
- _INIT_DCS_CMD(0x33, 0x07),
- _INIT_DCS_CMD(0x34, 0x07),
- _INIT_DCS_CMD(0x35, 0x07),
- _INIT_DCS_CMD(0x36, 0x01),
- _INIT_DCS_CMD(0x37, 0x00),
- _INIT_DCS_CMD(0x38, 0x28),
- _INIT_DCS_CMD(0x39, 0x29),
- _INIT_DCS_CMD(0x3A, 0x11),
- _INIT_DCS_CMD(0x3B, 0x13),
- _INIT_DCS_CMD(0x3C, 0x15),
- _INIT_DCS_CMD(0x3D, 0x17),
- _INIT_DCS_CMD(0x3E, 0x09),
- _INIT_DCS_CMD(0x3F, 0x0D),
- _INIT_DCS_CMD(0x40, 0x02),
- _INIT_DCS_CMD(0x41, 0x02),
- _INIT_DCS_CMD(0x42, 0x02),
- _INIT_DCS_CMD(0x43, 0x02),
- _INIT_DCS_CMD(0x44, 0x02),
- _INIT_DCS_CMD(0x45, 0x02),
- _INIT_DCS_CMD(0x46, 0x02),
-
- _INIT_DCS_CMD(0x47, 0x07),
- _INIT_DCS_CMD(0x48, 0x07),
- _INIT_DCS_CMD(0x49, 0x07),
- _INIT_DCS_
[v3 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep
At present, we have found that there may be a problem of blurred
screen during fast sleep/resume. The direct cause of the blurred
screen is that the IC does not receive 0x28/0x10. Because of the
particularity of the IC, before the panel enters sleep hid must
stop scanning, as i2c_hid_core_suspend before ili9882t_disable.
If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare,
touch reset will pull low before panel entersleep, which does not meet
the timing requirements.. So in order to solve this problem, the IC
can handle it through the exception mechanism when it cannot receive
0x28/0x10 command. Handling exceptions requires a reset 50ms delay.
Refer to vendor detailed analysis [1].
Ilitek vendor also suggested switching the page before entering sleep to
avoid panel IC not receiving 0x28/0x10 command.
Note: 0x28 is display off, 0x10 is sleep in.
[1]: https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence
Signed-off-by: Cong Yang
---
drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
index 93a40c2f1483..54ff1efb94aa 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
@@ -463,6 +463,24 @@ static int ili9882t_init_dcs_cmd(struct ili9882t *ili)
return 0;
}
+static int ili9882t_switch_page(struct mipi_dsi_device *dsi, u8 page)
+{
+ int ret;
+ const struct panel_init_cmd cmd = _INIT_SWITCH_PAGE_CMD(page);
+
+ ret = mipi_dsi_dcs_write(dsi, cmd.data[0],
+cmd.len <= 1 ? NULL :
+&cmd.data[1],
+cmd.len - 1);
+ if (ret) {
+ dev_err(&dsi->dev,
+ "error switching panel controller page (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
{
struct mipi_dsi_device *dsi = ili->dsi;
@@ -484,8 +502,10 @@ static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
static int ili9882t_disable(struct drm_panel *panel)
{
struct ili9882t *ili = to_ili9882t(panel);
+ struct mipi_dsi_device *dsi = ili->dsi;
int ret;
+ ili9882t_switch_page(dsi, 0x00);
ret = ili9882t_enter_sleep_mode(ili);
if (ret < 0) {
dev_err(panel->dev, "failed to set panel off: %d\n", ret);
@@ -546,7 +566,7 @@ static int ili9882t_prepare(struct drm_panel *panel)
gpiod_set_value(ili->enable_gpio, 1);
usleep_range(1000, 2000);
gpiod_set_value(ili->enable_gpio, 0);
- usleep_range(1000, 2000);
+ usleep_range(5, 51000);
gpiod_set_value(ili->enable_gpio, 1);
usleep_range(6000, 1);
--
2.25.1
[v3 3/3] arm64: defconfig: Enable ILITEK_ILI9882T panel
DRM_PANEL_ILITEK_ILI9882T is being split out from DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE panel driver enabled, let's also enable the Ilitek driver. Reviewed-by: Douglas Anderson Signed-off-by: Cong Yang --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0777bcae9104..c3453dcbad3e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -813,6 +813,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m CONFIG_DRM_PANEL_LVDS=m CONFIG_DRM_PANEL_SIMPLE=m CONFIG_DRM_PANEL_EDP=m +CONFIG_DRM_PANEL_ILITEK_ILI9882T=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m CONFIG_DRM_PANEL_SITRONIX_ST7703=m -- 2.25.1
Re: [PATCH drm-misc-next 2/3] drm/gpuva_mgr: generalize dma_resv/extobj handling and GEM validation
Am 12.10.23 um 12:33 schrieb Dave Airlie: On Wed, 11 Oct 2023 at 17:07, Christian König wrote: Am 10.10.23 um 22:23 schrieb Dave Airlie: I think we're then optimizing for different scenarios. Our compute driver will use mostly external objects only, and if shared, I don't forsee them bound to many VMs. What saves us currently here is that in compute mode we only really traverse the extobj list after a preempt fence wait, or when a vm is using a new context for the first time. So vm's extobj list is pretty large. Each bo's vma list will typically be pretty small. Can I ask why we are optimising for this userspace, this seems incredibly broken. We've has this sort of problem in the past with Intel letting the tail wag the horse, does anyone remember optimising relocations for a userspace that didn't actually need to use relocations? We need to ask why this userspace is doing this, can we get some pointers to it? compute driver should have no reason to use mostly external objects, the OpenCL and level0 APIs should be good enough to figure this out. Well that is pretty normal use case, AMD works the same way. In a multi GPU compute stack you have mostly all the data shared between different hardware devices. As I said before looking at just the Vulcan use case is not a good idea at all. It's okay, I don't think anyone is doing that, some of the these use-cases are buried in server land and you guys don't communicate them very well. Yeah, well everybody is trying very hard to get away from those approaches :) But so far there hasn't been any breakthrough. multi-gpu compute would I'd hope be moving towards HMM/SVM type solutions though? Unfortunately not in the foreseeable future. HMM seems more and more like a dead end, at least for AMD. AMD still has hardware support in all of their MI* products, but for Navi the features necessary for implementing HMM have been dropped. And it looks more and more like their are not going to come back. Additional to that from the software side Felix summarized it in the HMM peer2peer discussion thread recently quite well. A buffer object based approach is not only simpler to handle, but also performant vise multiple magnitudes faster. I'm also not into looking at use-cases that used to be important but might not as important going forward. Well multimedia applications and OpenGL are still around, but it's not the main focus any more. Christian. Dave. Christian. Dave.
