Re: [PATCH 1/4] fbdev: imsttfb: Fix error handling in init_imstt()

[Markus Elfring]

>> The return value was overlooked from a call of
>> the function “fb_alloc_cmap”.
>>
>> * Thus use a corresponding error check.
>>
>> * Add two jump targets so that a bit of exception handling
>>    can be better reused at the end of this function.
…
>> +++ b/drivers/video/fbdev/imsttfb.c
…
>> @@ -1452,17 +1452,25 @@ static int init_imstt(struct fb_info *info)
>>     FBINFO_HWACCEL_FILLRECT |
>>     FBINFO_HWACCEL_YPAN;
>>
>> -    fb_alloc_cmap(>cmap, 0, 0);
>> +    ret = fb_alloc_cmap(>cmap, 0, 0);
>> +    if (ret)
>> +    goto release_framebuffer;
>>
>>   if (register_framebuffer(info) < 0) {
>> -    framebuffer_release(info);
>> -    return -ENODEV;
>> +    fb_dealloc_cmap(>cmap);
>> +    goto e_nodev;
>>   }
>>
>>   tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8;
>>   fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n",
>>   info->fix.id, info->fix.smem_len >> 20, tmp);
>>   return 0;
>> +
>> +e_nodev:
>> +    ret = -ENODEV;
>
> I think the return value isn't checked at all, so you could
> simply return below "-ENODEV" for all cases (instead of "return ret").
> Then you don't need the e_nodev label and can simplify the flow.

Can it be helpful to distinguish involved error codes better?

How should return value ignorance be avoided further?

Regards,
Markus

Re: [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary

[Teres Alexis, Alan Previn]

On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:


alan: snip


> +int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, const void 
> *data, size_t size)
> +{
alan:snip
> + /*
> +  * The GSC binary starts with the pointer layout, which contains the
> +  * locations of the various partitions of the binary. The one we're
> +  * interested in to get the version is the boot1 partition, where we can
> +  * find a BPDT header followed by entries, one of which points to the
> +  * RBE sub-section of the partition. From here, we can parse the CPD
alan: nit: could we add the meaning of 'RBE', probably not here but in the 
header file where GSC_RBE is defined?
> +  * header and the following entries to find the manifest location
> +  * (entry identified by the "RBEP.man" name), from which we can finally
> +  * extract the version.
> +  *
> +  * --
> +  * [  intel_gsc_layout_pointers ]
> +  * [  ...   ]
> +  * [  boot1_offset  >---]--o
> +  * [  ...   ]  |
> +  * --  |
> +  * |
> +  * --  |
> +  * [  intel_gsc_bpdt_header ]<-o
> +  * --
alan: special thanks for the diagram - love these! :)
alan: snip

> + min_size = layout->boot1_offset + layout->boot1_offset > size;
alan: latter is a binary so + 1? or is this a typo and supposed to be:
min_size = layout->boot1_offset;
actually since we are accessing a bpdt_header hanging off that offset, it 
should rather be:
min_size = layout->boot1_offset + sizeof(*bpdt_header);
> + if (size < min_size) {
> + gt_err(gt, "GSC FW too small for boot section! %zu < %zu\n",
> +size, min_size);
> + return -ENODATA;
> + }
> +
> + bpdt_header = data + layout->boot1_offset;
> + if (bpdt_header->signature != INTEL_GSC_BPDT_HEADER_SIGNATURE) {
> + gt_err(gt, "invalid signature for meu BPDT header: 0x%08x!\n",
> +bpdt_header->signature);
> + return -EINVAL;
> + }
> +
alan: IIUC, to be strict about the size-crawl-checking, we should check minsize
again - this time with the additional "bpdt_header->descriptor_count * 
sizeof(*bpdt_entry)".
(hope i got that right?) - adding that check before parsing through the 
(bpdt_entry++)'s ->type
> + bpdt_entry = (void *)bpdt_header + sizeof(*bpdt_header);
> + for (i = 0; i < bpdt_header->descriptor_count; i++, bpdt_entry++) {
> + if ((bpdt_entry->type & INTEL_GSC_BPDT_ENTRY_TYPE_MASK) !=
> + INTEL_GSC_BPDT_ENTRY_TYPE_GSC_RBE)
> + continue;
> +
> + cpd_header = (void *)bpdt_header + 
> bpdt_entry->sub_partition_offset;
> + break;
> + }
> +
> + if (!cpd_header) {
> + gt_err(gt, "couldn't find CPD header in GSC binary!\n");
> + return -ENODATA;
> + }
alan: same as above, so for size-crawl-checking, we should check minsize again 
with the addition of cpd_header, no?
> +
> + if (cpd_header->header_marker != INTEL_GSC_CPD_HEADER_MARKER) {
> + gt_err(gt, "invalid marker for meu CPD header in GSC bin: 
> 0x%08x!\n",
> +cpd_header->header_marker);
> + return -EINVAL;
> + }
alan: and again here, the size crawl checking with cpd_header->num_of_entries * 
*cpd_entry
> + cpd_entry = (void *)cpd_header + cpd_header->header_length;
> + for (i = 0; i < cpd_header->num_of_entries; i++, cpd_entry++) {
> + if (strcmp(cpd_entry->name, "RBEP.man") == 0) {
> + manifest = (void *)cpd_header + 
> cpd_entry_offset(cpd_entry);
> + intel_uc_fw_version_from_meu_manifest(>release,
> +   manifest);
> + gsc->security_version = manifest->security_version;
> + break;
> + }
> + }
> +
> + return 0;

alan:snip

>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
> index fff8928218df..8d7b9e4f1ffc 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
alan:snip


> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
> index d55a66202576..8bce2b8aed84 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
alan:snip



> +struct intel_gsc_layout_pointers {
> + u8 

Re: [PATCH 3/4] fbdev: imsttfb: Move a variable assignment for an error code in imsttfb_probe()

[Markus Elfring]

>> The value “-ENOMEM” was assigned to the variable “ret”
>> at the beginning.
>> Move this statement directly before the first ioremap() call.
>
> Please do not move such variables without real need.

Is there a need to explain desirable effects better?


> It makes backporting (of this and maybe follow-up patches) much more 
> complicated

I propose to reconsider such development concerns a bit more.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/imsttfb.c?h=v6.4-rc3


> and the compiler will optimize it anyway.

How much do expectations fit to supported and documented software optimisations?

Regards,
Markus

Re: [PATCH 1/2] fbdev: Move two variable assignments in fb_alloc_cmap_gfp()

[Markus Elfring]

>> Move the assignment for the local variables “size” and “flags”
>> because the computed values were only used in a single if branch.
>
> Please do not move such variables without real need.

Is there a need to explain desirable effects better?


> It makes backporting (of this and maybe follow-up patches) much more 
> complicated

I suggest to reconsider such development concerns a bit more.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/core/fbcmap.c?h=v6.4-rc3


> and the compiler will optimize it anyway.

How much do expectations fit to supported and documented software optimisations?

Regards,
Markus

Re: [PATCH] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c

[Bjorn Andersson]

On Thu, 4 May 2023 19:04:30 +0300, Dmitry Baryshkov wrote:
> Now as both lt9611 and drm/msm drivers were updated to handle the 4k
> modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
> utilizes both DSI links and thus can support 4k on the HDMI output.
> 
> 

Applied, thanks!

[1/1] arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
  commit: 8721e18ca6960f3c5a6a7f58245d9ab084ad09dd

Best regards,
-- 
Bjorn Andersson 

Re: [PATCH v14 1/2] drm: add kms driver for loongson display controller

[Sui Jingfeng]

On 2023/5/25 12:09, Sui Jingfeng wrote:

Hi,

On 2023/5/23 00:40, WANG Xuerui wrote:

On 5/22/23 21:13, Sui Jingfeng wrote:

Hi,

On 2023/5/22 18:25, WANG Xuerui wrote:

On 2023/5/22 18:17, Sui Jingfeng wrote:

Hi,

On 2023/5/22 18:05, WANG Xuerui wrote:

On 2023/5/22 17:49, Sui Jingfeng wrote:

Hi,

On 2023/5/22 17:28, WANG Xuerui wrote:

On 2023/5/22 17:25, Sui Jingfeng wrote:

Hi,

On 2023/5/21 20:21, WANG Xuerui wrote:
+ * LS3A4000/LS3A5000/LS3A6000 CPU, they are equipped with 
on-board video RAM
+ * typically. While LS2K0500/LS2K1000/LS2K2000 are low cost 
SoCs which share
+ * the system RAM as video RAM, they don't has a dediacated 
VRAM.


CPU models are not typically prefixed with "LS", so "Loongson 
3A4000/3A5000/3A6000".


Here is because when you do programming, variable name should 
prefix with letters.


Commit messages, comments, and log messages etc. are natural 
language, so it's better to treat them differently. No problem 
to keep code as-is IMO.


Then you get two name for a single chip,  take LS7A1000 as an 
example.


You name it as Loongson 7A1000 in commit message,  and then you 
have to define another name in the code,  say LS7A1000.


"Loongson 7A1000" is too long,  not as compact as LS7A1000.

This also avoid bind the company name to a specific product, 
because a company can produce many product.


Nah, the existing convention is "LS7X" for bridges and 
"Loongson 3A" for CPUs (SoCs like 2K fall under this category 
too). It's better to stick with existing practice so it would be 
familiar to long-time Loongson/LoongArch developers, but I 
personally don't think it will hamper understanding if you feel 
like doing otherwise.



Can you explain why it is better?

is it that the already existing is better ?


It's not about subjective perception of "better" or "worse", but 
about tree-wide consistency, and about reducing any potential 
confusion from newcomers. I remember Huacai once pointing out that 
outsiders usually have a hard time remembering "1, 2, and 3 are 
CPUs, some 2 are SoCs, 7 are bridge chips", and consistently 
referring to the bridge chips throughout the tree as "LS7A" helped.


In any case, for the sake of consistency, you can definitely refer 
to the CPU models in natural language like "LS3A"; just make 
sure to refactor for example every occurrence in arch/loongarch and 
other parts of drivers/. That's a lot of churn, though, so I don't 
expect such changes to get accepted, and that's why the tree-wide 
consistency should be favored over the local one.


There are document[1] which named LS7A1000 bridge chip as Loongson 
7A1000 Bridge,


which is opposed to what you have said "the existing convention is 
LS7X for bridges".



there are also plenty projects[2] which encode ls2k1000 as project 
name, which simply


don't fall into the category as you have mentioned("Loongson 3A").


See [1][2] for reference, how to explain this phenomenon then?


Turn down the flames a little bit, okay? ;-)


There is no flames, its just that it need sufficient discussion when 
started to contribute to community.


We want more rigorous toward to our patch.


We can't adopt irresponsible ideas, especially from someone who is 
reluctant to give a


reasonable rationale and refused to discussion.


Such changes could probably made a damage to Loongson company.

As it tend to introduce self-contradictory between the code and comment.

Especially when we introduce DT support, there is no write space in 
the middle the string is allowed.




'write' -> 'white'


and encode model information to the compatible string is an common 
practice.



While at it, I will take it into another consideration if there are 
more professional person who


is supporting your ideas and could take the responsibility for it.

Beside this, other reviews are still acceptable, thanks for the 
reasonable part.

Re: [PATCH v14 1/2] drm: add kms driver for loongson display controller

[Sui Jingfeng]

Hi,

On 2023/5/23 00:40, WANG Xuerui wrote:

On 5/22/23 21:13, Sui Jingfeng wrote:

Hi,

On 2023/5/22 18:25, WANG Xuerui wrote:

On 2023/5/22 18:17, Sui Jingfeng wrote:

Hi,

On 2023/5/22 18:05, WANG Xuerui wrote:

On 2023/5/22 17:49, Sui Jingfeng wrote:

Hi,

On 2023/5/22 17:28, WANG Xuerui wrote:

On 2023/5/22 17:25, Sui Jingfeng wrote:

Hi,

On 2023/5/21 20:21, WANG Xuerui wrote:
+ * LS3A4000/LS3A5000/LS3A6000 CPU, they are equipped with 
on-board video RAM
+ * typically. While LS2K0500/LS2K1000/LS2K2000 are low cost 
SoCs which share
+ * the system RAM as video RAM, they don't has a dediacated 
VRAM.


CPU models are not typically prefixed with "LS", so "Loongson 
3A4000/3A5000/3A6000".


Here is because when you do programming, variable name should 
prefix with letters.


Commit messages, comments, and log messages etc. are natural 
language, so it's better to treat them differently. No problem 
to keep code as-is IMO.


Then you get two name for a single chip,  take  LS7A1000 as an 
example.


You name it as Loongson 7A1000 in commit message,  and then you 
have to define another name in the code,  say LS7A1000.


"Loongson 7A1000" is too long,  not as compact as LS7A1000.

This also avoid bind the company name to a specific product, 
because a company can produce many product.


Nah, the existing convention is "LS7X" for bridges and 
"Loongson 3A" for CPUs (SoCs like 2K fall under this category 
too). It's better to stick with existing practice so it would be 
familiar to long-time Loongson/LoongArch developers, but I 
personally don't think it will hamper understanding if you feel 
like doing otherwise.



Can you explain why it is better?

is it that the already existing is better ?


It's not about subjective perception of "better" or "worse", but 
about tree-wide consistency, and about reducing any potential 
confusion from newcomers. I remember Huacai once pointing out that 
outsiders usually have a hard time remembering "1, 2, and 3 are 
CPUs, some 2 are SoCs, 7 are bridge chips", and consistently 
referring to the bridge chips throughout the tree as "LS7A" helped.


In any case, for the sake of consistency, you can definitely refer 
to the CPU models in natural language like "LS3A"; just make 
sure to refactor for example every occurrence in arch/loongarch and 
other parts of drivers/. That's a lot of churn, though, so I don't 
expect such changes to get accepted, and that's why the tree-wide 
consistency should be favored over the local one.


There are document[1] which named LS7A1000 bridge chip as Loongson 
7A1000 Bridge,


which is opposed to what you have said "the existing convention is 
LS7X for bridges".



there are also plenty projects[2] which encode ls2k1000 as project 
name, which simply


don't fall into the category as you have mentioned("Loongson 3A").


See [1][2] for reference, how to explain this phenomenon then?


Turn down the flames a little bit, okay? ;-)


There is no flames, its just that it need sufficient discussion when 
started to contribute to community.


We want more rigorous toward to our patch.


We can't adopt irresponsible ideas, especially from someone who is 
reluctant to give a


reasonable rationale and refused to discussion.


Such changes could probably made a damage to Loongson company.

As it tend to introduce self-contradictory between the code and comment.

Especially when we introduce DT support, there is no write space in the 
middle the string is allowed.


and encode model information to the compatible string is an common practice.


While at it, I will take it into another consideration if there are more 
professional person who


is supporting your ideas and could take the responsibility for it.

Beside this, other reviews are still acceptable, thanks for the 
reasonable part.

[linux-next:master] BUILD REGRESSION cf09e328589a2ed7f6c8d90f2edb697fb4f8a96b

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: cf09e328589a2ed7f6c8d90f2edb697fb4f8a96b  Add linux-next specific 
files for 20230524

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202305240732.wucsrnaj-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305241902.uvhtmoxa-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305250935.6xsyibcz-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

arch/parisc/kernel/traps.c:312:25: error: 'SPINLOCK_BREAK_INSN' undeclared 
(first use in this function)
drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used 
uninitialized [-Wuninitialized]
drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used 
uninitialized [-Wuninitialized]
drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated 
fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
drivers/gpu/drm/i915/display/intel_display.c:6012:3: warning: unannotated 
fall-through between switch labels [-Wimplicit-fallthrough]
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer 
element is not a compile-time constant

Unverified Error/Warning (likely false positive, please contact us if 
interested):

fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code.
kernel/watchdog.c:40:19: sparse: sparse: symbol 
'watchdog_hardlockup_user_enabled' was not declared. Should it be static?
kernel/watchdog.c:41:19: sparse: sparse: symbol 
'watchdog_softlockup_user_enabled' was not declared. Should it be static?

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-randconfig-s053-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- arc-allyesconfig
|   |-- 
drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized
|   `-- 
drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized
|-- csky-randconfig-s032-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- i386-randconfig-m021-20230524
|   `-- 
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
|-- i386-randconfig-s001-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- i386-randconfig-s002-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- i386-randconfig-s003-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- ia64-randconfig-s053-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- parisc-randconfig-r015-20230524
|   `-- 
arch-parisc-kernel-traps.c:error:SPINLOCK_BREAK_INSN-undeclared-(first-use-in-this-function)
|-- parisc-randconfig-s033-20230524
|   `-- 
arch-parisc-kernel-traps.c:error:SPINLOCK_BREAK_INSN-undeclared-(first-use-in-this-function)
|-- x86_64-randconfig-s021-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- x86_64-randconfig-s022-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- x86_64-randconfig-s023-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- x86_64-randconfig-s041-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should

[v3 4/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

[Cong Yang]

The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with
the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need
to keep the LP11 state before the lcm_reset pin is pulled high. So add
lp11_before_reset flag.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Acked-by: Conor Dooley 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 ++
 1 file changed, 371 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 0772d96e446c..720b77964fcf 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1370,6 +1370,346 @@ 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_CMD(0x4A, 0x07),
+   _INIT_DCS_CMD(0x4B, 0x07),
+   _INIT_DCS_CMD(0x4C, 0x01),
+   _INIT_DCS_CMD(0x4D, 0x00),
+   _INIT_DCS_CMD(0x4E, 0x28),
+   _INIT_DCS_CMD(0x4F, 0x29),
+   _INIT_DCS_CMD(0x50, 0x10),
+   _INIT_DCS_CMD(0x51, 0x12),
+   _INIT_DCS_CMD(0x52, 0x14),
+   _INIT_DCS_CMD(0x53, 0x16),
+   _INIT_DCS_CMD(0x54, 0x08),
+   _INIT_DCS_CMD(0x55, 0x0C),
+   _INIT_DCS_CMD(0x56, 0x02),
+   _INIT_DCS_CMD(0x57, 0x02),
+   _INIT_DCS_CMD(0x58, 0x02),
+   _INIT_DCS_CMD(0x59, 0x02),
+   _INIT_DCS_CMD(0x5A, 0x02),
+   _INIT_DCS_CMD(0x5B, 0x02),
+   _INIT_DCS_CMD(0x5C, 0x02),
+
+   _INIT_DCS_CMD(0x61, 0x07),
+   _INIT_DCS_CMD(0x62, 0x07),
+   _INIT_DCS_CMD(0x63, 0x07),
+   _INIT_DCS_CMD(0x64, 0x07),
+   _INIT_DCS_CMD(0x65, 0x07),
+   _INIT_DCS_CMD(0x66, 0x01),
+   _INIT_DCS_CMD(0x67, 0x00),
+   _INIT_DCS_CMD(0x68, 0x28),
+   _INIT_DCS_CMD(0x69, 0x29),
+   _INIT_DCS_CMD(0x6A, 0x16),
+   _INIT_DCS_CMD(0x6B, 0x14),
+   _INIT_DCS_CMD(0x6C, 0x12),
+   _INIT_DCS_CMD(0x6D, 0x10),
+   _INIT_DCS_CMD(0x6E, 0x0C),
+   _INIT_DCS_CMD(0x6F, 0x08),
+   _INIT_DCS_CMD(0x70, 0x02),
+   _INIT_DCS_CMD(0x71, 0x02),
+   _INIT_DCS_CMD(0x72, 0x02),
+   _INIT_DCS_CMD(0x73, 0x02),
+   _INIT_DCS_CMD(0x74, 0x02),
+   _INIT_DCS_CMD(0x75, 0x02),
+   _INIT_DCS_CMD(0x76, 0x02),
+
+   _INIT_DCS_CMD(0x77, 0x07),
+   _INIT_DCS_CMD(0x78, 0x07),
+   _INIT_DCS_CMD(0x79, 0x07),
+   _INIT_DCS_CMD(0x7A, 0x07),
+   _INIT_DCS_CMD(0x7B, 0x07),
+   _INIT_DCS_CMD(0x7C, 0x01),
+   _INIT_DCS_CMD(0x7D, 0x00),
+   _INIT_DCS_CMD(0x7E, 0x28),
+   _INIT_DCS_CMD(0x7F, 0x29),
+   _INIT_DCS_CMD(0x80, 0x17),
+   _INIT_DCS_CMD(0x81, 0x15),
+   _INIT_DCS_CMD(0x82, 0x13),
+   _INIT_DCS_CMD(0x83, 0x11),
+   _INIT_DCS_CMD(0x84, 0x0D),
+   _INIT_DCS_CMD(0x85, 0x09),
+   _INIT_DCS_CMD(0x86, 0x02),
+   _INIT_DCS_CMD(0x87, 0x07),
+   _INIT_DCS_CMD(0x88, 0x07),
+   _INIT_DCS_CMD(0x89, 0x07),
+   _INIT_DCS_CMD(0x8A, 0x07),
+   _INIT_DCS_CMD(0x8B, 

[v3 3/4] dt-bindings: display: panel: Add compatible for Starry ili9882t

[Cong Yang]

The STARRY ili9882t is a 10.51" WUXGA TFT LCD panel,
which fits in nicely with the existing panel-boe-tv101wum-nl6
driver. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Acked-by: Conor Dooley 
---
 .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index 28a7beeb8f92..906ef62709b8 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -34,6 +34,8 @@ properties:
   - starry,2081101qfh032011-53g
 # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
   - starry,himax83102-j02
+# STARRY ili9882t 10.51" WUXGA TFT LCD panel
+  - starry,ili9882t
 
   reg:
 description: the virtual channel number of a DSI peripheral
-- 
2.25.1

[v3 2/4] drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel

[Cong Yang]

The Starry-himax83102-j02 is a 10.51" WUXGA TFT panel. which fits in nicely
with the existing panel-boe-tv101wum-nl6 driver. From the datasheet[1], MIPI
needs to keep the LP11 state before the lcm_reset pin is pulled high, so
increase lp11_before_reset flag.

[1]: https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Acked-by: Conor Dooley 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 100 ++
 1 file changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index f5a6046f1d19..0772d96e446c 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1301,6 +1301,75 @@ static const struct panel_init_cmd 
starry_qfh032011_53g_init_cmd[] = {
{},
 };
 
+static const struct panel_init_cmd starry_himax83102_j02_init_cmd[] = {
+   _INIT_DCS_CMD(0xB9, 0x83, 0x10, 0x21, 0x55, 0x00),
+   _INIT_DCS_CMD(0xB1, 0x2C, 0xB5, 0xB5, 0x31, 0xF1, 0x31, 0xD7, 0x2F, 
0x36, 0x36, 0x36, 0x36, 0x1A, 0x8B, 0x11,
+   0x65, 0x00, 0x88, 0xFA, 0xFF, 0xFF, 0x8F, 0xFF, 0x08, 0x74, 
0x33),
+   _INIT_DCS_CMD(0xB2, 0x00, 0x47, 0xB0, 0x80, 0x00, 0x12, 0x72, 0x3C, 
0xA3, 0x03, 0x03, 0x00, 0x00, 0x88, 0xF5),
+   _INIT_DCS_CMD(0xB4, 0x76, 0x76, 0x76, 0x76, 0x76, 0x76, 0x63, 0x5C, 
0x63, 0x5C, 0x01, 0x9E),
+   _INIT_DCS_CMD(0xE9, 0xCD),
+   _INIT_DCS_CMD(0xBA, 0x84),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xBC, 0x1B, 0x04),
+   _INIT_DCS_CMD(0xBE, 0x20),
+   _INIT_DCS_CMD(0xBF, 0xFC, 0xC4),
+   _INIT_DCS_CMD(0xC0, 0x36, 0x36, 0x22, 0x11, 0x22, 0xA0, 0x61, 0x08, 
0xF5, 0x03),
+   _INIT_DCS_CMD(0xE9, 0xCC),
+   _INIT_DCS_CMD(0xC7, 0x80),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xE9, 0xC6),
+   _INIT_DCS_CMD(0xC8, 0x97),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xC9, 0x00, 0x1E, 0x13, 0x88, 0x01),
+   _INIT_DCS_CMD(0xCB, 0x08, 0x13, 0x07, 0x00, 0x0F, 0x33),
+   _INIT_DCS_CMD(0xCC, 0x02),
+   _INIT_DCS_CMD(0xE9, 0xC4),
+   _INIT_DCS_CMD(0xD0, 0x03),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xD1, 0x37, 0x06, 0x00, 0x02, 0x04, 0x0C, 0xFF),
+   _INIT_DCS_CMD(0xD2, 0x1F, 0x11, 0x1F),
+   _INIT_DCS_CMD(0xD3, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 
0x08, 0x37, 0x47, 0x34, 0x3B, 0x12, 0x12, 0x03,
+   0x03, 0x32, 0x10, 0x10, 0x00, 0x10, 0x32, 0x10, 0x08, 0x00, 
0x08, 0x32, 0x17, 0x94, 0x07, 0x94, 0x00, 0x00),
+   _INIT_DCS_CMD(0xD5, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 
0x18, 0x18, 0x19, 0x19, 0x40, 0x40, 0x1A, 0x1A,
+   0x1B, 0x1B, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 
0x20, 0x21, 0x28, 0x29, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 
0x18, 0x18, 0x18, 0x18, 0x18),
+   _INIT_DCS_CMD(0xD6, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 
0x18, 0x18, 0x40, 0x40, 0x19, 0x19, 0x1A, 0x1A,
+   0x1B, 0x1B, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01, 0x00, 
0x29, 0x28, 0x21, 0x20, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 
0x18, 0x18, 0x18, 0x18, 0x18),
+   _INIT_DCS_CMD(0xD8, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 
0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA,
+   0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 
0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0),
+   _INIT_DCS_CMD(0xE0, 0x00, 0x09, 0x14, 0x1E, 0x26, 0x48, 0x61, 0x67, 
0x6C, 0x67, 0x7D, 0x7F, 0x80, 0x8B, 0x87, 0x8F, 0x98, 0xAB,
+   0xAB, 0x55, 0x5C, 0x68, 0x73, 0x00, 0x09, 0x14, 0x1E, 0x26, 
0x48, 0x61, 0x67, 0x6C, 0x67, 0x7D, 0x7F, 0x80, 0x8B, 0x87, 0x8F, 0x98, 0xAB, 
0xAB, 0x55, 0x5C, 0x68, 0x73),
+   _INIT_DCS_CMD(0xE7, 0x0E, 0x10, 0x10, 0x21, 0x2B, 0x9A, 0x02, 0x54, 
0x9A, 0x14, 0x14, 0x00, 0x00, 0x00, 0x00, 0x12, 0x05, 0x02, 0x02, 0x10),
+   _INIT_DCS_CMD(0xBD, 0x01),
+   _INIT_DCS_CMD(0xB1, 0x01, 0xBF, 0x11),
+   _INIT_DCS_CMD(0xCB, 0x86),
+   _INIT_DCS_CMD(0xD2, 0x3C, 0xFA),
+   _INIT_DCS_CMD(0xE9, 0xC5),
+   _INIT_DCS_CMD(0xD3, 0x00, 0x00, 0x00, 0x00, 0x80, 0x0C, 0x01),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xE7, 0x02, 0x00, 0x28, 0x01, 0x7E, 0x0F, 0x7E, 0x10, 
0xA0, 0x00, 0x00, 0x20, 0x40, 0x50, 0x40),
+   _INIT_DCS_CMD(0xBD, 0x02),
+   _INIT_DCS_CMD(0xD8, 0xFF, 0xFF, 0xBF, 0xFE, 0xAA, 0xA0, 0xFF, 0xFF, 
0xBF, 0xFE, 0xAA, 0xA0),
+   _INIT_DCS_CMD(0xE7, 0xFE, 0x04, 0xFE, 0x04, 0xFE, 0x04, 0x03, 0x03, 
0x03, 0x26, 0x00, 0x26, 0x81, 0x02, 0x40, 0x00, 0x20, 0x9E, 0x04, 0x03, 0x02, 
0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00),
+   _INIT_DCS_CMD(0xBD, 0x03),
+   _INIT_DCS_CMD(0xE9, 0xC6),
+   _INIT_DCS_CMD(0xB4, 0x03, 0xFF, 0xF8),
+   _INIT_DCS_CMD(0xE9, 0x3F),
+   _INIT_DCS_CMD(0xD8, 0x00, 0x2A, 0xAA, 0xA8, 0x00, 0x00, 0x00, 0x2A, 
0xAA, 0xA8, 0x00, 0x00, 0x00, 0x3F, 

[v3 1/4] dt-bindings: display: panel: Add compatible for Starry himax83102-j02

[Cong Yang]

The STARRY himax83102-j02 is a 10.51" WUXGA TFT LCD panel,
which fits in nicely with the existing panel-boe-tv101wum-nl6
driver. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
Acked-by: Conor Dooley 
---
 .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index aed55608ebf6..28a7beeb8f92 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -32,6 +32,8 @@ properties:
   - innolux,hj110iz-01a
 # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
   - starry,2081101qfh032011-53g
+# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
+  - starry,himax83102-j02
 
   reg:
 description: the virtual channel number of a DSI peripheral
-- 
2.25.1

[v3 0/4] Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel

[Cong Yang]

Compare V2: order of the tables match the order they're
referenced.

Cong Yang (4):
  dt-bindings: display: panel: Add compatible for Starry himax83102-j02
  drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
  dt-bindings: display: panel: Add compatible for Starry ili9882t
  drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

 .../display/panel/boe,tv101wum-nl6.yaml   |   4 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 471 ++
 2 files changed, 475 insertions(+)

-- 
2.25.1

Re: [v4,12/13] drm/fbdev-generic: Implement dedicated fbdev I/O helpers

[Sui Jingfeng]

Reviewed-by: Sui Jingfeng 


On 2023/5/24 17:21, Thomas Zimmermann wrote:

Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.

v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_SYS_HELPERS_DEFERRED option

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/Kconfig |   6 +-
  drivers/gpu/drm/drm_fb_helper.c | 107 
  drivers/gpu/drm/drm_fbdev_generic.c |  11 ++-
  include/drm/drm_fb_helper.h |  41 ---
  4 files changed, 6 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
  config DRM_KMS_HELPER
tristate
depends on DRM
+   select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
help
  CRTC helpers for KMS drivers.
  
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION

select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-   select FB_DEFERRED_IO
-   select FB_SYS_FOPS
-   select FB_SYS_FILLRECT
-   select FB_SYS_COPYAREA
-   select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cb03099fd2e3..bab6b252f02a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
-/**

- * drm_fb_helper_sys_read - Implements struct _ops.fb_read for system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
-  size_t count, loff_t *ppos)
-{
-   return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct _ops.fb_write for system 
memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
-   size_t count, loff_t *ppos)
-{
-   struct drm_fb_helper *helper = info->par;
-   loff_t pos = *ppos;
-   ssize_t ret;
-   struct drm_rect damage_area;
-
-   ret = fb_sys_write(info, buf, count, ppos);
-   if (ret <= 0)
-   return ret;
-
-   if (helper->funcs->fb_dirty) {
-   drm_fb_helper_memory_range_to_clip(info, pos, ret, 
_area);
-   drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
-drm_rect_width(_area),
-drm_rect_height(_area));
-   }
-
-   return ret;
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_write);
-
-/**
- * drm_fb_helper_sys_fillrect - wrapper around sys_fillrect
- * @info: fbdev registered by the helper
- * @rect: info about rectangle to fill
- *
- * A wrapper around sys_fillrect implemented by fbdev core
- */
-void drm_fb_helper_sys_fillrect(struct fb_info *info,
-   const struct fb_fillrect *rect)
-{
-   struct drm_fb_helper *helper = info->par;
-
-   sys_fillrect(info, rect);
-
-   if (helper->funcs->fb_dirty)
-   drm_fb_helper_damage(helper, rect->dx, rect->dy, rect->width, 
rect->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_fillrect);
-
-/**
- * drm_fb_helper_sys_copyarea - wrapper around sys_copyarea
- * @info: fbdev registered by the helper
- * @area: info about area to copy
- *
- * A wrapper around sys_copyarea implemented by fbdev core
- */
-void drm_fb_helper_sys_copyarea(struct fb_info *info,
-   const struct fb_copyarea *area)
-{
-   struct drm_fb_helper *helper = info->par;
-
-   sys_copyarea(info, area);
-
-   if (helper->funcs->fb_dirty)
-   drm_fb_helper_damage(helper, area->dx, area->dy, area->width, 
area->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_copyarea);
-
-/**
- * drm_fb_helper_sys_imageblit - wrapper around sys_imageblit
- * 

Re: [RFC PATCH v2 11/13] drm/msm/dpu: add a field describing inline rotation to dpu_caps

[Dmitry Baryshkov]

On Thu, 25 May 2023 at 02:20, Abhinav Kumar  wrote:
>
>
>
> On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
> > We need to know if the platform supports inline rotation on any of the
> > SSPP blocks or not. Add this information to struct dpu_caps in a form of
> > the boolean field has_inline_rot.
> >
>
> So even for this one, will a helper to detect it from the list of sspps
> be better?
>
> We are now duplicating information from sspp to dpu caps for convenience
> and nothing wrong with it if the helper will get called like every
> atomic check .
>
> But looking at the next patch, it seems we use this information only
> once during dpu_plane_init(), so why not add a helper to find this out?

Sure, why not.

>
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
> >   2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index 2d6944a9679a..33527ec7c938 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -489,6 +489,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
> >   .ubwc_version = DPU_HW_UBWC_VER_30,
> >   .has_dim_layer = true,
> >   .has_idle_pc = true,
> > + .has_inline_rot = true,
> >   .max_linewidth = 2400,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   .format_list = plane_formats_yuv,
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > index 4847aae78db2..cc64fb2e815f 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > @@ -400,6 +400,7 @@ struct dpu_rotation_cfg {
> >* @has_dim_layer  dim layer feature status
> >* @has_idle_pcindicate if idle power collapse feature is 
> > supported
> >* @has_3d_merge   indicate if 3D merge is supported
> > + * @has_inline_rot indicate if inline rotation is supported
> >* @max_linewidth  max linewidth for sspp
> >* @pixel_ram_size size of latency hiding and de-tiling buffer in 
> > bytes
> >* @max_hdeci_exp  max horizontal decimation supported (max is 
> > 2^value)
> > @@ -416,6 +417,7 @@ struct dpu_caps {
> >   bool has_dim_layer;
> >   bool has_idle_pc;
> >   bool has_3d_merge;
> > + bool has_inline_rot;
> >   /* SSPP limits */
> >   u32 max_linewidth;
> >   u32 pixel_ram_size;



-- 
With best wishes
Dmitry

Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps

[Dmitry Baryshkov]

On Thu, 25 May 2023 at 02:16, Abhinav Kumar  wrote:
>
>
>
> On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
> > As we are going to add virtual planes, add the list of supported formats
> > to the hw catalog entry. It will be used to setup universal planes, with
> > later selecting a pipe depending on whether the YUV format is used for
> > the framebuffer.
> >
>
> If your usage of format_list is going to be internal to dpu_plane.c, I
> can think of another idea for this change.
>
> This essentially translates to if (num_vig >= 1)
>
> If we can just have a small helper to detect that from the catalog can
> we use that instead of adding formats to the dpu caps?

I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.

Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.

>
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 26 +++
> >   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  4 +++
> >   2 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index 212d546b6c5d..2d6944a9679a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >   .max_vdeci_exp = MAX_VERT_DECIMATION,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps qcm2290_dpu_caps = {
> > @@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
> >   .has_idle_pc = true,
> >   .max_linewidth = 2160,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sdm845_dpu_caps = {
> > @@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >   .max_vdeci_exp = MAX_VERT_DECIMATION,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sc7180_dpu_caps = {
> > @@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
> >   .has_idle_pc = true,
> >   .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sm6115_dpu_caps = {
> > @@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
> >   .has_idle_pc = true,
> >   .max_linewidth = 2160,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sm8150_dpu_caps = {
> > @@ -376,6 +386,8 @@ static const struct dpu_caps sm8150_dpu_caps = {
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >   .max_vdeci_exp = MAX_VERT_DECIMATION,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sc8180x_dpu_caps = {
> > @@ -391,6 +403,8 @@ static const struct dpu_caps sc8180x_dpu_caps = {
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >   .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >   .max_vdeci_exp = MAX_VERT_DECIMATION,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sc8280xp_dpu_caps = {
> > @@ -404,6 +418,8 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
> >   .has_3d_merge = true,
> >   .max_linewidth = 5120,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps sm8250_dpu_caps = {
> > @@ -417,6 +433,8 @@ static const struct dpu_caps sm8250_dpu_caps = {
> >   .has_3d_merge = true,
> >   .max_linewidth = 900,
> >   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> > + .format_list = plane_formats_yuv,
> > + .num_formats = ARRAY_SIZE(plane_formats_yuv),
> >   };
> >
> >   static const struct dpu_caps 

Re: [PATCH v6 5/6] drm: lcdif: Add multiple encoders and first bridges support

[Ying Liu]

Hi Marek,

On Thu, May 11, 2023 at 12:24 AM Marek Vasut  wrote:
> On 5/10/23 11:24, Liu Ying wrote:
> > The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> > simultaneously.  Look at LCDIF output port's remote port parents to
> > find all enabled first bridges.  Add an encoder for each found bridge
> > and attach the bridge to the encoder.  This is a preparation for
> > adding i.MX93 LCDIF support.
> >
> > Tested-by: Alexander Stein 
> > Acked-by: Alexander Stein 
> > Signed-off-by: Liu Ying 
> > ---
> > v5->v6:
> > * Drop MAX_DISPLAYS macro. (Marek)
> > * Drop the encoder member in struct lcdif_drm_private.
> > * Drop endpoint id check.
>
> It might be nice to check (based on driver data for each IP variant) the
> encoder count, but that can be a separate patch.
>
> Reviewed-by: Marek Vasut 
>
> Thanks !
>
> btw if this doesn't get picked by someone in like a week or two, let me
> know and I'll apply this via drm-misc .

Thanks for your review.  I don't see any more comments in two weeks.
Can you please go ahead to apply this series?

Regards,
Liu Ying

Re: [Freedreno] [RFC PATCH v2 09/13] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check

[Dmitry Baryshkov]

On Thu, 25 May 2023 at 02:04, Abhinav Kumar  wrote:
>
>
>
> On 5/24/2023 3:46 PM, Abhinav Kumar wrote:
> >
> >
> > On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
> >> In preparation to virtualized planes support, move pstate->pipe
> >> initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
> >> case of virtual planes the plane's pipe will not be known up to the
> >> point of atomic_check() callback.
> >>
> >> Signed-off-by: Dmitry Baryshkov 
> >> ---
> >
> > Will legacy paths be broken with this? So lets say there is no
> > atomic_check we will not have a valid sspp anymore.
>
> I think it should still work, even if goes through the modeset crtc, it
> should still call drm_atomic_commit() internally which should have the
> call to atomic_check, once you confirm this , i can ack this particular
> change.

Can you please describe the scenario you have in mind? If I got you
correctly, you were asking about the non-commit IOCTLs. Because of the
atomic helpers being used (e.g. drm_atomic_helper_set_config()), they
will also result in a call to drm_atomic_commit(), which invokes
drm_atomic_check_only().

-- 
With best wishes
Dmitry

Re: [PATCH] drm/ast: Fix modeset failed on DisplayPort

[Jammy Huang]

Hi Thomas,

Thanks, I will modify the patch accordingly.

On 2023/5/24 下午 06:47, Thomas Zimmermann wrote:

Hi,

this patch also fell through the cracks. Apologies.

Am 24.05.23 um 04:29 schrieb Jammy Huang:

Hi Thomas,

Do you have other suggestion for this patch??


The main issue was that struct ast_private is now called struct 
ast_device.  So the current patch cannot be applied.




Please kindly advise.

On 2023/4/25 下午 03:39, Jammy Huang wrote:

Hi Thomas,

I think DP501 is OK. It doesn't use ioregs in ast_dp501_read_edid().

On 2023/4/25 下午 03:27, Thomas Zimmermann wrote:

Hi

Am 25.04.23 um 09:03 schrieb Jammy Huang:

If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO registers.

Add lock protection in DP's edid access to avoid this problem.


Thanks for the patch. I thought I fixed this issue already, but 
that apparently only happened for SIL164 and VGA.


What about ast_dp501_connector_helper_get_modes()? Does it require 
the locking as well?




Signed-off-by: Jammy Huang 
---
  drivers/gpu/drm/ast/ast_mode.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ast/ast_mode.c 
b/drivers/gpu/drm/ast/ast_mode.c

index 984ec590a7e7..fe5f1fd61361 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1635,6 +1635,8 @@ static int ast_dp501_output_init(struct 
ast_private *ast)
  static int ast_astdp_connector_helper_get_modes(struct 
drm_connector *connector)

  {
  void *edid;
+    struct drm_device *dev = connector->dev;
+    struct ast_private *ast = to_ast_private(dev);


We've meanwhile renamed ast_private to ast_device. Could you please 
provide an updated patch for the drm-misc-next tree?


Best regards
Thomas


    int succ;
  int count;
@@ -1643,10 +1645,18 @@ static int 
ast_astdp_connector_helper_get_modes(struct drm_connector *connector)

  if (!edid)
  goto err_drm_connector_update_edid_property;
  +    /*
+ * Protect access to I/O registers from concurrent modesetting
+ * by acquiring the I/O-register lock.
+ */
+    mutex_lock(>ioregs_lock);
+
  succ = ast_astdp_read_edid(connector->dev, edid);
  if (succ < 0)
  goto err_kfree;
  +    mutex_unlock(>ioregs_lock);
+
  drm_connector_update_edid_property(connector, edid);
  count = drm_add_edid_modes(connector, edid);
  kfree(edid);
@@ -1654,6 +1664,7 @@ static int 
ast_astdp_connector_helper_get_modes(struct drm_connector *connector)

  return count;
    err_kfree:


Here's a minor issue that the goto label should now be called 
err_mutex_unlock.


Best regards
Thomas


+ mutex_unlock(>ioregs_lock);
  kfree(edid);
  err_drm_connector_update_edid_property:
  drm_connector_update_edid_property(connector, NULL);

base-commit: 61d325dcbc05d8fef88110d35ef7776f3ac3f68b





--
Best Regards
Jammy

[PATCH v2] drm/ast: Fix modeset failed on DisplayPort

[Jammy Huang]

If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO registers.

Add lock protection in DP's edid access to avoid this problem.

Signed-off-by: Jammy Huang 
---
 v2 changes:
  - Fix build error since new struct ast_device is used.
---
 drivers/gpu/drm/ast/ast_mode.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36374828f6c8..9fcbf540d6fc 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1647,6 +1647,8 @@ static int ast_dp501_output_init(struct ast_device *ast)
 static int ast_astdp_connector_helper_get_modes(struct drm_connector 
*connector)
 {
void *edid;
+   struct drm_device *dev = connector->dev;
+   struct ast_device *ast = to_ast_device(dev);
 
int succ;
int count;
@@ -1655,10 +1657,18 @@ static int ast_astdp_connector_helper_get_modes(struct 
drm_connector *connector)
if (!edid)
goto err_drm_connector_update_edid_property;
 
+   /*
+* Protect access to I/O registers from concurrent modesetting
+* by acquiring the I/O-register lock.
+*/
+   mutex_lock(>ioregs_lock);
+
succ = ast_astdp_read_edid(connector->dev, edid);
if (succ < 0)
goto err_kfree;
 
+   mutex_unlock(>ioregs_lock);
+
drm_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
kfree(edid);
@@ -1666,6 +1676,7 @@ static int ast_astdp_connector_helper_get_modes(struct 
drm_connector *connector)
return count;
 
 err_kfree:
+   mutex_unlock(>ioregs_lock);
kfree(edid);
 err_drm_connector_update_edid_property:
drm_connector_update_edid_property(connector, NULL);

base-commit: 933174ae28ba72ab8de5b35cb7c98fc211235096
-- 
2.25.1

Re: [PATCH 21/36] drm/amd/display: add CRTC 3D LUT support

[kernel test robot]

Hi Melissa,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc3 next-20230524]
[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/Melissa-Wen/drm-drm_mode_object-increase-max-objects-to-accommodate-new-color-props/20230524-062917
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230523221520.3115570-22-mwen%40igalia.com
patch subject: [PATCH 21/36] drm/amd/display: add CRTC 3D LUT support
config: sparc-allyesconfig 
(https://download.01.org/0day-ci/archive/20230525/202305250946.oxxf7yxr-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/be212490fea8837eece5d56fa4a4963c0a21626f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Melissa-Wen/drm-drm_mode_object-increase-max-objects-to-accommodate-new-color-props/20230524-062917
git checkout be212490fea8837eece5d56fa4a4963c0a21626f
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 ~/bin/make.cross 
W=1 O=build_dir ARCH=sparc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 ~/bin/make.cross 
W=1 O=build_dir ARCH=sparc SHELL=/bin/bash drivers/gpu/drm/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202305250946.oxxf7yxr-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:515: 
>> warning: expecting prototype for amdgpu_dm_lut3d_size(). Prototype was for 
>> amdgpu_dm_get_lut3d_size() instead


vim +515 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c

   504  
   505  /**
   506   * amdgpu_dm_lut3d_size - get expected size according to hw color caps
   507   * @adev: amdgpu device
   508   * @lut_size: default size
   509   *
   510   * Return:
   511   * lut_size if DC 3D LUT is supported, zero otherwise.
   512   */
   513  static uint32_t amdgpu_dm_get_lut3d_size(struct amdgpu_device *adev,
   514   uint32_t lut_size)
 > 515  {
   516  return adev->dm.dc->caps.color.mpc.num_3dluts ? lut_size : 0;
   517  }
   518  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v14 1/9] drm/display/dsc: Add flatness and initial scale value calculations

[Jessica Zhang]

On 5/24/2023 12:05 PM, Marijn Suijten wrote:

On 2023-05-24 10:45:14, Jessica Zhang wrote:

Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Reviewed-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/display/drm_dsc_helper.c | 24 
  include/drm/display/drm_dsc_helper.h |  2 ++
  2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index fc187a8d8873..4efb6236d22c 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -1413,3 +1413,27 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
*vdsc_cfg)
return 0;
  }
  EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
+
+/**
+ * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
given DSC config
+ * @dsc: Pointer to DRM DSC config struct
+ *
+ * Return: Calculated initial scale value


Perhaps just drop Calculated from Return:?


+ */
+u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc)
+{
+   return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
dsc->initial_offset);
+}
+EXPORT_SYMBOL(drm_dsc_initial_scale_value);
+
+/**
+ * drm_dsc_flatness_det_thresh() - Calculate the flatness_det_thresh for the 
given DSC config


You've written out the word ("flatness det thresh" and "initial scale
value") entirely elsewhere, why the underscores in the doc comment here?

Instead we should have the full meaning here (and in the Return: below),
please correct me if I'm wrong but in VESA DSC v1.2a spec 6.8.5.1
Encoder Flatness Decision I think this variable means "flatness
determination threshold"?  If so, use that in the doc comment :)

(and drop the leading "the", so just "Calculate flatness determination
threshold for the given DSC config")


+ * @dsc: Pointer to DRM DSC config struct
+ *
+ * Return: Calculated flatness det thresh value


Nit: perhaps we can just drop "calculated" here?



Hi Marijn,

Sure, I will make these changes if a v15 is necessary.

In the future, can we try to group comments on wording/grammar/patch 
formatting with comments on the code itself?


I really appreciate your feedback and help in improving the 
documentation around this feature, however I don't find it very 
productive to have revisions where the only changes are on (in my 
opinion) small wording details.


Thanks,

Jessica Zhang



- Marijn


+ */
+u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}
+EXPORT_SYMBOL(drm_dsc_flatness_det_thresh);
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index fc2104415dcb..71789fb34e17 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -24,6 +24,8 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_sdp,
  void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
  int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_type type);
  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
+u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
+u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
  
  #endif /* _DRM_DSC_HELPER_H_ */
  


--
2.40.1

Re: [RFC PATCH v2 11/13] drm/msm/dpu: add a field describing inline rotation to dpu_caps

[Abhinav Kumar]

On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:

We need to know if the platform supports inline rotation on any of the
SSPP blocks or not. Add this information to struct dpu_caps in a form of
the boolean field has_inline_rot.



So even for this one, will a helper to detect it from the list of sspps 
be better?


We are now duplicating information from sspp to dpu caps for convenience 
and nothing wrong with it if the helper will get called like every 
atomic check .


But looking at the next patch, it seems we use this information only 
once during dpu_plane_init(), so why not add a helper to find this out?



Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
  2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 2d6944a9679a..33527ec7c938 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -489,6 +489,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
.ubwc_version = DPU_HW_UBWC_VER_30,
.has_dim_layer = true,
.has_idle_pc = true,
+   .has_inline_rot = true,
.max_linewidth = 2400,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.format_list = plane_formats_yuv,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 4847aae78db2..cc64fb2e815f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -400,6 +400,7 @@ struct dpu_rotation_cfg {
   * @has_dim_layer  dim layer feature status
   * @has_idle_pcindicate if idle power collapse feature is supported
   * @has_3d_merge   indicate if 3D merge is supported
+ * @has_inline_rot indicate if inline rotation is supported
   * @max_linewidth  max linewidth for sspp
   * @pixel_ram_size size of latency hiding and de-tiling buffer in bytes
   * @max_hdeci_exp  max horizontal decimation supported (max is 2^value)
@@ -416,6 +417,7 @@ struct dpu_caps {
bool has_dim_layer;
bool has_idle_pc;
bool has_3d_merge;
+   bool has_inline_rot;
/* SSPP limits */
u32 max_linewidth;
u32 pixel_ram_size;

Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps

[Abhinav Kumar]

On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:

As we are going to add virtual planes, add the list of supported formats
to the hw catalog entry. It will be used to setup universal planes, with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.



If your usage of format_list is going to be internal to dpu_plane.c, I 
can think of another idea for this change.


This essentially translates to if (num_vig >= 1)

If we can just have a small helper to detect that from the catalog can 
we use that instead of adding formats to the dpu caps?



Signed-off-by: Dmitry Baryshkov 
---
  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 26 +++
  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  4 +++
  2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps qcm2290_dpu_caps = {

@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sdm845_dpu_caps = {

@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sc7180_dpu_caps = {

@@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm6115_dpu_caps = {

@@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm8150_dpu_caps = {

@@ -376,6 +386,8 @@ static const struct dpu_caps sm8150_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sc8180x_dpu_caps = {

@@ -391,6 +403,8 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sc8280xp_dpu_caps = {

@@ -404,6 +418,8 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm8250_dpu_caps = {

@@ -417,6 +433,8 @@ static const struct dpu_caps sm8250_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 900,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm8350_dpu_caps = {

@@ -430,6 +448,8 @@ static const struct dpu_caps sm8350_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 4096,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm8450_dpu_caps = {

@@ -443,6 +463,8 @@ static const struct dpu_caps sm8450_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .format_list = plane_formats_yuv,
+   .num_formats = ARRAY_SIZE(plane_formats_yuv),
  };
  
  static const struct dpu_caps sm8550_dpu_caps = {

@@ -456,6 +478,8 @@ static const struct dpu_caps sm8550_dpu_caps = {
.has_3d_merge = true,
 

Re: [Freedreno] [RFC PATCH v2 09/13] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check

[Abhinav Kumar]

On 5/24/2023 3:46 PM, Abhinav Kumar wrote:



On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:

In preparation to virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.

Signed-off-by: Dmitry Baryshkov 
---


Will legacy paths be broken with this? So lets say there is no 
atomic_check we will not have a valid sspp anymore.


I think it should still work, even if goes through the modeset crtc, it 
should still call drm_atomic_commit() internally which should have the 
call to atomic_check, once you confirm this , i can ack this particular 
change.

[PATCH net-next v5 6/6] MAINTAINERS: ASP 2.0 Ethernet driver maintainers

[Justin Chen]

Add maintainers entry for ASP 2.0 Ethernet driver.

Reviewed-by: Simon Horman 
Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
v3
- Change from gmail to broadcom emails

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e2fd64c2ebdc..732a099f4a10 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4198,6 +4198,15 @@ F:   drivers/net/mdio/mdio-bcm-unimac.c
 F: include/linux/platform_data/bcmgenet.h
 F: include/linux/platform_data/mdio-bcm-unimac.h
 
+BROADCOM ASP 2.0 ETHERNET DRIVER
+M: Justin Chen 
+M: Florian Fainelli 
+L: bcm-kernel-feedback-l...@broadcom.com
+L: net...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
+F: drivers/net/ethernet/broadcom/asp2/
+
 BROADCOM IPROC ARM ARCHITECTURE
 M: Ray Jui 
 M: Scott Branden 
-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH net-next v5 5/6] net: phy: bcm7xxx: Add EPHY entry for 74165

[Justin Chen]

From: Florian Fainelli 

74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY,
utilize the recently defined 16nm EPHY macro to configure that PHY.

Reviewed-by: Simon Horman 
Reviewed-by: Andrew Lunn 
Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
 drivers/net/phy/bcm7xxx.c | 1 +
 include/linux/brcmphy.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index f8c17a253f8b..8478b081c058 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -913,6 +913,7 @@ static struct phy_driver bcm7xxx_driver[] = {
BCM7XXX_28NM_GPHY(PHY_ID_BCM7278, "Broadcom BCM7278"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7364, "Broadcom BCM7364"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7366, "Broadcom BCM7366"),
+   BCM7XXX_16NM_EPHY(PHY_ID_BCM74165, "Broadcom BCM74165"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM74371, "Broadcom BCM74371"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439_2, "Broadcom BCM7439 (2)"),
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index e9afbfb6d7a5..409ec9d35051 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -44,6 +44,7 @@
 #define PHY_ID_BCM7366 0x600d8490
 #define PHY_ID_BCM7346 0x600d8650
 #define PHY_ID_BCM7362 0x600d84b0
+#define PHY_ID_BCM741650x359052c0
 #define PHY_ID_BCM7425 0x600d86b0
 #define PHY_ID_BCM7429 0x600d8730
 #define PHY_ID_BCM7435 0x600d8750
-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH net-next v5 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller

[Justin Chen]

From: Florian Fainelli 

Add a binding document for the Broadcom ASP 2.0 Ethernet
controller.

Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
v5
- Fix compatible string yaml format to properly capture what we want

v4
- Adjust compatible string example to reference SoC and HW ver

v3
- Minor formatting issues
- Change channel prop to brcm,channel for vendor specific format
- Removed redundant v2.0 from compat string
- Fix ranges field

v2
- Minor formatting issues

 .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 149 +
 1 file changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml

diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml 
b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index ..c4cd24492bfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom ASP 2.0 Ethernet controller
+
+maintainers:
+  - Justin Chen 
+  - Florian Fainelli 
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+  '#address-cells':
+const: 1
+  '#size-cells':
+const: 1
+
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - brcm,bcm74165-asp
+  - const: brcm,asp-v2.1
+  - items:
+  - enum:
+  - brcm,bcm72165-asp
+  - const: brcm,asp-v2.0
+
+  reg:
+maxItems: 1
+
+  ranges: true
+
+  interrupts:
+minItems: 1
+items:
+  - description: RX/TX interrupt
+  - description: Port 0 Wake-on-LAN
+  - description: Port 1 Wake-on-LAN
+
+  clocks:
+maxItems: 1
+
+  ethernet-ports:
+type: object
+properties:
+  '#address-cells':
+const: 1
+  '#size-cells':
+const: 0
+
+patternProperties:
+  "^port@[0-9]+$":
+type: object
+
+$ref: ethernet-controller.yaml#
+
+properties:
+  reg:
+maxItems: 1
+description: Port number
+
+  brcm,channel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: ASP channel number
+
+required:
+  - reg
+  - brcm,channel
+
+additionalProperties: false
+
+patternProperties:
+  "^mdio@[0-9a-f]+$":
+type: object
+$ref: brcm,unimac-mdio.yaml
+
+description:
+  ASP internal UniMAC MDIO bus
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - ranges
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+ethernet@9c0 {
+compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
+reg = <0x9c0 0x1fff14>;
+interrupts = ;
+ranges = <0x0 0x9c0 0x1fff14>;
+clocks = < 14>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+mdio@c614 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xc614 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy0: ethernet-phy@1 {
+reg = <1>;
+};
+   };
+
+mdio@ce14 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xce14 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy1: ethernet-phy@1 {
+reg = <1>;
+};
+};
+
+ethernet-ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+brcm,channel = <8>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+
+port@1 {
+reg = <1>;
+brcm,channel = <9>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+};
+};
-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH net-next v5 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller

[Justin Chen]

Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.

This patch supports:

- Wake-on-LAN using magic packets
- basic ethtool operations (link, counters, message level)
- MAC destination address filtering (promiscuous, ALL_MULTI, etc.)

Reviewed-by: Simon Horman 
Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
v5
- Remove unnecessary parenthesis
- Use bool for bcmasp_netfilt_check_dup()

v4
- Address sparse warnings
- Fix one more reverse xmas tree violation
- Improve error logic for bcmasp_netfilt_get_reg_offset()
- Remove inlines

v3
- Fix logic error with net stats where some stats were missing
- General clean up addressing formatting/spelling/consistency
- Use dev_err_probe to save a few LoCs
- Use put_unaligned when updating net stats

v2
- Replace a couple functions with helper functions
- Fix a few WoL issues

 drivers/net/ethernet/broadcom/Kconfig  |   11 +
 drivers/net/ethernet/broadcom/Makefile |1 +
 drivers/net/ethernet/broadcom/asp2/Makefile|2 +
 drivers/net/ethernet/broadcom/asp2/bcmasp.c| 1462 
 drivers/net/ethernet/broadcom/asp2/bcmasp.h|  637 +
 .../net/ethernet/broadcom/asp2/bcmasp_ethtool.c|  568 
 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c   | 1425 +++
 .../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h  |  238 
 8 files changed, 4344 insertions(+)
 create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h

diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index 948586bf1b5b..d4166141145d 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -255,4 +255,15 @@ config BNXT_HWMON
  Say Y if you want to expose the thermal sensor data on NetXtreme-C/E
  devices, via the hwmon sysfs interface.
 
+config BCMASP
+   tristate "Broadcom ASP 2.0 Ethernet support"
+   default ARCH_BRCMSTB
+   depends on OF
+   select MII
+   select PHYLIB
+   select MDIO_BCM_UNIMAC
+   help
+ This configuration enables the Broadcom ASP 2.0 Ethernet controller
+ driver which is present in Broadcom STB SoCs such as 72165.
+
 endif # NET_VENDOR_BROADCOM
diff --git a/drivers/net/ethernet/broadcom/Makefile 
b/drivers/net/ethernet/broadcom/Makefile
index 0ddfb5b5d53c..bac5cb6ad0cd 100644
--- a/drivers/net/ethernet/broadcom/Makefile
+++ b/drivers/net/ethernet/broadcom/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_BGMAC_BCMA) += bgmac-bcma.o bgmac-bcma-mdio.o
 obj-$(CONFIG_BGMAC_PLATFORM) += bgmac-platform.o
 obj-$(CONFIG_SYSTEMPORT) += bcmsysport.o
 obj-$(CONFIG_BNXT) += bnxt/
+obj-$(CONFIG_BCMASP) += asp2/
diff --git a/drivers/net/ethernet/broadcom/asp2/Makefile 
b/drivers/net/ethernet/broadcom/asp2/Makefile
new file mode 100644
index ..e07550315f83
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_BCMASP) += bcm-asp.o
+bcm-asp-objs := bcmasp.o bcmasp_intf.o bcmasp_ethtool.o
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c 
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
new file mode 100644
index ..cb0d4f2de890
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -0,0 +1,1462 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Broadcom STB ASP 2.0 Driver
+ *
+ * Copyright (c) 2023 Broadcom
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "bcmasp.h"
+#include "bcmasp_intf_defs.h"
+
+static void _intr2_mask_clear(struct bcmasp_priv *priv, u32 mask)
+{
+   intr2_core_wl(priv, mask, ASP_INTR2_MASK_CLEAR);
+   priv->irq_mask &= ~mask;
+}
+
+static void _intr2_mask_set(struct bcmasp_priv *priv, u32 mask)
+{
+   intr2_core_wl(priv, mask, ASP_INTR2_MASK_SET);
+   priv->irq_mask |= mask;
+}
+
+void bcmasp_enable_tx_irq(struct bcmasp_intf *intf, int en)
+{
+   struct bcmasp_priv *priv = intf->parent;
+
+   if (en)
+   _intr2_mask_clear(priv, ASP_INTR2_TX_DESC(intf->channel));
+   else
+   _intr2_mask_set(priv, ASP_INTR2_TX_DESC(intf->channel));
+}
+EXPORT_SYMBOL_GPL(bcmasp_enable_tx_irq);
+
+void bcmasp_enable_rx_irq(struct bcmasp_intf *intf, int en)
+{
+   struct bcmasp_priv *priv = intf->parent;
+
+   if (en)
+   _intr2_mask_clear(priv, 

[PATCH net-next v5 4/6] net: phy: mdio-bcm-unimac: Add asp v2.0 support

[Justin Chen]

Add mdio compat string for ASP 2.0 ethernet driver.

Reviewed-by: Simon Horman 
Reviewed-by: Andrew Lunn 
Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
 drivers/net/mdio/mdio-bcm-unimac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mdio/mdio-bcm-unimac.c 
b/drivers/net/mdio/mdio-bcm-unimac.c
index bfc9be23c973..6b26a0803696 100644
--- a/drivers/net/mdio/mdio-bcm-unimac.c
+++ b/drivers/net/mdio/mdio-bcm-unimac.c
@@ -334,6 +334,8 @@ static SIMPLE_DEV_PM_OPS(unimac_mdio_pm_ops,
 unimac_mdio_suspend, unimac_mdio_resume);
 
 static const struct of_device_id unimac_mdio_ids[] = {
+   { .compatible = "brcm,asp-v2.1-mdio", },
+   { .compatible = "brcm,asp-v2.0-mdio", },
{ .compatible = "brcm,genet-mdio-v5", },
{ .compatible = "brcm,genet-mdio-v4", },
{ .compatible = "brcm,genet-mdio-v3", },
-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH net-next v5 1/6] dt-bindings: net: brcm, unimac-mdio: Add asp-v2.0

[Justin Chen]

The ASP 2.0 Ethernet controller uses a brcm unimac.

Reviewed-by: Simon Horman 
Acked-by: Conor Dooley 
Signed-off-by: Florian Fainelli 
Signed-off-by: Justin Chen 
---
 Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml 
b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
index 0be426ee1e44..6684810fcbf0 100644
--- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
@@ -22,6 +22,8 @@ properties:
   - brcm,genet-mdio-v3
   - brcm,genet-mdio-v4
   - brcm,genet-mdio-v5
+  - brcm,asp-v2.0-mdio
+  - brcm,asp-v2.1-mdio
   - brcm,unimac-mdio
 
   reg:
-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH net-next v5 0/6] Brcm ASP 2.0 Ethernet Controller

[Justin Chen]

Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165.

Add support for 74165 10/100 integrated Ethernet PHY which also uses
the ASP 2.0 Ethernet controller.

Florian Fainelli (2):
  dt-bindings: net: Brcm ASP 2.0 Ethernet controller
  net: phy: bcm7xxx: Add EPHY entry for 74165

Justin Chen (4):
  dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0
  net: bcmasp: Add support for ASP2.0 Ethernet controller
  net: phy: mdio-bcm-unimac: Add asp v2.0 support
  MAINTAINERS: ASP 2.0 Ethernet driver maintainers

 .../devicetree/bindings/net/brcm,asp-v2.0.yaml |  149 ++
 .../devicetree/bindings/net/brcm,unimac-mdio.yaml  |2 +
 MAINTAINERS|9 +
 drivers/net/ethernet/broadcom/Kconfig  |   11 +
 drivers/net/ethernet/broadcom/Makefile |1 +
 drivers/net/ethernet/broadcom/asp2/Makefile|2 +
 drivers/net/ethernet/broadcom/asp2/bcmasp.c| 1462 
 drivers/net/ethernet/broadcom/asp2/bcmasp.h|  637 +
 .../net/ethernet/broadcom/asp2/bcmasp_ethtool.c|  568 
 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c   | 1425 +++
 .../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h  |  238 
 drivers/net/mdio/mdio-bcm-unimac.c |2 +
 drivers/net/phy/bcm7xxx.c  |1 +
 include/linux/brcmphy.h|1 +
 14 files changed, 4508 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
 create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
 create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h

-- 
2.7.4



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RFC PATCH v2 09/13] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check

[Abhinav Kumar]

On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:

In preparation to virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.

Signed-off-by: Dmitry Baryshkov 
---


Will legacy paths be broken with this? So lets say there is no 
atomic_check we will not have a valid sspp anymore.

Re: [PATCH v14 3/9] drm/display/dsc: Add drm_dsc_get_bpp_int helper

[Jessica Zhang]

On 5/24/2023 12:14 PM, Marijn Suijten wrote:

On 2023-05-24 10:45:16, Jessica Zhang wrote:

Add helper to get the integer value of drm_dsc_config.bits_per_pixel

Reviewed-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 


Nit: if there comes a v15, perhaps this can be squashed with patch 1/9?
I always thought they were separate because one extends the header while
this extends the C file... but now both extend the C file with helpers.


Hi Marijn,

Sure, will squash this if there is a v15.




---
  drivers/gpu/drm/display/drm_dsc_helper.c | 13 +
  include/drm/display/drm_dsc_helper.h |  1 +
  2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index b31fe9849784..4424380c6cb6 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -1436,6 +1436,19 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
*vdsc_cfg)
  }
  EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
  
+/**

+ * drm_dsc_get_bpp_int() - Get integer bits per pixel value for the given DRM 
DSC config
+ * @vdsc_cfg: Pointer to DRM DSC config struct
+ *
+ * Return: Integer BPP value
+ */
+u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg)
+{
+   WARN_ON_ONCE(vdsc_cfg->bits_per_pixel & 0xf);


You did not add linux/bug.h back, presumably because Dmitry added
another use of WARN_ON_ONCE to this file in a previous series and it
compiles fine as the definition trickles in via another header?


Yep, this compiles fine without any error or warning.

Thanks,

Jessica Zhang



- Marijn


+   return vdsc_cfg->bits_per_pixel >> 4;
+}
+EXPORT_SYMBOL(drm_dsc_get_bpp_int);
+
  /**
   * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
given DSC config
   * @dsc: Pointer to DRM DSC config struct
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index f4e18e5d077a..913aa2071232 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -27,6 +27,7 @@ int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, 
enum drm_dsc_params
  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
  u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
  u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
+u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg);
  
  #endif /* _DRM_DSC_HELPER_H_ */
  


--
2.40.1

Re: [PATCH v13 02/10] drm/msm/dpu: add dsc blocks to the catalog of MSM8998 and SC8180X

[Marijn Suijten]

Title: DSC


On 2023-05-22 17:00:31, Kuogee Hsieh wrote:
> From: Abhinav Kumar 
> 
> Some platforms have DSC blocks which have not been declared in the catalog.
> Complete DSC 1.1 support for all platforms by adding the missing blocks to
> MSM8998 and SC8180X.
> 
> Changes in v9:
> -- add MSM8998 and SC8180x to commit title
> 
> Changes in v10:
> -- fix grammar at commit text
> 
> Changes in v12:
> -- fix "titil" with "title" at changes in v9
> 
> Signed-off-by: Abhinav Kumar 
> Reviewed-by: Dmitry Baryshkov 
> Reviewed-by: Marijn Suijten 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h |  7 +++
>  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 11 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index c0dd477..521cfd5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
>   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
>  };
>  
> +static const struct dpu_dsc_cfg msm8998_dsc[] = {
> + DSC_BLK("dsc_0", DSC_0, 0x8, 0),
> + DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
> +};
> +
>  static const struct dpu_dspp_cfg msm8998_dspp[] = {
>   DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_MSM8998_MASK,
>_dspp_sblk),
> @@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
>   .dspp = msm8998_dspp,
>   .pingpong_count = ARRAY_SIZE(msm8998_pp),
>   .pingpong = msm8998_pp,
> + .dsc_count = ARRAY_SIZE(msm8998_dsc),
> + .dsc = msm8998_dsc,
>   .intf_count = ARRAY_SIZE(msm8998_intf),
>   .intf = msm8998_intf,
>   .vbif_count = ARRAY_SIZE(msm8998_vbif),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index e8057a1..fec1665 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> @@ -142,6 +142,15 @@ static const struct dpu_merge_3d_cfg sc8180x_merge_3d[] 
> = {
>   MERGE_3D_BLK("merge_3d_2", MERGE_3D_2, 0x83200),
>  };
>  
> +static const struct dpu_dsc_cfg sc8180x_dsc[] = {
> + DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
> + DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
> + DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
> + DSC_BLK("dsc_3", DSC_3, 0x80c00, BIT(DPU_DSC_OUTPUT_CTRL)),
> + DSC_BLK("dsc_4", DSC_4, 0x81000, BIT(DPU_DSC_OUTPUT_CTRL)),
> + DSC_BLK("dsc_5", DSC_5, 0x81400, BIT(DPU_DSC_OUTPUT_CTRL)),
> +};
> +
>  static const struct dpu_intf_cfg sc8180x_intf[] = {
>   INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 
> MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK,
>   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> @@ -206,6 +215,8 @@ const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
>   .mixer = sc8180x_lm,
>   .pingpong_count = ARRAY_SIZE(sc8180x_pp),
>   .pingpong = sc8180x_pp,
> + .dsc_count = ARRAY_SIZE(sc8180x_dsc),
> + .dsc = sc8180x_dsc,
>   .merge_3d_count = ARRAY_SIZE(sc8180x_merge_3d),
>   .merge_3d = sc8180x_merge_3d,
>   .intf_count = ARRAY_SIZE(sc8180x_intf),
> -- 
> 2.7.4
> 

Re: [PATCH v13 01/10] drm/msm/dpu: set DSC flush bit correctly at MDP CTL flush register

[Marijn Suijten]

On 2023-05-22 17:00:30, Kuogee Hsieh wrote:
> The DSC CTL_FLUSH register should be programmed with the 22th bit

Sorry for botching this in v12 review, there's no DSC CTL_FLUSH
register.  Drop DSC from "The DSC CTL_FLUSH register".

> (DSC_IDX) to flush the DSC hardware blocks, not the literal value of
> 22 (which corresponds to flushing VIG1, VIG2 and RGB1 instead).
> 
> Changes in V12:
> -- split this patch out of "separate DSC flush update out of interface"
> 
> Changes in V13:
> -- rewording the commit text
> 
> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Signed-off-by: Kuogee Hsieh 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 4f7cfa9..69d0ea2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -525,7 +525,7 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
>   DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
>   if (cfg->dsc) {
> - DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
> + DPU_REG_WRITE(>hw, CTL_FLUSH, BIT(DSC_IDX));
>   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
>   }
>  }
> -- 
> 2.7.4
> 

Re: [PATCH v13 08/10] drm/msm/dpu: separate DSC flush update out of interface

[Marijn Suijten]

On 2023-05-22 17:00:37, Kuogee Hsieh wrote:
> Currently DSC flushing happens during interface configuration at
> dpu_hw_ctl_intf_cfg_v1(). Separate DSC flush away from
> dpu_hw_ctl_intf_cfg_v1() by adding dpu_hw_ctl_update_pending_flush_dsc_v1()
> to handle both per-DSC engine and DSC flush bits at same time to make it
> consistent with the location of flush programming of other DPU sub-blocks.
> 
> Changes in v10:
> -- rewording commit text
> -- pass ctl directly instead of dpu_enc to dsc_pipe_cfg()
> -- ctx->pending_dsc_flush_mask = 0;
> 
> Changes in v11:
> -- add Fixes tag
> -- capitalize MERGE_3D, DSPP and DSC at struct dpu_hw_ctl_ops{}

But MERGE_3D and DSPP documentation entries were removed some time
later, though this is not reflected anywhere in the changelog.

> 
> Changes in v12:
> -- move dsc parameter to next line at dpu_encoder_dsc_pipe_cfg()
> 
> Signed-off-by: Kuogee Hsieh 
> Reviewed-by: Dmitry Baryshkov 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c  | 23 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h  | 11 +++
>  3 files changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index ffa6f04..7fca09e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1834,7 +1834,8 @@ dpu_encoder_dsc_initial_line_calc(struct drm_dsc_config 
> *dsc,
>   return DIV_ROUND_UP(total_pixels, dsc->slice_width);
>  }
>  
> -static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,
> +static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_ctl *ctl,
> +  struct dpu_hw_dsc *hw_dsc,
>struct dpu_hw_pingpong *hw_pp,
>struct drm_dsc_config *dsc,
>u32 common_mode,
> @@ -1854,6 +1855,9 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc 
> *hw_dsc,
>  
>   if (hw_pp->ops.enable_dsc)
>   hw_pp->ops.enable_dsc(hw_pp);
> +
> + if (ctl->ops.update_pending_flush_dsc)
> + ctl->ops.update_pending_flush_dsc(ctl, hw_dsc->idx);
>  }
>  
>  static void dpu_encoder_prep_dsc(struct dpu_encoder_virt *dpu_enc,
> @@ -1861,6 +1865,7 @@ static void dpu_encoder_prep_dsc(struct 
> dpu_encoder_virt *dpu_enc,
>  {
>   /* coding only for 2LM, 2enc, 1 dsc config */
>   struct dpu_encoder_phys *enc_master = dpu_enc->cur_master;
> + struct dpu_hw_ctl *ctl = enc_master->hw_ctl;
>   struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
>   struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
>   int this_frame_slices;
> @@ -1898,7 +1903,8 @@ static void dpu_encoder_prep_dsc(struct 
> dpu_encoder_virt *dpu_enc,
>   initial_lines = dpu_encoder_dsc_initial_line_calc(dsc, enc_ip_w);
>  
>   for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
> - dpu_encoder_dsc_pipe_cfg(hw_dsc[i], hw_pp[i], dsc, 
> dsc_common_mode, initial_lines);
> + dpu_encoder_dsc_pipe_cfg(ctl, hw_dsc[i], hw_pp[i],
> +  dsc, dsc_common_mode, initial_lines);
>  }
>  
>  void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 64c21e0..ad6983e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -103,6 +103,7 @@ static inline void dpu_hw_ctl_clear_pending_flush(struct 
> dpu_hw_ctl *ctx)
>   ctx->pending_intf_flush_mask = 0;
>   ctx->pending_wb_flush_mask = 0;
>   ctx->pending_merge_3d_flush_mask = 0;
> + ctx->pending_dsc_flush_mask = 0;
>  
>   memset(ctx->pending_dspp_flush_mask, 0,
>   sizeof(ctx->pending_dspp_flush_mask));
> @@ -142,6 +143,11 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct 
> dpu_hw_ctl *ctx)
>   CTL_DSPP_n_FLUSH(dspp - DSPP_0),
>   ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
>   }
> +
> + if (ctx->pending_flush_mask & BIT(DSC_IDX))
> + DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
> +   ctx->pending_dsc_flush_mask);
> +
>   DPU_REG_WRITE(>hw, CTL_FLUSH, ctx->pending_flush_mask);
>  }
>  
> @@ -288,6 +294,13 @@ static void 
> dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
>   ctx->pending_flush_mask |= BIT(MERGE_3D_IDX);
>  }
>  
> +static void dpu_hw_ctl_update_pending_flush_dsc_v1(struct dpu_hw_ctl *ctx,
> +enum dpu_dsc dsc_num)
> +{
> + ctx->pending_dsc_flush_mask |= BIT(dsc_num - DSC_0);
> + ctx->pending_flush_mask |= BIT(DSC_IDX);
> +}
> +
>  static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl 

Re: [PATCH v13 10/10] drm/msm/dpu: tear down DSC data path when DSC disabled

[Marijn Suijten]

Title: Tear down DSC datapath on encoder cleanup

(from v10 review, this is v13...)

On 2023-05-22 17:00:39, Kuogee Hsieh wrote:


- Marijn

Re: [PATCH v13 07/10] drm/msm/dpu: always clear every individual pending flush mask

[Marijn Suijten]

On 2023-05-22 17:00:36, Kuogee Hsieh wrote:
> There are two tiers of pending flush control, top levle and

levle -> level

> individual hardware block. Currently only the top level of
> flush mask is reset to 0 but the individual pending flush masks
> of particular hardware blocks are left at their previous values,
> eventually accumulating all possible bit values and typically
> flushing more than necessary.
> Reset all individual hardware blocks flush masks to 0 to avoid

block, drop -s, because masks is plural.

> individual hardware block be triggered accidentally.

be = from being

triggered = flushed?

(You just said "individual hardware block", it would be okay to refer to
that with just "Reset all individual hardware block flush masks to 0 to
avoid accidentally flushing them.")

> 
> Changes in V13:
> -- rewording commi ttext

commit text

> -- add an empty space line as suggested
> 
> Signed-off-by: Kuogee Hsieh 
> Reviewed-by: Dmitry Baryshkov 
> Reviewed-by: Marijn Suijten 

So no fixes tag?

- Marijn

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 69d0ea2..64c21e0 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -100,6 +100,9 @@ static inline void dpu_hw_ctl_clear_pending_flush(struct 
> dpu_hw_ctl *ctx)
>   trace_dpu_hw_ctl_clear_pending_flush(ctx->pending_flush_mask,
>dpu_hw_ctl_get_flush_register(ctx));
>   ctx->pending_flush_mask = 0x0;
> + ctx->pending_intf_flush_mask = 0;
> + ctx->pending_wb_flush_mask = 0;
> + ctx->pending_merge_3d_flush_mask = 0;
>  
>   memset(ctx->pending_dspp_flush_mask, 0,
>   sizeof(ctx->pending_dspp_flush_mask));
> -- 
> 2.7.4
> 

Re: [PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional

[Dixit, Ashutosh]

On Wed, 24 May 2023 10:53:20 -0700, Tvrtko Ursulin wrote:
>

Hi Tvrtko,

> On 24/05/2023 18:38, Dixit, Ashutosh wrote:
> > On Wed, 24 May 2023 04:38:18 -0700, Tvrtko Ursulin wrote:
> >> On 23/05/2023 16:19, Ashutosh Dixit wrote:
> >>> No functional changes but we can remove some unsightly index computation
> >>> and read/write functions if we convert the PMU sample array from a
> >>> one-dimensional to a two-dimensional array.
> >>>
> >>> Suggested-by: Tvrtko Ursulin 
> >>> Signed-off-by: Ashutosh Dixit 
> >>> ---
> >>>drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
> >>>drivers/gpu/drm/i915/i915_pmu.h |  2 +-
> >>>2 files changed, 19 insertions(+), 43 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> >>> b/drivers/gpu/drm/i915/i915_pmu.c
> >>> index b47d890d4ada1..137e0df9573ee 100644
> >>> --- a/drivers/gpu/drm/i915/i915_pmu.c
> >>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> >>> @@ -195,33 +195,6 @@ static inline s64 ktime_since_raw(const ktime_t kt)
> >>>   return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
> >>>}
> >>>-static unsigned int
> >>> -__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
> >>> -{
> >>> - unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
> >>> -
> >>> - GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
> >>> -
> >>> - return idx;
> >>> -}
> >>> -
> >>> -static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int 
> >>> sample)
> >>> -{
> >>> - return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
> >>> -}
> >>> -
> >>> -static void
> >>> -store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 
> >>> val)
> >>> -{
> >>> - pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
> >>> -}
> >>> -
> >>> -static void
> >>> -add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, 
> >>> u32 val, u32 mul)
> >>> -{
> >>> - pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val, 
> >>> mul);
> >>> -}
> >>
> >> IMO read and store helpers could have stayed and just changed the
> >> implementation. Like add_sample_mult which you just moved. I would have
> >> been a smaller patch. So dunno.. a bit of a reluctant r-b.
> >
> > Are you referring just to add_sample_mult or to all the other functions
> > too? add_sample_mult I moved it to where it was before bc4be0a38b63
>
> Read and store helpers.
>
> > ("drm/i915/pmu: Prepare for multi-tile non-engine counters"), could have
> > left it here I guess.
> >
> > The other read and store helpers are not needed with the 2-d array at all
> > since the compiler itself will do that, so I thought it was better to get
> > rid of them completely.
>
> Yes I get it, just that I didn't see the benefit of removing them.
>
> For example:
>
>  -store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
>  +pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
>
> It's a meh for me. Either flavour looks fine to me so I would have erred on
> the side of keeping the patch small. If anything I probably slightly prefer
> that the struct pmu_sample implementation was able to be changed with less
> churn before. For example. But a very minor argument really.

OK, I finally understood and have made this change in Patch v2. Please take
a look.

>
> Or maybe next step is get rid of the struct i915_pmu_sample. It is a struct
> because originally previous value was tracked too. Then I removed that and
> it was easier to keep the struct. I guess it can go now and then the
> removal of helpers here will look somewhat nicer without the trailing .cur
> on every affected line.

I have left this as is for now in case the i915_pmu_sample need to be
expanded again. Should be ok with the read/store helpers.

>
> > Let me know if you want any changes, otherwise I will leave as is.
>
> You can leave it as is, I dont' mind much.

I went ahead and changed it anyway since you seemed to want it.

Thanks.
--
Ashutosh

>
> >> Reviewed-by: Tvrtko Ursulin 
> >
> > Thanks for the review. Thanks Andrzej too :)
> > --
> > Ashutosh
> >
> >>> -
> >>>static u64 get_rc6(struct intel_gt *gt)
> >>>{
> >>>   struct drm_i915_private *i915 = gt->i915;
> >>> @@ -240,7 +213,7 @@ static u64 get_rc6(struct intel_gt *gt)
> >>>   spin_lock_irqsave(>lock, flags);
> >>>   if (awake) {
> >>> - store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
> >>> + pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
> >>>   } else {
> >>>   /*
> >>>* We think we are runtime suspended.
> >>> @@ -250,13 +223,13 @@ static u64 get_rc6(struct intel_gt *gt)
> >>>* counter value.
> >>>*/
> >>>   val = ktime_since_raw(pmu->sleep_last[gt_id]);
> >>> - val += read_sample(pmu, gt_id, __I915_SAMPLE_RC6);
> >>> + val += pmu->sample[gt_id][__I915_SAMPLE_RC6].cur;
> >>>   }
> >>>-  if (val < read_sample(pmu, gt_id, 
> >>> __I915_SAMPLE_RC6_LAST_REPORTED))
> >>> - val = 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked

[Dixit, Ashutosh]

On Wed, 24 May 2023 02:12:31 -0700, Andrzej Hajda wrote:
>

Hi Andrzej,

> On 23.05.2023 17:19, Ashutosh Dixit wrote:
> > pmu_needs_timer() keeps the timer running even when GT is parked,
> > ostensibly to sample requested/actual frequencies. However
> > frequency_sample() has the following:
> >
> > /* Report 0/0 (actual/requested) frequency while parked. */
> > if (!intel_gt_pm_get_if_awake(gt))
> > return;
> >
> > The above code prevents frequencies to be sampled while the GT is
> > parked. So we might as well turn off the sampling timer itself in this
> > case and save CPU cycles/power.
> >
> > v2: Instead of turning freq bits off, return false, since no counters will
> >  run after this change when GT is parked (Tvrtko)
> >
> > Signed-off-by: Ashutosh Dixit 
> > Reviewed-by: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 12 +---
> >   1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index a814583e19fd7..b47d890d4ada1 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -144,6 +144,10 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool 
> > gpu_active)
> > struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
> > u32 enable;
> >   + /* When GPU is idle, at present no counters need to run */
> > +   if (!gpu_active)
> > +   return false;
> > +
>
> What is then purpose of calling pmu_needs_timer with 2nd arg false?
> Why not just replace all occurrences of pmu_needs_timer(.., false) with
> false? And remove the 2nd argument.

OK, this didn't seem unreasonable so I went ahead and made this change in
Patch v3. Copying Tvrtko too in case he prefers v2 for any reason. Please
review.

Thanks.
--
Ashutosh


>
>
>
> > /*
> >  * Only some counters need the sampling timer.
> >  *
> > @@ -157,17 +161,11 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, 
> > bool gpu_active)
> >  */
> > enable &= frequency_enabled_mask() | ENGINE_SAMPLE_MASK;
> >   - /*
> > -* When the GPU is idle per-engine counters do not need to be
> > -* running so clear those bits out.
> > -*/
> > -   if (!gpu_active)
> > -   enable &= ~ENGINE_SAMPLE_MASK;
> > /*
> >  * Also there is software busyness tracking available we do not
> >  * need the timer for I915_SAMPLE_BUSY counter.
> >  */
> > -   else if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS)
> > +   if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS)
> > enable &= ~BIT(I915_SAMPLE_BUSY);
> > /*
>

[PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional

[Ashutosh Dixit]

No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.

v2: Retain read/store helpers (Tvrtko)

Suggested-by: Tvrtko Ursulin 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_pmu.c | 16 +++-
 drivers/gpu/drm/i915/i915_pmu.h |  2 +-
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 09313cf9316b4..f96fe92dca4e4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -191,31 +191,21 @@ static inline s64 ktime_since_raw(const ktime_t kt)
return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
 }
 
-static unsigned int
-__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
-   unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
-
-   GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
-
-   return idx;
-}
-
 static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample)
 {
-   return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
+   return pmu->sample[gt_id][sample].cur;
 }
 
 static void
 store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
 {
-   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
+   pmu->sample[gt_id][sample].cur = val;
 }
 
 static void
 add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32 val, 
u32 mul)
 {
-   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val, 
mul);
+   pmu->sample[gt_id][sample].cur += mul_u32_u32(val, mul);
 }
 
 static u64 get_rc6(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 33d80fbaab8bc..d20592e7db999 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -127,7 +127,7 @@ struct i915_pmu {
 * Only global counters are held here, while the per-engine ones are in
 * struct intel_engine_cs.
 */
-   struct i915_pmu_sample sample[I915_PMU_MAX_GTS * 
__I915_NUM_PMU_SAMPLERS];
+   struct i915_pmu_sample 
sample[I915_PMU_MAX_GTS][__I915_NUM_PMU_SAMPLERS];
/**
 * @sleep_last: Last time GT parked for RC6 estimation.
 */
-- 
2.38.0

[PATCH 1/2] drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked

[Ashutosh Dixit]

pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:

/* Report 0/0 (actual/requested) frequency while parked. */
if (!intel_gt_pm_get_if_awake(gt))
return;

The above code prevents frequencies to be sampled while the GT is
parked. So we might as well turn off the sampling timer itself in this
case and save CPU cycles/power.

v2: Instead of turning freq bits off, return false, since no counters will
run after this change when GT is parked (Tvrtko)
v3: Remove gpu_active argument of pmu_needs_timer (Andrzej)

Signed-off-by: Ashutosh Dixit 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index a814583e19fd7..09313cf9316b4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -139,7 +139,7 @@ static u32 frequency_enabled_mask(void)
return mask;
 }
 
-static bool pmu_needs_timer(struct i915_pmu *pmu, bool gpu_active)
+static bool pmu_needs_timer(struct i915_pmu *pmu)
 {
struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
u32 enable;
@@ -157,17 +157,11 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool 
gpu_active)
 */
enable &= frequency_enabled_mask() | ENGINE_SAMPLE_MASK;
 
-   /*
-* When the GPU is idle per-engine counters do not need to be
-* running so clear those bits out.
-*/
-   if (!gpu_active)
-   enable &= ~ENGINE_SAMPLE_MASK;
/*
 * Also there is software busyness tracking available we do not
 * need the timer for I915_SAMPLE_BUSY counter.
 */
-   else if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS)
+   if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS)
enable &= ~BIT(I915_SAMPLE_BUSY);
 
/*
@@ -295,7 +289,7 @@ static void park_rc6(struct intel_gt *gt)
 
 static void __i915_pmu_maybe_start_timer(struct i915_pmu *pmu)
 {
-   if (!pmu->timer_enabled && pmu_needs_timer(pmu, true)) {
+   if (!pmu->timer_enabled && pmu_needs_timer(pmu)) {
pmu->timer_enabled = true;
pmu->timer_last = ktime_get();
hrtimer_start_range_ns(>timer,
@@ -321,7 +315,7 @@ void i915_pmu_gt_parked(struct intel_gt *gt)
 */
pmu->unparked &= ~BIT(gt->info.id);
if (pmu->unparked == 0)
-   pmu->timer_enabled = pmu_needs_timer(pmu, false);
+   pmu->timer_enabled = false;
 
spin_unlock_irq(>lock);
 }
@@ -827,7 +821,7 @@ static void i915_pmu_disable(struct perf_event *event)
 */
if (--pmu->enable_count[bit] == 0) {
pmu->enable &= ~BIT(bit);
-   pmu->timer_enabled &= pmu_needs_timer(pmu, true);
+   pmu->timer_enabled &= pmu_needs_timer(pmu);
}
 
spin_unlock_irqrestore(>lock, flags);
-- 
2.38.0

[PATCH v2 0/2] drm/i915/pmu: couple of cleanups

[Ashutosh Dixit]

Cc: Andrzej Hajda 
Cc: Tvrtko Ursulin 

Signed-off-by: Ashutosh Dixit 

Ashutosh Dixit (2):
  drm/i915/pmu: Turn off the timer to sample frequencies when GT is
parked
  drm/i915/pmu: Make PMU sample array two-dimensional

 drivers/gpu/drm/i915/i915_pmu.c | 32 
 drivers/gpu/drm/i915/i915_pmu.h |  2 +-
 2 files changed, 9 insertions(+), 25 deletions(-)

-- 
2.38.0

Re: [PATCH net-next v4 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller

[Conor Dooley]

On Wed, May 24, 2023 at 02:47:59PM -0700, Justin Chen wrote:
> On Tue, May 23, 2023 at 11:56 PM Conor Dooley  
> wrote:

> Gotcha. I got something like this now.
> 
>   compatible:
> oneOf:
>   - items:
>   - enum:
>   - brcm,bcm74165-asp
>   - const: brcm,asp-v2.1
>   - items:
>   - enum:
>   - brcm,bcm72165-asp
>   - const: brcm,asp-v2.0

Yes, this is what I had in mind.

> Apologies, still getting used to this yaml stuff. Starting to make a
> bit more sense to me now.

No worries.

> > > valid fallback for "brcm,asp-v2.1"?
> > > The oneOf: also becomes redundant since you only have one items:.
> > >
> > > > Will submit a v5 tomorrow.
> > >
> > > BTW, when you do, could you use the address listed in MAINTAINERS rather
> > > than the one you used for this version?
> > >
> I changed the address listed in MAINTAINERS from the previous versions
> of this patchset. The current version should match the address that
> this patch set was sent from. Looks like I forgot to add a changelog
> for that in v4.

Hmm, I must not have been clear. You sent it to  and I
was hoping that you would use  instead so that you
end up hitting the right mail filters :) It's not a problem, I was just
added to it in -rc1 so get_maintainer.pl probably didn't spit my name
out for your original revision.

Thanks,
Conor.

Re: [PATCH net-next v4 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller

[Justin Chen]

On Tue, May 23, 2023 at 11:56 PM Conor Dooley
 wrote:
>
> On Wed, May 24, 2023 at 07:51:07AM +0100, Conor Dooley wrote:
> > Hey Justin,
> > On Tue, May 23, 2023 at 04:27:12PM -0700, Justin Chen wrote:
> > > On Tue, May 23, 2023 at 3:55 PM Conor Dooley  wrote:
> > > > On Tue, May 23, 2023 at 02:53:43PM -0700, Justin Chen wrote:
> > > >
> > > > > +  compatible:
> > > > > +enum:
> > > > > +  - brcm,asp-v2.0
> > > > > +  - brcm,bcm72165-asp
> > > > > +  - brcm,asp-v2.1
> > > > > +  - brcm,bcm74165-asp
> > > >
> > > > > +compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
> > > >
> > > > You can't do this, as Rob's bot has pointed out. Please test the
> > > > bindings :( You need one of these type of constructs:
> > > >
> > > > compatible:
> > > >   oneOf:
> > > > - items:
> > > > - const: brcm,bcm72165-asp
> > > > - const: brcm,asp-v2.0
> > > > - items:
> > > > - const: brcm,bcm74165-asp
> > > > - const: brcm,asp-v2.1
> > > >
> > > > Although, given either you or Florian said there are likely to be
> > > > multiple parts, going for an enum, rather than const for the brcm,bcm..
> > > > entry will prevent some churn. Up to you.
> > > >
> > > Urg so close. Thought it was a trivial change, so didn't bother
> > > retesting the binding. I think I have it right now...
> > >
> > >   compatible:
> > > oneOf:
> > >   - items:
> > >   - enum:
> > >   - brcm,bcm72165-asp
> > >   - brcm,bcm74165-asp
> > >   - enum:
> > >   - brcm,asp-v2.0
> > >   - brcm,asp-v2.1
> > >
> > > Something like this look good?
> >
> > I am still caffeine-less, but this implies that both of
> > "brcm,bcm72165-asp", "brcm,asp-v2.0"
> > _and_
> > "brcm,bcm72165-asp", "brcm,asp-v2.1"
> > are. I suspect that that is not the case, unless "brcm,asp-v2.0" is a
>
> I a word. s/are/are valid/
>
Gotcha. I got something like this now.

  compatible:
oneOf:
  - items:
  - enum:
  - brcm,bcm74165-asp
  - const: brcm,asp-v2.1
  - items:
  - enum:
  - brcm,bcm72165-asp
  - const: brcm,asp-v2.0

Apologies, still getting used to this yaml stuff. Starting to make a
bit more sense to me now.

> > valid fallback for "brcm,asp-v2.1"?
> > The oneOf: also becomes redundant since you only have one items:.
> >
> > > Will submit a v5 tomorrow.
> >
> > BTW, when you do, could you use the address listed in MAINTAINERS rather
> > than the one you used for this version?
> >
I changed the address listed in MAINTAINERS from the previous versions
of this patchset. The current version should match the address that
this patch set was sent from. Looks like I forgot to add a changelog
for that in v4.

Thanks,
Justin

> > Cheers,
> > Conor.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [v4,13/13] drm/i915: Implement dedicated fbdev I/O helpers

[Sui Jingfeng]

Hi,


I have just tested this patch on my i3-8100@3.6Ghz cpu + h110 
motherboard with fbtest:



Benchmarking... 10x10 squares: 26.44 Mpixels/s
Benchmarking... 20x20 squares: 52.54 Mpixels/s
Benchmarking... 50x50 squares: 128.13 Mpixels/s
Benchmarking... 100x100 squares: 252.21 Mpixels/s
Benchmarking... 200x200 squares: 489.48 Mpixels/s
Benchmarking... 500x500 squares: 1073.42 Mpixels/s
Benchmarking... 1000x1000 squares: 1823.72 Mpixels/s
Benchmarking... R5 circles: 18.73 Mpixels/s
Benchmarking... R10 circles: 39.05 Mpixels/s
Benchmarking... R25 circles: 98.60 Mpixels/s
Benchmarking... R50 circles: 196.31 Mpixels/s
Benchmarking... R100 circles: 382.81 Mpixels/s
Benchmarking... R250 circles: 872.09 Mpixels/s
Benchmarking... R500 circles: 1511.50 Mpixels/s


Then I mount ast2400 card on the same motherboard:


Benchmarking... 10x10 squares: 261.75 Mpixels/s
Benchmarking... 20x20 squares: 539.37 Mpixels/s
Benchmarking... 50x50 squares: 1161.53 Mpixels/s
Benchmarking... 100x100 squares: 1624.30 Mpixels/s
Benchmarking... 200x200 squares: 2089.74 Mpixels/s
Benchmarking... 500x500 squares: 2779.27 Mpixels/s
Benchmarking... 1000x1000 squares: 2382.28 Mpixels/s
Benchmarking... R5 circles: 151.03 Mpixels/s
Benchmarking... R10 circles: 311.34 Mpixels/s
Benchmarking... R25 circles: 698.63 Mpixels/s
Benchmarking... R50 circles: 1184.14 Mpixels/s
Benchmarking... R100 circles: 1791.60 Mpixels/s
Benchmarking... R250 circles: 2641.76 Mpixels/s
Benchmarking... R500 circles: 2669.38 Mpixels/s


The logs of fbtest and fbdev of IGT say passed.


On 2023/5/24 17:21, Thomas Zimmermann wrote:

Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.

i915's fbdev emulation is still incomplete as it doesn't implement
deferred I/O and damage handling for mmaped pages.

v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_IO_HELPERS options

Signed-off-by: Thomas Zimmermann 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: "Ville Syrjälä" 
---
  drivers/gpu/drm/Kconfig|   3 -
  drivers/gpu/drm/drm_fb_helper.c| 107 -
  drivers/gpu/drm/i915/Kconfig   |   1 +
  drivers/gpu/drm/i915/display/intel_fbdev.c |  14 +--
  include/drm/drm_fb_helper.h|  39 
  5 files changed, 9 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 92a782827b7b..bb2e48cc6cd6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -133,9 +133,6 @@ config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPER
depends on FB=y || FB=DRM_KMS_HELPER
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bab6b252f02a..9978147bbc8a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
-/**

- * drm_fb_helper_cfb_read - Implements struct _ops.fb_read for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_read(struct fb_info *info, char __user *buf,
-  size_t count, loff_t *ppos)
-{
-   return fb_io_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_read);
-
-/**
- * drm_fb_helper_cfb_write - Implements struct _ops.fb_write for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_write(struct fb_info *info, const char __user *buf,
-   size_t count, loff_t *ppos)
-{
-   struct drm_fb_helper *helper = info->par;
-   loff_t pos = *ppos;
-   ssize_t ret;
-   struct drm_rect damage_area;
-
-   ret = fb_io_write(info, buf, count, ppos);
-   if (ret <= 0)
-   return ret;
-
-   if (helper->funcs->fb_dirty) {
-   drm_fb_helper_memory_range_to_clip(info, pos, ret, 
_area);
- 

Re: [v2 4/4] dt-bindings: display: panel: Add compatible for Starry ili9882t

[Doug Anderson]

Hi,

On Wed, May 24, 2023 at 12:45 AM Cong Yang
 wrote:
>
> The STARRY ili9882t is a 10.51" WUXGA TFT LCD panel,
> which fits in nicely with the existing panel-boe-tv101wum-nl6
> driver. Hence, we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang 
> ---
>  .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++
>  1 file changed, 2 insertions(+)

nit: bindings usually land first, so you should swap the order of
patch #3 and patch #4 in your series.

In any case:

Reviewed-by: Douglas Anderson 

Re: [v2 2/4] dt-bindings: display: panel: Add compatible for Starry himax83102-j02

[Doug Anderson]

Hi,

On Wed, May 24, 2023 at 12:45 AM Cong Yang
 wrote:
>
> The STARRY himax83102-j02 is a 10.51" WUXGA TFT LCD panel,
> which fits in nicely with the existing panel-boe-tv101wum-nl6
> driver. Hence, we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang 
> ---
>  .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++
>  1 file changed, 2 insertions(+)

nit: bindings usually land first, so you should swap the order of
patch #1 and patch #2 in your series.

In any case:

Reviewed-by: Douglas Anderson 

Re: [v2 3/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

[Doug Anderson]

Hi,

On Wed, May 24, 2023 at 12:45 AM Cong Yang
 wrote:
>
> The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with
> the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need
> to keep the LP11 state before the lcm_reset pin is pulled high. So add
> lp11_before_reset flag.
>
> Signed-off-by: Cong Yang 
> ---
>  .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 ++
>  1 file changed, 371 insertions(+)

Assuming you order the table in the proper place like I requested for
("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel"),
then:

Reviewed-by: Douglas Anderson 

[pull] amdgpu, radeon drm-fixes-6.4

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 6.4.

The following changes since commit 79ef1c9d14c65a5c3f7eec47389d8c2a33be8e8d:

  Merge tag 'amd-drm-fixes-6.4-2023-05-18' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-05-19 11:26:21 
+1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-6.4-2023-05-24

for you to fetch changes up to 482e6ad9adde69d9da08864b4ccf4dfd53edb2f0:

  drm/amd/display: Have Payload Properly Created After Resume (2023-05-24 
16:37:00 -0400)


amd-drm-fixes-6.4-2023-05-24:

amdgpu:
- Fix missing BO unlocking in KIQ error path
- Avoid spurious secure display error messages
- SMU13 fix
- Fix an OD regression
- GPU reset display IRQ warning fix
- MST fix

radeon:
- Fix a DP regression


Alan Liu (1):
  drm/amd/display: Fix warning in disabling vblank irq

Alex Deucher (1):
  drm/radeon: reintroduce radeon_dp_work_func content

Evan Quan (1):
  drm/amd/pm: add missing NotifyPowerSource message mapping for SMU13.0.7

Fangzhi Zuo (1):
  drm/amd/display: Have Payload Properly Created After Resume

Jesse Zhang (1):
  drm/amdgpu: don't enable secure display on incompatible platforms

Jonatas Esteves (1):
  drm/amd/pm: Fix output of pp_od_clk_voltage

Sukrut Bellary (1):
  drm:amd:amdgpu: Fix missing buffer object unlock in failure path

 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  4 +++-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  4 +++-
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  8 ++-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 25 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 16 +++---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 12 +--
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c   |  1 +
 drivers/gpu/drm/radeon/radeon_irq_kms.c| 10 +
 8 files changed, 47 insertions(+), 33 deletions(-)

Re: [v2 1/4] drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel

[Doug Anderson]

Hi,

On Wed, May 24, 2023 at 12:28 AM Cong Yang
 wrote:
>
> The Starry-himax83102-j02 is a 10.51" WUXGA TFT panel. which fits in nicely
> with the existing panel-boe-tv101wum-nl6 driver. From the datasheet[1], MIPI
> needs to keep the LP11 state before the lcm_reset pin is pulled high, so
> increase lp11_before_reset flag.
>
> [1]: 
> https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence
>
> Signed-off-by: Cong Yang 
> ---
>  .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 100 ++
>  1 file changed, 100 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
> b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> index f5a6046f1d19..5c8ec263e11f 100644
> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> @@ -76,6 +76,75 @@ struct panel_init_cmd {
> .len = sizeof((char[]){__VA_ARGS__}), \
> .data = (char[]){__VA_ARGS__} }
>
> +static const struct panel_init_cmd starry_himax83102_j02_init_cmd[] = {

nit: Please have the order of the tables match the order they're
referenced. That means this should come _after_
"starry_qfh032011_53g_init_cmd", not at the start of the tables.


-Doug

[PATCH] drm/tegra: dc: cap non-cursor plane zpos to 254

[Emmanuel Gil Peyrot]

Since cursor plane has the immutable zpos 255, other planes can’t take
its place so we can cap them to 254 instead.

Thanks emersion!

Signed-off-by: Emmanuel Gil Peyrot 
---
 drivers/gpu/drm/tegra/dc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 6e78416e64b0..e9a416fb4db7 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -838,7 +838,7 @@ static struct drm_plane *tegra_primary_plane_create(struct 
drm_device *drm,
}
 
drm_plane_helper_add(>base, _plane_helper_funcs);
-   drm_plane_create_zpos_property(>base, plane->index, 0, 255);
+   drm_plane_create_zpos_property(>base, plane->index, 0, 254);
 
err = drm_plane_create_rotation_property(>base,
 DRM_MODE_ROTATE_0,
@@ -1292,7 +1292,7 @@ static struct drm_plane 
*tegra_dc_overlay_plane_create(struct drm_device *drm,
}
 
drm_plane_helper_add(>base, _plane_helper_funcs);
-   drm_plane_create_zpos_property(>base, plane->index, 0, 255);
+   drm_plane_create_zpos_property(>base, plane->index, 0, 254);
 
err = drm_plane_create_rotation_property(>base,
 DRM_MODE_ROTATE_0,
-- 
2.40.1

Re: [v4,02/13] fbdev: Add initializer macros for struct fb_ops

[Sui Jingfeng]

Hi,


we love your patch:


On 2023/5/24 17:21, Thomas Zimmermann wrote:

For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.

For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.

These macros can remove a lot boilerplate code from fbdev drivers.
The drivers are supposed to use the macro that is required for its
framebuffer. Each macro is split into smaller helpers, so that
drivers with non-standard callbacks can pick and customize callbacks
as needed. There are individual helper macros for read/write, mmap
and drawing.

Signed-off-by: Thomas Zimmermann 
---
  include/linux/fb.h | 112 +
  1 file changed, 112 insertions(+)

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 2cf8efcb9e32..731472a2bb62 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -538,9 +538,31 @@ extern ssize_t fb_io_read(struct fb_info *info, char 
__user *buf,
  extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf,
   size_t count, loff_t *ppos);
  
+/*

+ * Initializes struct fb_ops for framebuffers in I/O memory.
+ */
+
+#define __FB_DEFAULT_IO_OPS_RDWR \
+   .fb_read= fb_io_read, \
+   .fb_write   = fb_io_write
+
+#define __FB_DEFAULT_IO_OPS_DRAW \
+.fb_fillrect   = cfb_fillrect, \
+.fb_copyarea   = cfb_copyarea, \
+.fb_imageblit  = cfb_imageblit


Here,  it seems that your text editor replace the tap with space, but 
I'm OK.


I'm asking because I see other __FB__DEFAULT_* macro begin with tabs.


+#define __FB_DEFAULT_IO_OPS_MMAP \
+   .fb_mmap= NULL // default implementation
+
+#define FB_DEFAULT_IO_OPS \
+   __FB_DEFAULT_IO_OPS_RDWR, \
+   __FB_DEFAULT_IO_OPS_DRAW, \
+   __FB_DEFAULT_IO_OPS_MMAP
+
  /*
   * Drawing operations where framebuffer is in system RAM
   */
+
  extern void sys_fillrect(struct fb_info *info, const struct fb_fillrect 
*rect);
  extern void sys_copyarea(struct fb_info *info, const struct fb_copyarea 
*area);
  extern void sys_imageblit(struct fb_info *info, const struct fb_image *image);
@@ -549,6 +571,27 @@ extern ssize_t fb_sys_read(struct fb_info *info, char 
__user *buf,
  extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
  
+/*

+ * Initializes struct fb_ops for framebuffers in system memory.
+ */
+
+#define __FB_DEFAULT_SYS_OPS_RDWR \
+   .fb_read= fb_sys_read, \
+   .fb_write   = fb_sys_write
+
+#define __FB_DEFAULT_SYS_OPS_DRAW \
+.fb_fillrect   = sys_fillrect, \
+.fb_copyarea   = sys_copyarea, \
+.fb_imageblit  = sys_imageblit
+
+#define __FB_DEFAULT_SYS_OPS_MMAP \
+   .fb_mmap= NULL // default implementation
+
+#define FB_DEFAULT_SYS_OPS \
+   __FB_DEFAULT_SYS_OPS_RDWR, \
+   __FB_DEFAULT_SYS_OPS_DRAW, \
+   __FB_DEFAULT_SYS_OPS_MMAP
+
  /* drivers/video/fbmem.c */
  extern int register_framebuffer(struct fb_info *fb_info);
  extern void unregister_framebuffer(struct fb_info *fb_info);
@@ -604,6 +647,75 @@ extern void fb_deferred_io_cleanup(struct fb_info *info);
  extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
  
+/*

+ * Generate callbacks for deferred I/O
+ */
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range, __mode) \
+   static ssize_t __prefix ## _defio_read(struct fb_info *info, char 
__user *buf, \
+  size_t count, loff_t *ppos) \
+   { \
+   return fb_ ## __mode ## _read(info, buf, count, ppos); \
+   } \
+   static ssize_t __prefix ## _defio_write(struct fb_info *info, const 
char __user *buf, \
+   size_t count, loff_t *ppos) \
+   { \
+   unsigned long offset = *ppos; \
+   ssize_t ret = fb_ ## __mode ## _write(info, buf, count, ppos); \
+   if (ret > 0) \
+   __damage_range(info, offset, ret); \
+   return ret; \
+   }
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area, __mode) \
+   static void __prefix ## _defio_fillrect(struct fb_info *info, \
+   const struct fb_fillrect *rect) 
\
+   { \
+   __mode ## _fillrect(info, rect); \
+   __damage_area(info, rect->dx, rect->dy, rect->width, 
rect->height); \
+   } \
+   static void __prefix ## _defio_copyarea(struct fb_info *info, \
+   const struct fb_copyarea *area) 
\
+   { \
+   __mode ## _copyarea(info, area); \
+   __damage_area(info, area->dx, area->dy, area->width, 
area->height); \
+ 

Re: [v4, 01/13] fbdev: Add Kconfig options to select different fb_ops helpers

[Sui Jingfeng]

Reviewed-by: Sui Jingfeng 


On 2023/5/24 17:21, Thomas Zimmermann wrote:

Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.

v3:
* fix select statement (Jingfeng)

Signed-off-by: Thomas Zimmermann 
---
  drivers/video/fbdev/Kconfig | 21 +
  1 file changed, 21 insertions(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e8889035c882..6df9bd09454a 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -158,6 +158,27 @@ config FB_DEFERRED_IO
bool
depends on FB
  
+config FB_IO_HELPERS

+   bool
+   depends on FB
+   select FB_CFB_COPYAREA
+   select FB_CFB_FILLRECT
+   select FB_CFB_IMAGEBLIT
+
+config FB_SYS_HELPERS
+   bool
+   depends on FB
+   select FB_SYS_COPYAREA
+   select FB_SYS_FILLRECT
+   select FB_SYS_FOPS
+   select FB_SYS_IMAGEBLIT
+
+config FB_SYS_HELPERS_DEFERRED
+   bool
+   depends on FB
+   select FB_DEFERRED_IO
+   select FB_SYS_HELPERS
+
  config FB_HECUBA
tristate
depends on FB

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Hamza Mahfooz]

+ Kees

On 5/24/23 15:50, Alex Deucher wrote:

On Wed, May 24, 2023 at 3:46 PM Felix Kuehling  wrote:


Sure, I think we tried enabling warnings as errors before and had to
revert it because of weird compiler quirks or the variety of compiler
versions that need to be supported.

Alex, are you planning to upstream this, or is this only to enforce more
internal discipline about not ignoring warnings?


I'd like to upstream it.  Upstream already has CONFIG_WERROR as a
config option, but it's been problematic to enable in CI because of
various breakages outside of the driver and in different compilers.
That said, I don't know how much trouble enabling it will cause with
various compilers in the wild.

Alex



Regards,
Felix


On 2023-05-24 15:41, Russell, Kent wrote:


[AMD Official Use Only - General]


(Adding Felix in CC)

I’m a fan of adding it to KFD as well. Felix, can you foresee any
issues here?

Kent

*From:* amd-gfx  *On Behalf Of
*Ho, Kenny
*Sent:* Wednesday, May 24, 2023 3:23 PM
*To:* Alex Deucher ; Mahfooz, Hamza

*Cc:* Li, Sun peng (Leo) ; Wentland, Harry
; Pan, Xinhui ; Siqueira,
Rodrigo ; linux-ker...@vger.kernel.org;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel
Vetter ; Deucher, Alexander
; David Airlie ; Koenig,
Christian 
*Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
checks

[AMD Official Use Only - General]

[AMD Official Use Only - General]

(+ Felix)

Should we do the same for other modules under amd (amdkfd)?  I was
going to enable full kernel werror in the kconfig used by my CI but
this is probably better.

Kenny



*From:*Alex Deucher 
*Sent:* Wednesday, May 24, 2023 3:22 PM
*To:* Mahfooz, Hamza 
*Cc:* amd-...@lists.freedesktop.org ;
Li, Sun peng (Leo) ; Ho, Kenny ;
Pan, Xinhui ; Siqueira, Rodrigo
; linux-ker...@vger.kernel.org
; dri-devel@lists.freedesktop.org
; Daniel Vetter ;
Deucher, Alexander ; David Airlie
; Wentland, Harry ; Koenig,
Christian 
*Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
checks

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz 
wrote:


Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should consider all
warnings to be compile errors, since the community will eventually end
up complaining about them. So, enable -Werror, -Wunused and
-Wmisleading-indentation for all kernel builds.

Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Kenny Ho 
Signed-off-by: Hamza Mahfooz 
---
v2: fix grammatical error
---
  drivers/gpu/drm/amd/display/Makefile | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/Makefile

b/drivers/gpu/drm/amd/display/Makefile

index 0d610cb376bb..3c44162ebe21 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,6 +26,8 @@

  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)

+subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
+


Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 

Alex


  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
--
2.40.1




--
Hamza

Re: [v4,12/13] drm/fbdev-generic: Implement dedicated fbdev I/O helpers

[Sui Jingfeng]

Tested-by: Sui Jingfeng 


This version works fine, I have tested it On LoongArch with 
drm/loongson(v14) as it is most handy for me.


Also because it using fbdev-generic. fbdev of IGT report no error. Then 
I run fbtest from geert[1],



Before apply your patch:


Benchmarking... 10x10 squares: 468.39 Mpixels/s
Benchmarking... 20x20 squares: 985.02 Mpixels/s
Benchmarking... 50x50 squares: 2247.22 Mpixels/s
Benchmarking... 100x100 squares: 2242.30 Mpixels/s
Benchmarking... 200x200 squares: 2883.18 Mpixels/s
Benchmarking... 500x500 squares: 3642.18 Mpixels/s
Benchmarking... 1000x1000 squares: 3992.77 Mpixels/s
Benchmarking... R5 circles: 261.90 Mpixels/s
Benchmarking... R10 circles: 596.27 Mpixels/s
Benchmarking... R25 circles: 1513.96 Mpixels/s
Benchmarking... R50 circles: 1965.07 Mpixels/s
Benchmarking... R100 circles: 2470.75 Mpixels/s
Benchmarking... R250 circles: 3288.00 Mpixels/s
Benchmarking... R500 circles: 3705.66 Mpixels/s


After apply your patch:


Benchmarking... 10x10 squares: 477.04 Mpixels/s
Benchmarking... 20x20 squares: 1021.07 Mpixels/s
Benchmarking... 50x50 squares: 2315.70 Mpixels/s
Benchmarking... 100x100 squares: 2267.69 Mpixels/s
Benchmarking... 200x200 squares: 3006.28 Mpixels/s
Benchmarking... 500x500 squares: 3761.44 Mpixels/s
Benchmarking... 1000x1000 squares: 4112.49 Mpixels/s
Benchmarking... R5 circles: 269.19 Mpixels/s
Benchmarking... R10 circles: 620.77 Mpixels/s
Benchmarking... R25 circles: 1559.02 Mpixels/s
Benchmarking... R50 circles: 2027.36 Mpixels/s
Benchmarking... R100 circles: 2574.42 Mpixels/s
Benchmarking... R250 circles: 3363.28 Mpixels/s
Benchmarking... R500 circles: 3815.51 Mpixels/s


It seems that this bring a little bit performance gain.

Directly operate on video RAM is slower than have a shadow in system RAM.

I also test this patch in intel i3-8100 @ 3.6Ghz, the results show that 
i915 is a bit slower.


Because it operate directly on device memory.


[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git


On 2023/5/24 17:21, Thomas Zimmermann wrote:

Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.

v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_SYS_HELPERS_DEFERRED option

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/Kconfig |   6 +-
  drivers/gpu/drm/drm_fb_helper.c | 107 
  drivers/gpu/drm/drm_fbdev_generic.c |  11 ++-
  include/drm/drm_fb_helper.h |  41 ---
  4 files changed, 6 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
  config DRM_KMS_HELPER
tristate
depends on DRM
+   select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
help
  CRTC helpers for KMS drivers.
  
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION

select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-   select FB_DEFERRED_IO
-   select FB_SYS_FOPS
-   select FB_SYS_FILLRECT
-   select FB_SYS_COPYAREA
-   select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cb03099fd2e3..bab6b252f02a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
-/**

- * drm_fb_helper_sys_read - Implements struct _ops.fb_read for system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
-  size_t count, loff_t *ppos)
-{
-   return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct _ops.fb_write for system 
memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
-  

Re: [v2 0/4] Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel

[Conor Dooley]

On Wed, May 24, 2023 at 03:28:12PM +0800, Cong Yang wrote:
> Compare V1:Add compatible for Starry himax83102-j02 and Starry-ili9882t
> in dt-bindings.

BTW, my mailer doesn't like how you threaded these patches, I guess you
sent them as a reply to something I was not CCed on.

>   dt-bindings: display: panel: Add compatible for Starry himax83102-j02
>   dt-bindings: display: panel: Add compatible for Starry ili9882t

These two are
Acked-by: Conor Dooley 

Thanks,
Conor.


signature.asc
Description: PGP signature

[PATCH v12 1/1] drm/i915: Allow user to set cache at BO creation

[fei . yang]

From: Fei Yang 

To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.

BSpec: 45101

Test igt@gem_create@create_ext_set_pat posted at
https://patchwork.freedesktop.org/series/118314/

Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878

Signed-off-by: Fei Yang 
Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Andi Shyti 
Reviewed-by: Andi Shyti 
Acked-by: Jordan Justen 
Tested-by: Jordan Justen 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 41 ++
 3 files changed, 83 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb7..644a936248ad 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   unsigned int pat_index;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+   struct create_ext *ext_data = data;
+   struct drm_i915_private *i915 = ext_data->i915;
+   struct drm_i915_gem_create_ext_set_pat ext;
+   unsigned int max_pat_index;
+
+   BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+   if (copy_from_user(, base, sizeof(ext)))
+   return -EFAULT;
+
+   max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+   if (ext.pat_index > max_pat_index) {
+   drm_dbg(>drm, "PAT index is invalid: %u\n",
+   ext.pat_index);
+   return -EINVAL;
+   }
+
+   ext_data->pat_index = ext.pat_index;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
 };
 
+#define PAT_INDEX_NOT_SET  0x
 /**
  * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle to 
it.
  * @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
+   ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
   create_extensions,
   ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
 
+   if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+   i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+   /* Mark pat_index is set by UMD */
+   obj->pat_set_by_user = true;
+   }
+
return i915_gem_publish(obj, file, >size, >handle);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 46a19b099ec8..97ac6fb37958 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -208,6 +208,12 @@ bool i915_gem_object_can_bypass_llc(struct 
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
 
+   /*
+* Always flush cache for UMD objects at creation time.
+*/
+   if (obj->pat_set_by_user)
+   return true;
+
/*
 * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
 * possible for userspace to bypass the GTT caching bits set by the
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f31dfacde601..4083a23e0614 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3679,9 +3679,13 @@ struct drm_i915_gem_create_ext {
 *
 * 

[PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

[fei . yang]

From: Fei Yang 

This series introduce a new extension for GEM_CREATE,
1. end support for set caching ioctl [PATCH 1/2]
2. add set_pat extension for gem_create [PATCH 2/2]

v2: drop one patch that was merged separately
commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
v3: rebased on https://patchwork.freedesktop.org/series/117082/
v4: fix missing unlock introduced in v3, and
solve a rebase conflict
v5: replace obj->cache_level with pat_set_by_user,
fix i915_cache_level_str() for legacy platforms.
v6: rebased on https://patchwork.freedesktop.org/series/117480/
v7: rebased on https://patchwork.freedesktop.org/series/117528/
v8: dropped the two dependent patches that has been merged
separately. Add IGT link and Tested-by (MESA).
v9: addressing comments (Andi)
v10: acked-by and tested-by MESA
v11: drop "end support for set caching ioctl" (merged)
 remove tools/include/uapi/drm/i915_drm.h
v12: drop Bspec reference in comment. add to commit message instead

Fei Yang (1):
  drm/i915: Allow user to set cache at BO creation

 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 41 ++
 3 files changed, 83 insertions(+)

-- 
2.25.1

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Hamza Mahfooz]

On 5/24/23 15:54, Harry Wentland wrote:



On 5/24/23 15:27, Hamza Mahfooz wrote:

On 5/24/23 15:22, Alex Deucher wrote:

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  wrote:


Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should consider all
warnings to be compile errors, since the community will eventually end
up complaining about them. So, enable -Werror, -Wunused and
-Wmisleading-indentation for all kernel builds.

Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Kenny Ho 
Signed-off-by: Hamza Mahfooz 
---
v2: fix grammatical error
---
   drivers/gpu/drm/amd/display/Makefile | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index 0d610cb376bb..3c44162ebe21 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,6 +26,8 @@

   AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)

+subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
+


Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 


As far as I can tell, if `CONFIG_DRM_AMD_DC` is set it will run these
checks on at least the base driver code.



It's probable best to put that into amdgpu/Makefile in that case.


I tried the following, but it doesn't seem to work:

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile

index 74a9aa6fe18c..d97bde0796dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -39,6 +39,8 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_DISPLAY_PATH)/amdgpu_dm \
-I$(FULL_AMD_PATH)/amdkfd

+ccflags-y += -Werror -Wunused -Wmisleading-indentation
+
 amdgpu-y := amdgpu_drv.o

 # add KMS driver



Harry



Alex


   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
--
2.40.1




--
Hamza

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Ho, Kenny]

[AMD Official Use Only - General]

I ran some experiment yesterday to turn on CONFIG_WERROR and here are some 
results (summary: gcc 12 seems ok but gcc 13 gives a lot more error, but not 
necessarily in our module.)

Build with gcc13 using Fedora 38:
http://zuul.linux.amd.com/t/osg/build/722ad77affed4f988d72051a84979e9f/log/job-output.txt#2924

Build with gcc12 using Fedora 37:
http://zuul.linux.amd.com/t/osg/build/9e90f08bbeb044a2997a41b6cdc13f29/log/job-output.txt#7534

Kenny


From: Alex Deucher 
Sent: Wednesday, May 24, 2023 3:50 PM
To: Kuehling, Felix 
Cc: Russell, Kent ; Ho, Kenny ; 
Mahfooz, Hamza ; Li, Sun peng (Leo) 
; Wentland, Harry ; Pan, Xinhui 
; Siqueira, Rodrigo ; 
linux-ker...@vger.kernel.org ; 
dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org ; Daniel Vetter 
; Deucher, Alexander ; David Airlie 
; Koenig, Christian 
Subject: Re: [PATCH v2] drm/amd/display: enable more strict compile checks

On Wed, May 24, 2023 at 3:46 PM Felix Kuehling  wrote:
>
> Sure, I think we tried enabling warnings as errors before and had to
> revert it because of weird compiler quirks or the variety of compiler
> versions that need to be supported.
>
> Alex, are you planning to upstream this, or is this only to enforce more
> internal discipline about not ignoring warnings?

I'd like to upstream it.  Upstream already has CONFIG_WERROR as a
config option, but it's been problematic to enable in CI because of
various breakages outside of the driver and in different compilers.
That said, I don't know how much trouble enabling it will cause with
various compilers in the wild.

Alex

>
> Regards,
>Felix
>
>
> On 2023-05-24 15:41, Russell, Kent wrote:
> >
> > [AMD Official Use Only - General]
> >
> >
> > (Adding Felix in CC)
> >
> > I’m a fan of adding it to KFD as well. Felix, can you foresee any
> > issues here?
> >
> > Kent
> >
> > *From:* amd-gfx  *On Behalf Of
> > *Ho, Kenny
> > *Sent:* Wednesday, May 24, 2023 3:23 PM
> > *To:* Alex Deucher ; Mahfooz, Hamza
> > 
> > *Cc:* Li, Sun peng (Leo) ; Wentland, Harry
> > ; Pan, Xinhui ; Siqueira,
> > Rodrigo ; linux-ker...@vger.kernel.org;
> > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel
> > Vetter ; Deucher, Alexander
> > ; David Airlie ; Koenig,
> > Christian 
> > *Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
> > checks
> >
> > [AMD Official Use Only - General]
> >
> > [AMD Official Use Only - General]
> >
> > (+ Felix)
> >
> > Should we do the same for other modules under amd (amdkfd)?  I was
> > going to enable full kernel werror in the kconfig used by my CI but
> > this is probably better.
> >
> > Kenny
> >
> > 
> >
> > *From:*Alex Deucher 
> > *Sent:* Wednesday, May 24, 2023 3:22 PM
> > *To:* Mahfooz, Hamza 
> > *Cc:* amd-...@lists.freedesktop.org ;
> > Li, Sun peng (Leo) ; Ho, Kenny ;
> > Pan, Xinhui ; Siqueira, Rodrigo
> > ; linux-ker...@vger.kernel.org
> > ; dri-devel@lists.freedesktop.org
> > ; Daniel Vetter ;
> > Deucher, Alexander ; David Airlie
> > ; Wentland, Harry ; Koenig,
> > Christian 
> > *Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
> > checks
> >
> > On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz 
> > wrote:
> > >
> > > Currently, there are quite a number of issues that are quite easy for
> > > the CI to catch, that slip through the cracks. Among them, there are
> > > unused variable and indentation issues. Also, we should consider all
> > > warnings to be compile errors, since the community will eventually end
> > > up complaining about them. So, enable -Werror, -Wunused and
> > > -Wmisleading-indentation for all kernel builds.
> > >
> > > Cc: Alex Deucher 
> > > Cc: Harry Wentland 
> > > Cc: Kenny Ho 
> > > Signed-off-by: Hamza Mahfooz 
> > > ---
> > > v2: fix grammatical error
> > > ---
> > >  drivers/gpu/drm/amd/display/Makefile | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/Makefile
> > b/drivers/gpu/drm/amd/display/Makefile
> > > index 0d610cb376bb..3c44162ebe21 100644
> > > --- a/drivers/gpu/drm/amd/display/Makefile
> > > +++ b/drivers/gpu/drm/amd/display/Makefile
> > > @@ -26,6 +26,8 @@
> > >
> > >  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
> > >
> > > +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> > > +
> >
> > Care to enable this for the rest of amdgpu as well?  Or send out an
> > additional patch to do that?  Either way:
> > Reviewed-by: Alex Deucher 
> >
> > Alex
> >
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> > > --
> > > 2.40.1
> > >
> >

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Harry Wentland]

On 5/24/23 15:27, Hamza Mahfooz wrote:
> On 5/24/23 15:22, Alex Deucher wrote:
>> On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  wrote:
>>>
>>> Currently, there are quite a number of issues that are quite easy for
>>> the CI to catch, that slip through the cracks. Among them, there are
>>> unused variable and indentation issues. Also, we should consider all
>>> warnings to be compile errors, since the community will eventually end
>>> up complaining about them. So, enable -Werror, -Wunused and
>>> -Wmisleading-indentation for all kernel builds.
>>>
>>> Cc: Alex Deucher 
>>> Cc: Harry Wentland 
>>> Cc: Kenny Ho 
>>> Signed-off-by: Hamza Mahfooz 
>>> ---
>>> v2: fix grammatical error
>>> ---
>>>   drivers/gpu/drm/amd/display/Makefile | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/Makefile 
>>> b/drivers/gpu/drm/amd/display/Makefile
>>> index 0d610cb376bb..3c44162ebe21 100644
>>> --- a/drivers/gpu/drm/amd/display/Makefile
>>> +++ b/drivers/gpu/drm/amd/display/Makefile
>>> @@ -26,6 +26,8 @@
>>>
>>>   AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
>>>
>>> +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
>>> +
>>
>> Care to enable this for the rest of amdgpu as well?  Or send out an
>> additional patch to do that?  Either way:
>> Reviewed-by: Alex Deucher 
> 
> As far as I can tell, if `CONFIG_DRM_AMD_DC` is set it will run these
> checks on at least the base driver code.
> 

It's probable best to put that into amdgpu/Makefile in that case.

Harry

>>
>> Alex
>>
>>>   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
>>>   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
>>>   subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
>>> -- 
>>> 2.40.1
>>>

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

On 3/17/23 09:53, Joshua Ashton wrote:
> 
> 
> On 3/17/23 13:35, Pekka Paalanen wrote:
>> On Fri, 17 Mar 2023 14:50:40 +0200
>> Ville Syrjälä  wrote:
>>
>>> On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
 On Fri, 17 Mar 2023 01:01:38 +0200
 Ville Syrjälä  wrote:
   
> On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
>> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
>>  wrote:
>>>
>>> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
 On Thu, 16 Mar 2023 12:47:51 +0200
 Ville Syrjälä  wrote:
    
> On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
>> On Thu, 16 Mar 2023 11:50:27 +0200
>> Ville Syrjälä  wrote:
>>    
>>> On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
 On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland 
  wrote:
>
> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.

 About that... The documentation says that user space has to check 
 the
 EDID for what the sink actually supports. So whatever is in
 supported_colorspaces is just what the driver/hardware is able to 
 set
 but doesn't actually indicate that the sink supports it.

 So the only way to enable bt2020 is by checking if the sink 
 supports
 both RGB and YUV variants because both could be used by the driver.
 Not great at all. Something to remember for the new property.
>>>
>>> Hmm. I wonder if that's even legal... Looks like maybe it
>>> is since I can't immediately spot anything in CTA-861 to
>>> forbid it :/
>>
>> Wouldn't the driver do the same EDID check before choosing whether it
>> uses RGB or YCbCr signalling?
>
> I suppose it could. The modeset would then fail, which is perhaps

 Could? What are they missing?
>>>
>>> The fact that the new property that also affects the rgb->ycbcr matrix
>>> doesn't even exist?
>>
>> I think the question was about the current Colorspace property.

 Yes.

 We need to be able to set ColourPrimaries infoframe field for the sink.
 Only userspace knows what ColourPrimaries it uses, and the driver has
 no need to care at all, other than tell the sink what we have.

 When a driver chooses to use YCbCr, it needs to use the
 MatrixCoefficients the sink expects.

 If we send the infoframe to the sink telling the signal uses BT.2020
 ColourPrimaries, does that same bit pattern also tell the sink we are
 using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?

 Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
>>>
>>> No. I think I've repeated this same line a thousand times already:
>>> The current colorspace property *only* affects the infoframe/msa/sdp,
>>> nothing else.
> 
> No, sorry, this is completely nonsensical.
> 
> Even with the current Colorspace property that we want to deprecate, drivers 
> doing an implicit conversion from RGB -> to YCC should respect the colorspace 
> property to pick the right matrix coefficients here.
> 
> Doing so simply introduces a useless mismatch that is unavoidable from 
> userspace and makes absolutely no sense.
> 
> Arguing about this is kind of completely useless anyway... as we are 
> deprecating this property... Let's plase let it die.
> 
> I am not sure why these patches were re-submitted with my RB again after we 
> had the discussion previously about making a new one that's actually going to 
> get tested and have userspace consumers.
> 

Apologies for that. I must've mis-read thins. Dropping them from the
next version of this set.

Based on the hackfest discussions I'll iterate on this with the hopes
to unblock the Colorspace property on AMD HW. A more thorough API will
require more work and rushing it would be unwise. In the meantime we
do really need something on AMD HW.

Harry

> (FTR, I guess Gamescope *is* a userspace consumer for this broken property 
> right now, but I am completely happy for AMDGPU upstream to never support 
> this and to just move onto the new property and leave this one behind).
> 
>>
>> That's the problem. I don't know what that means.
>>
>> Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
>> have been used?
> 
> Yes.
> 
>>
>> And the driver will never use BT.2020 NCL MatrixCoefficients in any
>> circumstances?
> 
> That is what Ville is describing and what I disagree with, yes.
> 
> But whether or not Ville or I agree on that is kind of irrelevant as we are 
> going to deprecate the property... right... right?
> 
>>
>> See the conflict? 

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Alex Deucher]

On Wed, May 24, 2023 at 3:46 PM Felix Kuehling  wrote:
>
> Sure, I think we tried enabling warnings as errors before and had to
> revert it because of weird compiler quirks or the variety of compiler
> versions that need to be supported.
>
> Alex, are you planning to upstream this, or is this only to enforce more
> internal discipline about not ignoring warnings?

I'd like to upstream it.  Upstream already has CONFIG_WERROR as a
config option, but it's been problematic to enable in CI because of
various breakages outside of the driver and in different compilers.
That said, I don't know how much trouble enabling it will cause with
various compilers in the wild.

Alex

>
> Regards,
>Felix
>
>
> On 2023-05-24 15:41, Russell, Kent wrote:
> >
> > [AMD Official Use Only - General]
> >
> >
> > (Adding Felix in CC)
> >
> > I’m a fan of adding it to KFD as well. Felix, can you foresee any
> > issues here?
> >
> > Kent
> >
> > *From:* amd-gfx  *On Behalf Of
> > *Ho, Kenny
> > *Sent:* Wednesday, May 24, 2023 3:23 PM
> > *To:* Alex Deucher ; Mahfooz, Hamza
> > 
> > *Cc:* Li, Sun peng (Leo) ; Wentland, Harry
> > ; Pan, Xinhui ; Siqueira,
> > Rodrigo ; linux-ker...@vger.kernel.org;
> > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel
> > Vetter ; Deucher, Alexander
> > ; David Airlie ; Koenig,
> > Christian 
> > *Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
> > checks
> >
> > [AMD Official Use Only - General]
> >
> > [AMD Official Use Only - General]
> >
> > (+ Felix)
> >
> > Should we do the same for other modules under amd (amdkfd)?  I was
> > going to enable full kernel werror in the kconfig used by my CI but
> > this is probably better.
> >
> > Kenny
> >
> > 
> >
> > *From:*Alex Deucher 
> > *Sent:* Wednesday, May 24, 2023 3:22 PM
> > *To:* Mahfooz, Hamza 
> > *Cc:* amd-...@lists.freedesktop.org ;
> > Li, Sun peng (Leo) ; Ho, Kenny ;
> > Pan, Xinhui ; Siqueira, Rodrigo
> > ; linux-ker...@vger.kernel.org
> > ; dri-devel@lists.freedesktop.org
> > ; Daniel Vetter ;
> > Deucher, Alexander ; David Airlie
> > ; Wentland, Harry ; Koenig,
> > Christian 
> > *Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile
> > checks
> >
> > On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz 
> > wrote:
> > >
> > > Currently, there are quite a number of issues that are quite easy for
> > > the CI to catch, that slip through the cracks. Among them, there are
> > > unused variable and indentation issues. Also, we should consider all
> > > warnings to be compile errors, since the community will eventually end
> > > up complaining about them. So, enable -Werror, -Wunused and
> > > -Wmisleading-indentation for all kernel builds.
> > >
> > > Cc: Alex Deucher 
> > > Cc: Harry Wentland 
> > > Cc: Kenny Ho 
> > > Signed-off-by: Hamza Mahfooz 
> > > ---
> > > v2: fix grammatical error
> > > ---
> > >  drivers/gpu/drm/amd/display/Makefile | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/Makefile
> > b/drivers/gpu/drm/amd/display/Makefile
> > > index 0d610cb376bb..3c44162ebe21 100644
> > > --- a/drivers/gpu/drm/amd/display/Makefile
> > > +++ b/drivers/gpu/drm/amd/display/Makefile
> > > @@ -26,6 +26,8 @@
> > >
> > >  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
> > >
> > > +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> > > +
> >
> > Care to enable this for the rest of amdgpu as well?  Or send out an
> > additional patch to do that?  Either way:
> > Reviewed-by: Alex Deucher 
> >
> > Alex
> >
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
> > >  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> > > --
> > > 2.40.1
> > >
> >

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Felix Kuehling]

Sure, I think we tried enabling warnings as errors before and had to 
revert it because of weird compiler quirks or the variety of compiler 
versions that need to be supported.


Alex, are you planning to upstream this, or is this only to enforce more 
internal discipline about not ignoring warnings?


Regards,
  Felix


On 2023-05-24 15:41, Russell, Kent wrote:


[AMD Official Use Only - General]


(Adding Felix in CC)

I’m a fan of adding it to KFD as well. Felix, can you foresee any 
issues here?


Kent

*From:* amd-gfx  *On Behalf Of 
*Ho, Kenny

*Sent:* Wednesday, May 24, 2023 3:23 PM
*To:* Alex Deucher ; Mahfooz, Hamza 

*Cc:* Li, Sun peng (Leo) ; Wentland, Harry 
; Pan, Xinhui ; Siqueira, 
Rodrigo ; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel 
Vetter ; Deucher, Alexander 
; David Airlie ; Koenig, 
Christian 
*Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile 
checks


[AMD Official Use Only - General]

[AMD Official Use Only - General]

(+ Felix)

Should we do the same for other modules under amd (amdkfd)?  I was 
going to enable full kernel werror in the kconfig used by my CI but 
this is probably better.


Kenny



*From:*Alex Deucher 
*Sent:* Wednesday, May 24, 2023 3:22 PM
*To:* Mahfooz, Hamza 
*Cc:* amd-...@lists.freedesktop.org ; 
Li, Sun peng (Leo) ; Ho, Kenny ; 
Pan, Xinhui ; Siqueira, Rodrigo 
; linux-ker...@vger.kernel.org 
; dri-devel@lists.freedesktop.org 
; Daniel Vetter ; 
Deucher, Alexander ; David Airlie 
; Wentland, Harry ; Koenig, 
Christian 
*Subject:* Re: [PATCH v2] drm/amd/display: enable more strict compile 
checks


On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  
wrote:

>
> Currently, there are quite a number of issues that are quite easy for
> the CI to catch, that slip through the cracks. Among them, there are
> unused variable and indentation issues. Also, we should consider all
> warnings to be compile errors, since the community will eventually end
> up complaining about them. So, enable -Werror, -Wunused and
> -Wmisleading-indentation for all kernel builds.
>
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Kenny Ho 
> Signed-off-by: Hamza Mahfooz 
> ---
> v2: fix grammatical error
> ---
>  drivers/gpu/drm/amd/display/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile

> index 0d610cb376bb..3c44162ebe21 100644
> --- a/drivers/gpu/drm/amd/display/Makefile
> +++ b/drivers/gpu/drm/amd/display/Makefile
> @@ -26,6 +26,8 @@
>
>  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
>
> +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> +

Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 

Alex

>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> --
> 2.40.1
>

RE: [PATCH v2] drm/amd/display: enable more strict compile checks

[Russell, Kent]

[AMD Official Use Only - General]

(Adding Felix in CC)

I’m a fan of adding it to KFD as well. Felix, can you foresee any issues here?

Kent

From: amd-gfx  On Behalf Of Ho, Kenny
Sent: Wednesday, May 24, 2023 3:23 PM
To: Alex Deucher ; Mahfooz, Hamza 
Cc: Li, Sun peng (Leo) ; Wentland, Harry 
; Pan, Xinhui ; Siqueira, Rodrigo 
; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel Vetter 
; Deucher, Alexander ; David Airlie 
; Koenig, Christian 
Subject: Re: [PATCH v2] drm/amd/display: enable more strict compile checks


[AMD Official Use Only - General]


[AMD Official Use Only - General]

(+ Felix)

Should we do the same for other modules under amd (amdkfd)?  I was going to 
enable full kernel werror in the kconfig used by my CI but this is probably 
better.

Kenny

From: Alex Deucher mailto:alexdeuc...@gmail.com>>
Sent: Wednesday, May 24, 2023 3:22 PM
To: Mahfooz, Hamza mailto:hamza.mahf...@amd.com>>
Cc: amd-...@lists.freedesktop.org 
mailto:amd-...@lists.freedesktop.org>>; Li, Sun 
peng (Leo) mailto:sunpeng...@amd.com>>; Ho, Kenny 
mailto:kenny...@amd.com>>; Pan, Xinhui 
mailto:xinhui@amd.com>>; Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; 
linux-ker...@vger.kernel.org 
mailto:linux-ker...@vger.kernel.org>>; 
dri-devel@lists.freedesktop.org 
mailto:dri-devel@lists.freedesktop.org>>; 
Daniel Vetter mailto:dan...@ffwll.ch>>; Deucher, Alexander 
mailto:alexander.deuc...@amd.com>>; David Airlie 
mailto:airl...@gmail.com>>; Wentland, Harry 
mailto:harry.wentl...@amd.com>>; Koenig, Christian 
mailto:christian.koe...@amd.com>>
Subject: Re: [PATCH v2] drm/amd/display: enable more strict compile checks

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz 
mailto:hamza.mahf...@amd.com>> wrote:
>
> Currently, there are quite a number of issues that are quite easy for
> the CI to catch, that slip through the cracks. Among them, there are
> unused variable and indentation issues. Also, we should consider all
> warnings to be compile errors, since the community will eventually end
> up complaining about them. So, enable -Werror, -Wunused and
> -Wmisleading-indentation for all kernel builds.
>
> Cc: Alex Deucher mailto:alexander.deuc...@amd.com>>
> Cc: Harry Wentland mailto:harry.wentl...@amd.com>>
> Cc: Kenny Ho mailto:kenny...@amd.com>>
> Signed-off-by: Hamza Mahfooz 
> mailto:hamza.mahf...@amd.com>>
> ---
> v2: fix grammatical error
> ---
>  drivers/gpu/drm/amd/display/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/Makefile 
> b/drivers/gpu/drm/amd/display/Makefile
> index 0d610cb376bb..3c44162ebe21 100644
> --- a/drivers/gpu/drm/amd/display/Makefile
> +++ b/drivers/gpu/drm/amd/display/Makefile
> @@ -26,6 +26,8 @@
>
>  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
>
> +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> +

Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>

Alex

>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> --
> 2.40.1
>

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Hamza Mahfooz]

On 5/24/23 15:22, Alex Deucher wrote:

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  wrote:


Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should consider all
warnings to be compile errors, since the community will eventually end
up complaining about them. So, enable -Werror, -Wunused and
-Wmisleading-indentation for all kernel builds.

Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Kenny Ho 
Signed-off-by: Hamza Mahfooz 
---
v2: fix grammatical error
---
  drivers/gpu/drm/amd/display/Makefile | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index 0d610cb376bb..3c44162ebe21 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,6 +26,8 @@

  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)

+subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
+


Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 


As far as I can tell, if `CONFIG_DRM_AMD_DC` is set it will run these
checks on at least the base driver code.



Alex


  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
--
2.40.1


--
Hamza

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Ho, Kenny]

[AMD Official Use Only - General]

(+ Felix)

Should we do the same for other modules under amd (amdkfd)?  I was going to 
enable full kernel werror in the kconfig used by my CI but this is probably 
better.

Kenny

From: Alex Deucher 
Sent: Wednesday, May 24, 2023 3:22 PM
To: Mahfooz, Hamza 
Cc: amd-...@lists.freedesktop.org ; Li, Sun peng 
(Leo) ; Ho, Kenny ; Pan, Xinhui 
; Siqueira, Rodrigo ; 
linux-ker...@vger.kernel.org ; 
dri-devel@lists.freedesktop.org ; Daniel 
Vetter ; Deucher, Alexander ; David 
Airlie ; Wentland, Harry ; Koenig, 
Christian 
Subject: Re: [PATCH v2] drm/amd/display: enable more strict compile checks

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  wrote:
>
> Currently, there are quite a number of issues that are quite easy for
> the CI to catch, that slip through the cracks. Among them, there are
> unused variable and indentation issues. Also, we should consider all
> warnings to be compile errors, since the community will eventually end
> up complaining about them. So, enable -Werror, -Wunused and
> -Wmisleading-indentation for all kernel builds.
>
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Kenny Ho 
> Signed-off-by: Hamza Mahfooz 
> ---
> v2: fix grammatical error
> ---
>  drivers/gpu/drm/amd/display/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/Makefile 
> b/drivers/gpu/drm/amd/display/Makefile
> index 0d610cb376bb..3c44162ebe21 100644
> --- a/drivers/gpu/drm/amd/display/Makefile
> +++ b/drivers/gpu/drm/amd/display/Makefile
> @@ -26,6 +26,8 @@
>
>  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
>
> +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> +

Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 

Alex

>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> --
> 2.40.1
>

Re: [PATCH v2] drm/amd/display: enable more strict compile checks

[Alex Deucher]

On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz  wrote:
>
> Currently, there are quite a number of issues that are quite easy for
> the CI to catch, that slip through the cracks. Among them, there are
> unused variable and indentation issues. Also, we should consider all
> warnings to be compile errors, since the community will eventually end
> up complaining about them. So, enable -Werror, -Wunused and
> -Wmisleading-indentation for all kernel builds.
>
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Kenny Ho 
> Signed-off-by: Hamza Mahfooz 
> ---
> v2: fix grammatical error
> ---
>  drivers/gpu/drm/amd/display/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/Makefile 
> b/drivers/gpu/drm/amd/display/Makefile
> index 0d610cb376bb..3c44162ebe21 100644
> --- a/drivers/gpu/drm/amd/display/Makefile
> +++ b/drivers/gpu/drm/amd/display/Makefile
> @@ -26,6 +26,8 @@
>
>  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
>
> +subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
> +

Care to enable this for the rest of amdgpu as well?  Or send out an
additional patch to do that?  Either way:
Reviewed-by: Alex Deucher 

Alex

>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
>  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
> --
> 2.40.1
>

Re: [PATCH 1/2] dt-bindings: display: panel-simple: Add Ampire AM-800480L1TMQW-T00H

[Conor Dooley]

On Wed, May 24, 2023 at 02:32:10PM +0200, Geert Uytterhoeven wrote:
> Document support for the Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD
> panel.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Conor Dooley 

Thanks,
Conor.


signature.asc
Description: PGP signature

[PATCH v2] drm/amd/display: enable more strict compile checks

[Hamza Mahfooz]

Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should consider all
warnings to be compile errors, since the community will eventually end
up complaining about them. So, enable -Werror, -Wunused and
-Wmisleading-indentation for all kernel builds.

Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Kenny Ho 
Signed-off-by: Hamza Mahfooz 
---
v2: fix grammatical error
---
 drivers/gpu/drm/amd/display/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index 0d610cb376bb..3c44162ebe21 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,6 +26,8 @@
 
 AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
 
+subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
+
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
-- 
2.40.1

Re: [PATCH 1/2] drm/msm/dpu: drop SSPP register dumpers

[Abhinav Kumar]

On 5/24/2023 2:48 AM, Marijn Suijten wrote:

On 2023-05-23 13:01:13, Abhinav Kumar wrote:



On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote:

Drop SSPP-specifig debugfs register dumps in favour of using
debugfs/dri/0/kms or devcoredump.



I did see another series which removes src_blk from the catalog (I am
yet to review that one) . Lets assume that one is fine and this change
will be going on top of that one right?


It replaces src_blk with directly accessing the blk (non-sub-block)
directly, because they were overlapping anyway.


The concern I have with this change is that although I do agree that we
should be in favor of using debugfs/dri/0/kms ( i have used it a few
times and it works pretty well ), devcoredump does not have the support
to dump sub-blocks . Something which we should add with priority because
even with DSC blocks with the separation of enc/ctl blocks we need that
like I wrote in one of the responses.

So the "len" of the blocks having sub-blocks will be ignored in favor of
the len of the sub-blocks.


The sub-blocks are not always contiguous with their parent block, are
they?  It's probably better to print the sub-blocks separately with


Yes, not contiguous otherwise we could have just had them in one big range.


clear headers anyway rather than dumping the range parent_blk_base to
max(parent_blk_base+len, parent_blk_base+sblk_base+sblk_len...).

- Marijn


When I meant sub-block support to devcoredump, this is how I visualize 
them to be printed


=SSPP xxx ===
=SSPP_CSC ===(for SSPP_xxx)
=SSPP_QSEED =(for SSPP_xxx)
etc

OR for DSC

DSC_xxx ==
DSC_CTL == (for DSC_xxx)
DSC_ENC ===(for DSC_xxx)

This is clear enough headers.




If we remove this without adding that support first, its a loss of debug
functionality.

Can we retain these blocks and remove dpu_debugfs_create_regset32 in a
different way?

[PATCH] drm/amd/display: enable more strict compile checks

[Hamza Mahfooz]

Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there unused
variable and indentation issues. Also, we should consider all warnings
to be compile errors, since the community will eventually end up
complaining about them. So, enable -Werror, -Wunused and
-Wmisleading-indentation for all kernel builds.

Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Kenny Ho 
Signed-off-by: Hamza Mahfooz 
---
 drivers/gpu/drm/amd/display/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index 0d610cb376bb..3c44162ebe21 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,6 +26,8 @@
 
 AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
 
+subdir-ccflags-y += -Werror -Wunused -Wmisleading-indentation
+
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/clk_mgr
-- 
2.40.1

Re: [PATCH v14 3/9] drm/display/dsc: Add drm_dsc_get_bpp_int helper

[Marijn Suijten]

On 2023-05-24 10:45:16, Jessica Zhang wrote:
> Add helper to get the integer value of drm_dsc_config.bits_per_pixel
> 
> Reviewed-by: Marijn Suijten 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Jessica Zhang 

Nit: if there comes a v15, perhaps this can be squashed with patch 1/9?
I always thought they were separate because one extends the header while
this extends the C file... but now both extend the C file with helpers.

> ---
>  drivers/gpu/drm/display/drm_dsc_helper.c | 13 +
>  include/drm/display/drm_dsc_helper.h |  1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index b31fe9849784..4424380c6cb6 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -1436,6 +1436,19 @@ int drm_dsc_compute_rc_parameters(struct 
> drm_dsc_config *vdsc_cfg)
>  }
>  EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
>  
> +/**
> + * drm_dsc_get_bpp_int() - Get integer bits per pixel value for the given 
> DRM DSC config
> + * @vdsc_cfg: Pointer to DRM DSC config struct
> + *
> + * Return: Integer BPP value
> + */
> +u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg)
> +{
> + WARN_ON_ONCE(vdsc_cfg->bits_per_pixel & 0xf);

You did not add linux/bug.h back, presumably because Dmitry added
another use of WARN_ON_ONCE to this file in a previous series and it
compiles fine as the definition trickles in via another header?

- Marijn

> + return vdsc_cfg->bits_per_pixel >> 4;
> +}
> +EXPORT_SYMBOL(drm_dsc_get_bpp_int);
> +
>  /**
>   * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
> given DSC config
>   * @dsc: Pointer to DRM DSC config struct
> diff --git a/include/drm/display/drm_dsc_helper.h 
> b/include/drm/display/drm_dsc_helper.h
> index f4e18e5d077a..913aa2071232 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -27,6 +27,7 @@ int drm_dsc_setup_rc_params(struct drm_dsc_config 
> *vdsc_cfg, enum drm_dsc_params
>  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>  u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
>  u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
> +u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg);
>  
>  #endif /* _DRM_DSC_HELPER_H_ */
>  
> 
> -- 
> 2.40.1
> 

Re: [PATCH v14 0/9] Introduce MSM-specific DSC helpers

[Marijn Suijten]

On 2023-05-24 10:45:13, Jessica Zhang wrote:
> There are some overlap in calculations for MSM-specific DSC variables
> between DP and DSI. In addition, the calculations for initial_scale_value
> and det_thresh_flatness that are defined within the DSC 1.2 specifications,
> but aren't yet included in drm_dsc_helper.c.
> 
> This series moves these calculations to a shared msm_dsc_helper.c file and
> defines drm_dsc_helper methods for initial_scale_value and
> det_thresh_flatness.
> 
> Note: For now, the MSM specific helper methods are only called for the DSI
> path, but will called for DP once DSC 1.2 support for DP has been added.
> 
> Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1]
> 
> [1] https://patchwork.freedesktop.org/series/114472/
> 
> ---
> Changes in v14:
> - Added kernel docs and made DRM DSC helper functions (Jani)

They were already helper functions: I think you meant to write that you
have moved from from inlined header functions to exported symbols in the
.c file?

- Marijn

> - Link to v13: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v13-0-d7581e7be...@quicinc.com
> 
> Changes in v13:
> - Reworded comment doc for msm_dsc_get_slices_per_intf()
> - Changed intf_width to u32
> - msm_dsc_calculate_slices_per_intf -> msm_dsc_get_slices_per_intf
> - Link to v12: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v12-0-9cdb7401f...@quicinc.com
> 
> Changes in v12:
> - Reworded summary comment for msm_dsc_helper.h
> - msm_dsc_get_slices_per_intf -> msm_dsc_calculate_slices_per_intf
> - Corrected total_bytes_per_intf math in dsc_update_dsc_timing
> - Rebased on top of latest version of "drm/i915: move DSC RC tables to 
> drm_dsc_helper.c"
> - Link to v11: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v11-0-30270e1ee...@quicinc.com
> 
> Changes in v11:
> - Fixed mismatched return types
> - Moved MSM DSC helpers summary comment to under copyright
> - Moved msm_dsc_get_bpp_int() to drm_dsc_helper.h
> - Reworded MSM DSC helper comment docs for clarity
> - Added const keyword where applicable
> - Renamed msm_dsc_get_slice_per_intf to msm_dsc_get_slices_per_intf
> - Removed msm_dsc_get_slice_per_intf()
> - Reworded commit message for "drm/msm/dsi: update hdisplay calculation
>   for dsi_timing_setup"
> - Link to v10: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v10-0-4cb21168c...@quicinc.com
> 
> Changes in v10:
> - Removed msm_dsc_get_bytes_per_slice helper
> - Inlined msm_dsc_get_bytes_per_intf
> - Refactored drm_dsc_set_initial_scale_value() to be a pure function
> - Renamed DRM DSC initial_scale and flatness_det_thresh helpers
> - Removed msm_dsc_helpers.o from Makefile
> - Link to v9: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v9-0-87daeaec2...@quicinc.com
> 
> Changes in v9:
> - Fixed incorrect math for msm_dsc_get_bytes_per_line()
> - Link to v8: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v8-0-2c9b2bb12...@quicinc.com
> 
> Changes in v8:
> - *_bytes_per_soft_slice --> *_bytes_per_slice
> - Fixed comment doc formatting for MSM DSC helpers
> - Use slice_chunk_size in msm_dsc_get_bytes_per_line calculation
> - Reworded "drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness"
>   commit title for clarity
> - Picked up "Reviewed-by" tags
> - Added duplicate Signed-off-by tag to "drm/display/dsc: Add flatness
>   and initial scale value calculations" to reflect patch history
> - Link to v7: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v7-0-df48a2c54...@quicinc.com
> 
> Changes in v7:
> - Renamed msm_dsc_get_pclk_per_intf to msm_dsc_get_bytes_per_line
> - Removed duplicate msm_dsc_get_dce_bytes_per_line
> - Reworded commit message for "drm/msm/dpu: Use DRM DSC helper for
>   det_thresh_flatness"
> - Dropped slice_per_pkt change (it will be included in the later
>   "Add DSC v1.2 Support for DSI" series)
> - Picked up "drm/display/dsc: Add flatness and initial scale value
>   calculations" and "drm/display/dsc: add helper to set semi-const
>   parameters", which were dropped from "drm/i915: move DSC RC tables to
>   drm_dsc_helper.c" series
> - Picked up "Reviewed-by" tags
> - Removed changelog in individual patches
> - Link to v6: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v6-0-cb7f59f0f...@quicinc.com
> 
> Changes in v6:
> - Documented return values for MSM DSC helpers
> - Fixed dependency issue in msm_dsc_helper.c
> - Link to v5: 
> https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v5-0-0108401d7...@quicinc.com
> 
> Changes in v5:
> - Added extra line at end of msm_dsc_helper.h
> - Simplified msm_dsc_get_bytes_per_soft_slice() math
> - Simplified and inlined msm_dsc_get_pclk_per_intf() math
> - "Fix calculations pkt_per_line" --> "... Fix calculation for pkt_per_line"
> - Split dsc->slice_width check into a separate patch
> - Picked up Dmitry's msm/dsi patch ("drm/msm/dsi: use new helpers for
>   DSC setup")
> - Removed unused headers in MSM DSC helper files
> - Picked up Reviewed-by 

Re: [PATCH v14 1/9] drm/display/dsc: Add flatness and initial scale value calculations

[Marijn Suijten]

On 2023-05-24 10:45:14, Jessica Zhang wrote:
> Add helpers to calculate det_thresh_flatness and initial_scale_value as
> these calculations are defined within the DSC spec.
> 
> Reviewed-by: Marijn Suijten 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Jessica Zhang 
> ---
>  drivers/gpu/drm/display/drm_dsc_helper.c | 24 
>  include/drm/display/drm_dsc_helper.h |  2 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index fc187a8d8873..4efb6236d22c 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -1413,3 +1413,27 @@ int drm_dsc_compute_rc_parameters(struct 
> drm_dsc_config *vdsc_cfg)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
> +
> +/**
> + * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
> given DSC config
> + * @dsc: Pointer to DRM DSC config struct
> + *
> + * Return: Calculated initial scale value

Perhaps just drop Calculated from Return:?

> + */
> +u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc)
> +{
> + return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
> dsc->initial_offset);
> +}
> +EXPORT_SYMBOL(drm_dsc_initial_scale_value);
> +
> +/**
> + * drm_dsc_flatness_det_thresh() - Calculate the flatness_det_thresh for the 
> given DSC config

You've written out the word ("flatness det thresh" and "initial scale
value") entirely elsewhere, why the underscores in the doc comment here?

Instead we should have the full meaning here (and in the Return: below),
please correct me if I'm wrong but in VESA DSC v1.2a spec 6.8.5.1
Encoder Flatness Decision I think this variable means "flatness
determination threshold"?  If so, use that in the doc comment :)

(and drop the leading "the", so just "Calculate flatness determination
threshold for the given DSC config")

> + * @dsc: Pointer to DRM DSC config struct
> + *
> + * Return: Calculated flatness det thresh value

Nit: perhaps we can just drop "calculated" here?

- Marijn

> + */
> +u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc)
> +{
> + return 2 << (dsc->bits_per_component - 8);
> +}
> +EXPORT_SYMBOL(drm_dsc_flatness_det_thresh);
> diff --git a/include/drm/display/drm_dsc_helper.h 
> b/include/drm/display/drm_dsc_helper.h
> index fc2104415dcb..71789fb34e17 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -24,6 +24,8 @@ void drm_dsc_pps_payload_pack(struct 
> drm_dsc_picture_parameter_set *pps_sdp,
>  void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
>  int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
> drm_dsc_params_type type);
>  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
> +u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
> +u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
>  
>  #endif /* _DRM_DSC_HELPER_H_ */
>  
> 
> -- 
> 2.40.1
> 

Re: [PATCH] drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()

[Nick Desaulniers]

On Wed, May 24, 2023 at 11:41 AM Nathan Chancellor  wrote:
>
> On Wed, May 24, 2023 at 11:32:32AM -0700, Nick Desaulniers wrote:
> > On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor  wrote:
> > >
> > > Clang warns:
> > >
> > >   drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated 
> > > fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
> > >   case I915_FORMAT_MOD_X_TILED:
> > >   ^
> > >   drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 
> > > 'break;' to avoid fall-through
> > >   case I915_FORMAT_MOD_X_TILED:
> > >   ^
> > >   break;
> > >   1 error generated.
> > >
> > > Clang is a little more pedantic than GCC, which does not warn when
> > > falling through to a case that is just break or return. Clang's version
> > > is more in line with the kernel's own stance in deprecated.rst, which
> > > states that all switch/case blocks must end in either break,
> > > fallthrough, continue, goto, or return. Add the missing break to silence
> > > the warning.
> > >
> > > Fixes: 937859485aef ("drm/i915: Support Async Flip on Linear buffers")
> > > Reported-by: kernel test robot 
> > > Closes: https://lore.kernel.org/202305241902.uvhtmoxa-...@intel.com/
> > > Reported-by: Naresh Kamboju 
> > > Closes: 
> > > https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
> > > Signed-off-by: Nathan Chancellor 
> >
> > Thanks for the patch! I've never seen the closes tag before, that's
> > new to me. Can you tell me more about it?
>
> It is new to me (at least in the context of the kernel) as well. I only
> used it over Link: because checkpatch.pl told me to:
>
> WARNING: Reported-by: should be immediately followed by Closes: with a URL to 
> the report
> #26:
> Reported-by: kernel test robot 
> Reported-by: Naresh Kamboju 
>
> WARNING: Reported-by: should be immediately followed by Closes: with a URL to 
> the report
> #27:
> Reported-by: Naresh Kamboju 
> Signed-off-by: Nathan Chancellor 
>
> It was Link: for a bit but commit 44c31888098a ("checkpatch: allow
> Closes tags with links") changed it to Closes:. Looks odd to me but
> whatever the linter says I suppose.
>
> Thanks for the review!
>
> Cheers,
> Nathan
>
> > A few more tags
> >
> > Reported-by: Tom Rix 
> > Link: https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
> > Reviewed-by: Nick Desaulniers 

Ah then I guess my link tag should have been

Closes: https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/

I hope the author of
commit 44c31888098a ("checkpatch: allow Closes tags with links")
has coordinated with the maintainer of b4, so that b4 recognizes Closes tags.
b4 v0.12.2 does not pick up Closes tags.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] drm/amdgpu: Fix return types of certain NBIOv7.9 callbacks

[Alex Deucher]

Applied.  Thanks!

On Wed, May 24, 2023 at 12:44 PM Nathan Chancellor  wrote:
>
> When building with clang's -Wincompatible-function-pointer-types-strict,
> which ensures that function pointer signatures match exactly to avoid
> tripping clang's Control Flow Integrity (kCFI) checks at run time and
> will eventually be turned on for the kernel, the following instances
> appear in the NBIOv7.9 code:
>
>   drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c:465:32: error: incompatible function 
> pointer types initializing 'int (*)(struct amdgpu_device *)' with an 
> expression of type 'enum amdgpu_gfx_partition (struct amdgpu_device *)' 
> [-Werror,-Wincompatible-function-pointer-types-strict]
>   .get_compute_partition_mode = nbio_v7_9_get_compute_partition_mode,
> ^~~~
>   drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c:467:31: error: incompatible function 
> pointer types initializing 'u32 (*)(struct amdgpu_device *, u32 *)' (aka 
> 'unsigned int (*)(struct amdgpu_device *, unsigned int *)') with an 
> expression of type 'enum amdgpu_memory_partition (struct amdgpu_device *, u32 
> *)' (aka 'enum amdgpu_memory_partition (struct amdgpu_device *, unsigned int 
> *)') [-Werror,-Wincompatible-function-pointer-types-strict]
>   .get_memory_partition_mode = nbio_v7_9_get_memory_partition_mode,
>^~~
>   2 errors generated.
>
> Change the return types of these callbacks to match the prototypes to
> clear up the warning and avoid tripping kCFI at run time. Both functions
> return a value from ffs(), which is an integer that can fit into either
> int or unsigned int.
>
> Fixes: 11f64eb1472f ("drm/amdgpu: add sysfs node for compute partition mode")
> Fixes: 41a717ea8afc ("drm/amdgpu: detect current GPU memory partition mode")
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c 
> b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
> index e082f6343d20..d19325476752 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
> @@ -382,7 +382,7 @@ static void nbio_v7_9_enable_doorbell_interrupt(struct 
> amdgpu_device *adev,
>   DOORBELL_INTERRUPT_DISABLE, enable ? 0 : 1);
>  }
>
> -static enum amdgpu_gfx_partition nbio_v7_9_get_compute_partition_mode(struct 
> amdgpu_device *adev)
> +static int nbio_v7_9_get_compute_partition_mode(struct amdgpu_device *adev)
>  {
> u32 tmp, px;
>
> @@ -408,8 +408,8 @@ static void nbio_v7_9_set_compute_partition_mode(struct 
> amdgpu_device *adev,
> WREG32_SOC15(NBIO, 0, regBIF_BX_PF0_PARTITION_COMPUTE_STATUS, tmp);
>  }
>
> -static enum amdgpu_memory_partition
> -nbio_v7_9_get_memory_partition_mode(struct amdgpu_device *adev, u32 
> *supp_modes)
> +static u32 nbio_v7_9_get_memory_partition_mode(struct amdgpu_device *adev,
> +  u32 *supp_modes)
>  {
> u32 tmp;
>
>
> ---
> base-commit: fd8f7bb391fa9c1979232cb5ab5bedb08abc855d
> change-id: 
> 20230524-nbio_v7_9-wincompatible-function-pointer-types-strict-c894636ce146
>
> Best regards,
> --
> Nathan Chancellor 
>

Re: [PATCH] drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()

[Nathan Chancellor]

On Wed, May 24, 2023 at 11:32:32AM -0700, Nick Desaulniers wrote:
> On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor  wrote:
> >
> > Clang warns:
> >
> >   drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated 
> > fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
> >   case I915_FORMAT_MOD_X_TILED:
> >   ^
> >   drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 
> > 'break;' to avoid fall-through
> >   case I915_FORMAT_MOD_X_TILED:
> >   ^
> >   break;
> >   1 error generated.
> >
> > Clang is a little more pedantic than GCC, which does not warn when
> > falling through to a case that is just break or return. Clang's version
> > is more in line with the kernel's own stance in deprecated.rst, which
> > states that all switch/case blocks must end in either break,
> > fallthrough, continue, goto, or return. Add the missing break to silence
> > the warning.
> >
> > Fixes: 937859485aef ("drm/i915: Support Async Flip on Linear buffers")
> > Reported-by: kernel test robot 
> > Closes: https://lore.kernel.org/202305241902.uvhtmoxa-...@intel.com/
> > Reported-by: Naresh Kamboju 
> > Closes: 
> > https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
> > Signed-off-by: Nathan Chancellor 
> 
> Thanks for the patch! I've never seen the closes tag before, that's
> new to me. Can you tell me more about it?

It is new to me (at least in the context of the kernel) as well. I only
used it over Link: because checkpatch.pl told me to:

WARNING: Reported-by: should be immediately followed by Closes: with a URL to 
the report
#26:
Reported-by: kernel test robot 
Reported-by: Naresh Kamboju 

WARNING: Reported-by: should be immediately followed by Closes: with a URL to 
the report
#27:
Reported-by: Naresh Kamboju 
Signed-off-by: Nathan Chancellor 

It was Link: for a bit but commit 44c31888098a ("checkpatch: allow
Closes tags with links") changed it to Closes:. Looks odd to me but
whatever the linter says I suppose.

Thanks for the review!

Cheers,
Nathan

> A few more tags
> 
> Reported-by: Tom Rix 
> Link: https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
> Reviewed-by: Nick Desaulniers 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0490c6412ab5..6d49e0ab3e85 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6008,6 +6008,7 @@ static int intel_async_flip_check_hw(struct 
> > intel_atomic_state *state, struct in
> > plane->base.base.id, 
> > plane->base.name);
> > return -EINVAL;
> > }
> > +   break;
> >
> > case I915_FORMAT_MOD_X_TILED:
> > case I915_FORMAT_MOD_Y_TILED:
> >
> > ---
> > base-commit: 9a2cb1b31c040e2f1b313e2f7921f0f5e6b66d82
> > change-id: 
> > 20230524-intel_async_flip_check_hw-implicit-fallthrough-c4c40b03802f
> >
> > Best regards,
> > --
> > Nathan Chancellor 
> >
> 
> 
> -- 
> Thanks,
> ~Nick Desaulniers

Re: [PATCH] drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()

[Nick Desaulniers]

On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor  wrote:
>
> Clang warns:
>
>   drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated 
> fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
>   case I915_FORMAT_MOD_X_TILED:
>   ^
>   drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 'break;' 
> to avoid fall-through
>   case I915_FORMAT_MOD_X_TILED:
>   ^
>   break;
>   1 error generated.
>
> Clang is a little more pedantic than GCC, which does not warn when
> falling through to a case that is just break or return. Clang's version
> is more in line with the kernel's own stance in deprecated.rst, which
> states that all switch/case blocks must end in either break,
> fallthrough, continue, goto, or return. Add the missing break to silence
> the warning.
>
> Fixes: 937859485aef ("drm/i915: Support Async Flip on Linear buffers")
> Reported-by: kernel test robot 
> Closes: https://lore.kernel.org/202305241902.uvhtmoxa-...@intel.com/
> Reported-by: Naresh Kamboju 
> Closes: 
> https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
> Signed-off-by: Nathan Chancellor 

Thanks for the patch! I've never seen the closes tag before, that's
new to me. Can you tell me more about it?

A few more tags

Reported-by: Tom Rix 
Link: https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
Reviewed-by: Nick Desaulniers 


> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0490c6412ab5..6d49e0ab3e85 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6008,6 +6008,7 @@ static int intel_async_flip_check_hw(struct 
> intel_atomic_state *state, struct in
> plane->base.base.id, 
> plane->base.name);
> return -EINVAL;
> }
> +   break;
>
> case I915_FORMAT_MOD_X_TILED:
> case I915_FORMAT_MOD_Y_TILED:
>
> ---
> base-commit: 9a2cb1b31c040e2f1b313e2f7921f0f5e6b66d82
> change-id: 
> 20230524-intel_async_flip_check_hw-implicit-fallthrough-c4c40b03802f
>
> Best regards,
> --
> Nathan Chancellor 
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2] amdgpu: validate drm_amdgpu_gem_va addrs

[Christian König]

Am 24.05.23 um 00:53 schrieb Chia-I Wu:

Validate drm_amdgpu_gem_va addrs in amdgpu_gem_va_ioctl.
amdgpu_vm_bo_replace_map no longer needs to validate (and its
validations were insufficient either).  amdgpu_vm_bo_map has internal
users and its validations are kept.


No, please keep all validation inside amdgpu_vm.c code.

See the offset is unused or might have a different meaning for some use 
cases, so validating it here is actually not correct.


Christian.



This is motivated by OOB access in amdgpu_vm_update_range when
offset_in_bo+map_size overflows.

Userspace (radeonsi and radv) seems fine as well.

v2: keep the validations in amdgpu_vm_bo_map

Fixes: 9f7eb5367d00 ("drm/amdgpu: actually use the VM map parameters")
Signed-off-by: Chia-I Wu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 15 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  8 +---
  2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d8e683688daab..36d5adfdf0f69 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -681,6 +681,21 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
uint64_t vm_size;
int r = 0;
  
+	if (args->va_address & ~PAGE_MASK || args->offset_in_bo & ~PAGE_MASK ||

+   args->map_size & ~PAGE_MASK) {
+   dev_dbg(dev->dev, "unaligned va_address 0x%LX, offset_in_bo 0x%LX, 
or map_size 0x%LX\n",
+   args->va_address, args->offset_in_bo, args->map_size);
+   return -EINVAL;
+   }
+
+   if (args->map_size == 0 ||
+   args->va_address + args->map_size < args->va_address ||
+   args->offset_in_bo + args->map_size < args->offset_in_bo) {
+   dev_dbg(dev->dev, "invalid map_size 0x%LX (va_address 0x%LX, 
offset_in_bo 0x%LX)\n",
+   args->map_size, args->va_address, args->offset_in_bo);
+   return -EINVAL;
+   }
+
if (args->va_address < AMDGPU_VA_RESERVED_SIZE) {
dev_dbg(dev->dev,
"va_address 0x%LX is in reserved area 0x%LX\n",
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index b9441ab457ea7..6307baaa136cf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1501,15 +1501,9 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device *adev,
uint64_t eaddr;
int r;
  
-	/* validate the parameters */

-   if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
-   size == 0 || size & ~PAGE_MASK)
-   return -EINVAL;
-
/* make sure object fit at this offset */
eaddr = saddr + size - 1;
-   if (saddr >= eaddr ||
-   (bo && offset + size > amdgpu_bo_size(bo)) ||
+   if ((bo && offset + size > amdgpu_bo_size(bo)) ||
(eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
return -EINVAL;
  

Re: [PATCH 1/4] fbdev: imsttfb: Fix error handling in init_imstt()

[Helge Deller]

On 5/23/23 19:38, Markus Elfring wrote:

From: Markus Elfring 
Date: Tue, 23 May 2023 14:32:39 +0200

The return value was overlooked from a call of
the function “fb_alloc_cmap”.

* Thus use a corresponding error check.

* Add two jump targets so that a bit of exception handling
   can be better reused at the end of this function.


Reported-by: Helge Deller 
Link: 
https://lore.kernel.org/dri-devel/069f2f78-01f3-9476-d860-2b695c122...@gmx.de/
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: c75f5a550610 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe")
Signed-off-by: Markus Elfring 
---
  drivers/video/fbdev/imsttfb.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 975dd682fae4..d3532def4707 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1351,6 +1351,7 @@ static int init_imstt(struct fb_info *info)
  {
struct imstt_par *par = info->par;
__u32 i, tmp, *ip, *end;
+   int ret;

tmp = read_reg_le32(par->dc_regs, PRC);
if (par->ramdac == IBM)
@@ -1419,8 +1420,7 @@ static int init_imstt(struct fb_info *info)
if ((info->var.xres * info->var.yres) * (info->var.bits_per_pixel >> 3) > 
info->fix.smem_len
|| !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) {
printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, 
info->var.yres, info->var.bits_per_pixel);
-   framebuffer_release(info);
-   return -ENODEV;
+   goto e_nodev;
}

sprintf(info->fix.id, "IMS TT (%s)", par->ramdac == IBM ? "IBM" : 
"TVP");
@@ -1452,17 +1452,25 @@ static int init_imstt(struct fb_info *info)
  FBINFO_HWACCEL_FILLRECT |
  FBINFO_HWACCEL_YPAN;

-   fb_alloc_cmap(>cmap, 0, 0);
+   ret = fb_alloc_cmap(>cmap, 0, 0);
+   if (ret)
+   goto release_framebuffer;

if (register_framebuffer(info) < 0) {
-   framebuffer_release(info);
-   return -ENODEV;
+   fb_dealloc_cmap(>cmap);
+   goto e_nodev;
}

tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8;
fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n",
info->fix.id, info->fix.smem_len >> 20, tmp);
return 0;
+
+e_nodev:
+   ret = -ENODEV;


I think the return value isn't checked at all, so you could
simply return below "-ENODEV" for all cases (instead of "return ret").
Then you don't need the e_nodev label and can simplify the flow.

Helge



+release_framebuffer:
+   framebuffer_release(info);
+   return ret;
  }

  static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
--
2.40.1

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

On 3/8/23 04:24, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:59 -0500
> Harry Wentland  wrote:
> 
>> We want compositors to be able to set the output
>> colorspace on DP and HDMI outputs, based on the
>> caps reported from the receiver via EDID.
>>
>> Signed-off-by: Harry Wentland 
>> Cc: Pekka Paalanen 
>> Cc: Sebastian Wick 
>> Cc: vitaly.pros...@amd.com
>> Cc: Joshua Ashton 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: amd-...@lists.freedesktop.org
>> Reviewed-By: Joshua Ashton 
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index f91b2ea13d96..2d883c6dae90 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct 
>> drm_connector *connector)
>>  return amdgpu_dm_connector->num_modes;
>>  }
>>  
>> +static const u32 supported_colorspaces =
>> +BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
>> +BIT(DRM_MODE_COLORIMETRY_OPRGB) |
>> +BIT(DRM_MODE_COLORIMETRY_BT2020) |
>> +BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> 
> No DEFAULT?

DEFAULT is always added in drm_mode_create_colorspace_property.

> No BT.709 RGB, i.e. sRGB?
> 

No RGB variants for BT.709 or sRGB are explicitly defined in the API
(which is based on the infoframe values). Not trying to change things
up here.

You'll probably want to select "DEFAULT" if you want sRGB.

Harry

> Doesn't DRM core reject enum uint values that are not listed in the enum
> property?
> 
> 
> Thanks,
> pq
> 
>> +
>>  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>>   struct amdgpu_dm_connector *aconnector,
>>   int connector_type,
>> @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct 
>> amdgpu_display_manager *dm,
>>  adev->mode_info.abm_level_property, 0);
>>  }
>>  
>> +if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
>> +if 
>> (!drm_mode_create_hdmi_colorspace_property(>base, 
>> supported_colorspaces))
>> +
>> drm_connector_attach_colorspace_property(>base);
>> +} else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>> +   connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +if (!drm_mode_create_dp_colorspace_property(>base, 
>> supported_colorspaces))
>> +
>> drm_connector_attach_colorspace_property(>base);
>> +}
>> +
>>  if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>>  connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>>  connector_type == DRM_MODE_CONNECTOR_eDP) {
> 

Re: [PATCH 3/4] fbdev: imsttfb: Move a variable assignment for an error code in imsttfb_probe()

[Helge Deller]

On 5/23/23 19:42, Markus Elfring wrote:

From: Markus Elfring 
Date: Tue, 23 May 2023 18:30:26 +0200

The value “-ENOMEM” was assigned to the variable “ret”
at the beginning.
Move this statement directly before the first ioremap() call.


Please do not move such variables without real need.
It makes backporting (of this and maybe follow-up patches) much more
complicated and the compiler will optimize it anyway.

Thanks!
Helge



Signed-off-by: Markus Elfring 
---
  drivers/video/fbdev/imsttfb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 6490f544f8eb..90c72428e8d7 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1484,7 +1484,6 @@ static int imsttfb_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
ret = aperture_remove_conflicting_pci_devices(pdev, "imsttfb");
if (ret)
return ret;
-   ret = -ENOMEM;

dp = pci_device_to_OF_node(pdev);
if(dp)
@@ -1525,6 +1524,7 @@ static int imsttfb_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
}

info->fix.smem_start = addr;
+   ret = -ENOMEM;
info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
0x40 : 0x80);
if (!info->screen_base)
--
2.40.1

Re: [PATCH 1/2] fbdev: Move two variable assignments in fb_alloc_cmap_gfp()

[Helge Deller]

On 5/23/23 22:15, Markus Elfring wrote:

From: Markus Elfring 
Date: Tue, 23 May 2023 21:30:29 +0200

Move the assignment for the local variables “size” and “flags”
because the computed values were only used in a single if branch.


Please do not move such variables without real need.
It makes backporting (of this and maybe follow-up patches) much more
complicated and the compiler will optimize it anyway.

Thanks!
Helge



Signed-off-by: Markus Elfring 
---
  drivers/video/fbdev/core/fbcmap.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcmap.c 
b/drivers/video/fbdev/core/fbcmap.c
index ff09e57f3c38..5c1075ed28ab 100644
--- a/drivers/video/fbdev/core/fbcmap.c
+++ b/drivers/video/fbdev/core/fbcmap.c
@@ -91,16 +91,17 @@ static const struct fb_cmap default_16_colors = {

  int fb_alloc_cmap_gfp(struct fb_cmap *cmap, int len, int transp, gfp_t flags)
  {
-   int size = len * sizeof(u16);
int ret = -ENOMEM;

-   flags |= __GFP_NOWARN;
-
if (cmap->len != len) {
+   int size;
+
fb_dealloc_cmap(cmap);
if (!len)
return 0;

+   size = len * sizeof(u16);
+   flags |= __GFP_NOWARN;
cmap->red = kzalloc(size, flags);
if (!cmap->red)
goto fail;
--
2.40.1

[PULL] drm-intel-gt-next

[Tvrtko Ursulin]

Hi Dave, Daniel,

Here goes the first pull request for 6.5.

In terms of headline features probably the fact GuC platforms can now show per
client engine utilisation sticks out the most.

Then there is a bunch of fixes where those in the area of GuC error capture,
SLPS and firmware loading dominate the picture.

Meteorlake platform enablement continues full steam ahead with workarounds,
multi-tile refactoring, PMU support, PXP support, and prep work for sunsetting
the set caching ioctl to be replaced with direct PAT index programming from
userspace probably in the next pull request.

Finally there is smaller than usual amount of driver cleanups and refactorings
and a spinkle of selftest fixups and such.

Btw the next and final pull request for 6.5 I aim to send two weeks from now.

Regards,

Tvrtko

drm-intel-gt-next-2023-05-24:
UAPI Changes:

- New getparam for querying PXP support and load status

Cross-subsystem Changes:

- GSC/MEI proxy driver

Driver Changes:

Fixes/improvements/new stuff:

- Avoid clearing pre-allocated framebuffers with the TTM backend (Nirmoy Das)
- Implement framebuffer mmap support (Nirmoy Das)
- Disable sampler indirect state in bindless heap (Lionel Landwerlin)
- Avoid out-of-bounds access when loading HuC (Lucas De Marchi)
- Actually return an error if GuC version range check fails (John Harrison)
- Get mutex and rpm ref just once in hwm_power_max_write (Ashutosh Dixit)
- Disable PL1 power limit when loading GuC firmware (Ashutosh Dixit)
- Block in hwmon while waiting for GuC reset to complete (Ashutosh Dixit)
- Provide sysfs for SLPC efficient freq (Vinay Belgaumkar)
- Add support for total context runtime for GuC back-end (Umesh Nerlige Ramappa)
- Enable fdinfo for GuC backends (Umesh Nerlige Ramappa)
- Don't capture Gen8 regs on Xe devices (John Harrison)
- Fix error capture for virtual engines (John Harrison)
- Track patch level versions on reduced version firmware files (John Harrison)
- Decode another GuC load failure case (John Harrison)
- GuC loading and firmware table handling fixes (John Harrison)
- Fix confused register capture list creation (John Harrison)
- Dump error capture to kernel log (John Harrison)
- Dump error capture to dmesg on CTB error (John Harrison)
- Disable rps_boost debugfs when SLPC is used (Vinay Belgaumkar)

Future platform enablement:

- Disable stolen memory backed FB for A0 [mtl] (Nirmoy Das)
- Various refactors for multi-tile enablement (Andi Shyti, Tejas Upadhyay)
- Extend Wa_22011802037 to MTL A-step (Madhumitha Tolakanahalli Pradeep)
- WA to clear RDOP clock gating [mtl] (Haridhar Kalvala)
- Set has_llc=0 [mtl] (Fei Yang)
- Define MOCS and PAT tables for MTL (Madhumitha Tolakanahalli Pradeep)
- Add PTE encode function [mtl] (Fei Yang)
- fix mocs selftest [mtl] (Fei Yang)
- Workaround coherency issue for Media [mtl] (Fei Yang)
- Add workaround 14018778641 [mtl] (Tejas Upadhyay)
- Implement Wa_14019141245 [mtl] (Radhakrishna Sripada)
- Fix the wa number for Wa_22016670082 [mtl] (Radhakrishna Sripada)
- Use correct huge page manager for MTL (Jonathan Cavitt)
- GSC/MEI support for Meteorlake (Alexander Usyskin, Daniele Ceraolo Spurio)
- Define GuC firmware version for MTL (John Harrison)
- Drop FLAT CCS check [mtl] (Pallavi Mishra)
- Add MTL for remapping CCS FBs [mtl] (Clint Taylor)
- Meteorlake PXP enablement (Alan Previn)
- Do not enable render power-gating on MTL (Andrzej Hajda)
- Add MTL performance tuning changes (Radhakrishna Sripada)
- Extend Wa_16014892111 to MTL A-step (Radhakrishna Sripada)
- PMU multi-tile support (Tvrtko Ursulin)
- End support for set caching ioctl [mtl] (Fei Yang)

Driver refactors:

- Use i915 instead of dev_priv insied the file_priv structure (Andi Shyti)
- Use proper parameter naming in for_each_engine() (Andi Shyti)
- Use gt_err for GT info (Tejas Upadhyay)
- Consolidate duplicated capture list code (John Harrison)
- Capture list naming clean up (John Harrison)
- Use kernel-doc -Werror when CONFIG_DRM_I915_WERROR=y (Jani Nikula)
- Preparation for using PAT index (Fei Yang)
- Use pat_index instead of cache_level (Fei Yang)

Miscellaneous:

- Fix memory leaks in i915 selftests (Cong Liu)
- Record GT error for gt failure (Tejas Upadhyay)
- Migrate platform-dependent mock hugepage selftests to live (Jonathan Cavitt)
- Update the SLPC selftest (Vinay Belgaumkar)
- Throw out set() wrapper (Jani Nikula)
- Large driver kernel doc cleanup (Jani Nikula)
- Fix probe injection CI failures after recent change (John Harrison)
- Make unexpected firmware versions an error in debug builds (John Harrison)
- Silence UBSAN uninitialized bool variable warning (Ashutosh Dixit)
- Fix memory leaks in function live_nop_switch (Cong Liu)

Merges:

- Merge drm/drm-next into drm-intel-gt-next (Joonas Lahtinen)
The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585:

  Merge tag 'mediatek-drm-next-6.4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into 
drm-next (2023-04-11 12:28:10 +0200)

Re: [PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional

[Tvrtko Ursulin]

On 24/05/2023 18:38, Dixit, Ashutosh wrote:

On Wed, 24 May 2023 04:38:18 -0700, Tvrtko Ursulin wrote:




Hi Tvrtko,


On 23/05/2023 16:19, Ashutosh Dixit wrote:

No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Ashutosh Dixit 
---
   drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
   drivers/gpu/drm/i915/i915_pmu.h |  2 +-
   2 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index b47d890d4ada1..137e0df9573ee 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -195,33 +195,6 @@ static inline s64 ktime_since_raw(const ktime_t kt)
return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
   }
   -static unsigned int
-__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
-   unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
-
-   GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
-
-   return idx;
-}
-
-static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
-   return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
-}
-
-static void
-store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
-{
-   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
-}
-
-static void
-add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32 val, 
u32 mul)
-{
-   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val, 
mul);
-}


IMO read and store helpers could have stayed and just changed the
implementation. Like add_sample_mult which you just moved. I would have
been a smaller patch. So dunno.. a bit of a reluctant r-b.


Are you referring just to add_sample_mult or to all the other functions
too? add_sample_mult I moved it to where it was before bc4be0a38b63


Read and store helpers.


("drm/i915/pmu: Prepare for multi-tile non-engine counters"), could have
left it here I guess.

The other read and store helpers are not needed with the 2-d array at all
since the compiler itself will do that, so I thought it was better to get
rid of them completely.


Yes I get it, just that I didn't see the benefit of removing them.

For example:

 -  store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
 +  pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;

It's a meh for me. Either flavour looks fine to me so I would have erred 
on the side of keeping the patch small. If anything I probably slightly 
prefer that the struct pmu_sample implementation was able to be changed 
with less churn before. For example. But a very minor argument really.


Or maybe next step is get rid of the struct i915_pmu_sample. It is a 
struct because originally previous value was tracked too. Then I removed 
that and it was easier to keep the struct. I guess it can go now and 
then the removal of helpers here will look somewhat nicer without the 
trailing .cur on every affected line.



Let me know if you want any changes, otherwise I will leave as is.


You can leave it as is, I dont' mind much.

Regards,

Tvrtko


Reviewed-by: Tvrtko Ursulin 


Thanks for the review. Thanks Andrzej too :)
--
Ashutosh


-
   static u64 get_rc6(struct intel_gt *gt)
   {
struct drm_i915_private *i915 = gt->i915;
@@ -240,7 +213,7 @@ static u64 get_rc6(struct intel_gt *gt)
spin_lock_irqsave(>lock, flags);
if (awake) {
-   store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
+   pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
} else {
/*
 * We think we are runtime suspended.
@@ -250,13 +223,13 @@ static u64 get_rc6(struct intel_gt *gt)
 * counter value.
 */
val = ktime_since_raw(pmu->sleep_last[gt_id]);
-   val += read_sample(pmu, gt_id, __I915_SAMPLE_RC6);
+   val += pmu->sample[gt_id][__I915_SAMPLE_RC6].cur;
}
   -if (val < read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED))
-   val = read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED);
+   if (val < pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur)
+   val = pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur;
else
-   store_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED, val);
+   pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
spin_unlock_irqrestore(>lock, flags);
   @@ -275,9 +248,8 @@ static void init_rc6(struct i915_pmu *pmu)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
u64 val = __get_rc6(gt);
   -store_sample(pmu, i, __I915_SAMPLE_RC6, val);
-   store_sample(pmu, i, 

[PATCH v14 8/9] drm/msm/dsi: Use MSM and DRM DSC helper methods

[Jessica Zhang]

Use MSM and DRM DSC helper methods to configure DSC for DSI.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 74d38f90398a..5526a51b3d97 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -28,6 +28,7 @@
 #include "dsi.xml.h"
 #include "sfpb.xml.h"
 #include "dsi_cfg.h"
+#include "msm_dsc_helper.h"
 #include "msm_kms.h"
 #include "msm_gem.h"
 #include "phy/dsi_phy.h"
@@ -848,7 +849,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
/* first calculate dsc parameters and then program
 * compress mode registers
 */
-   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   slice_per_intf = msm_dsc_get_slices_per_intf(dsc, hdisplay);
 
/*
 * If slice_count is greater than slice_per_intf
@@ -1759,7 +1760,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return ret;
}
 
-   dsc->initial_scale_value = 32;
+   dsc->initial_scale_value = drm_dsc_initial_scale_value(dsc);
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
return drm_dsc_compute_rc_parameters(dsc);

-- 
2.40.1

[PATCH v14 6/9] drm/msm/dpu: Use fixed DRM DSC helper for det_thresh_flatness

[Jessica Zhang]

The current dpu_hw_dsc calculation for det_thresh_flatness does not
match the downstream calculation or the DSC spec.

Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4e1396575e6a..3cad6a80af97 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
  * Copyright (c) 2020-2022, Linaro Limited
  */
 
+#include 
+
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
 
-   det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+   det_thresh_flatness = drm_dsc_flatness_det_thresh(dsc);
data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;

-- 
2.40.1

[PATCH v14 4/9] drm/msm/dsi: use DRM DSC helpers for DSC setup

[Jessica Zhang]

From: Dmitry Baryshkov 

Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 61 +-
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 961689a255c4..74d38f90398a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1731,28 +1731,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
-   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
-   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
-   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
-   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
 static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct 
drm_dsc_config *dsc)
 {
-   int i;
-   u16 bpp = dsc->bits_per_pixel >> 4;
+   int ret;
 
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(_host->pdev->dev, "DSI does not support 
fractional bits_per_pixel\n");
@@ -1764,49 +1745,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
 
-   dsc->rc_model_size = 8192;
-   dsc->first_line_bpg_offset = 12;
-   dsc->rc_edge_factor = 6;
-   dsc->rc_tgt_offset_high = 3;
-   dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
 
-   /* handle only bpp = bpc = 8 */
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
-   dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+   drm_dsc_set_const_params(dsc);
+   drm_dsc_set_rc_buf_thresh(dsc);
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
-   dsc->rc_range_params[i].range_min_qp = min_qp[i];
-   dsc->rc_range_params[i].range_max_qp = max_qp[i];
-   /*
-* Range BPG Offset contains two's-complement signed values 
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits 
wide.
-*/
-   dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] & 
DSC_RANGE_BPG_OFFSET_MASK;
+   /* handle only bpp = bpc = 8, pre-SCR panels */
+   ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+   if (ret) {
+   DRM_DEV_ERROR(_host->pdev->dev, "could not find DSC RC 
parameters\n");
+   return ret;
}
 
-   dsc->initial_offset = 6144; /* Not bpp 12 */
-   if (bpp != 8)
-   dsc->initial_offset = 2048; /* bpp = 12 */
-
-   if (dsc->bits_per_component <= 10)
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
-   else
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
-   dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
-   dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
-   /* bpc 8 */
-   dsc->flatness_min_qp = 3;
-   dsc->flatness_max_qp = 12;
-   dsc->rc_quant_incr_limit0 = 11;
-   dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
 }
 

-- 
2.40.1

[PATCH v14 1/9] drm/display/dsc: Add flatness and initial scale value calculations

[Jessica Zhang]

Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Reviewed-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 24 
 include/drm/display/drm_dsc_helper.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index fc187a8d8873..4efb6236d22c 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -1413,3 +1413,27 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
*vdsc_cfg)
return 0;
 }
 EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
+
+/**
+ * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
given DSC config
+ * @dsc: Pointer to DRM DSC config struct
+ *
+ * Return: Calculated initial scale value
+ */
+u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc)
+{
+   return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
dsc->initial_offset);
+}
+EXPORT_SYMBOL(drm_dsc_initial_scale_value);
+
+/**
+ * drm_dsc_flatness_det_thresh() - Calculate the flatness_det_thresh for the 
given DSC config
+ * @dsc: Pointer to DRM DSC config struct
+ *
+ * Return: Calculated flatness det thresh value
+ */
+u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}
+EXPORT_SYMBOL(drm_dsc_flatness_det_thresh);
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index fc2104415dcb..71789fb34e17 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -24,6 +24,8 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_sdp,
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_type type);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
+u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
+u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
 
 #endif /* _DRM_DSC_HELPER_H_ */
 

-- 
2.40.1

[PATCH v14 7/9] drm/msm/dpu: Fix slice_last_group_size calculation

[Jessica Zhang]

Correct the math for slice_last_group_size so that it matches the
calculations downstream.

Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 3cad6a80af97..ea7d828b8812 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,9 +56,10 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
 
-   slice_last_group_size = 3 - (dsc->slice_width % 3);
+   slice_last_group_size = (dsc->slice_width + 2) % 3;
+
data = (initial_lines << 20);
-   data |= ((slice_last_group_size - 1) << 18);
+   data |= (slice_last_group_size << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */
data |= (dsc->bits_per_pixel << 8);
data |= (dsc->block_pred_enable << 7);

-- 
2.40.1

[PATCH v14 2/9] drm/display/dsc: add helper to set semi-const parameters

[Jessica Zhang]

From: Dmitry Baryshkov 

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 22 ++
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 4efb6236d22c..b31fe9849784 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,28 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   if (!vdsc_cfg->rc_model_size)
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
 /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
 static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 71789fb34e17..f4e18e5d077a 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_type type);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);

-- 
2.40.1

[PATCH v14 9/9] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup

[Jessica Zhang]

Currently, hdisplay is being divided by 3 for DSC. However, this
calculation only works for cases where BPP = 8.

Update hdisplay calculation to be bytes_per_line / 3, so that it
accounts for cases where BPP != 8.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 5526a51b3d97..9223d7ec5a73 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi)
 * pulse width same
 */
h_total -= hdisplay;
-   hdisplay /= 3;
+   hdisplay = msm_dsc_get_bytes_per_line(msm_host->dsc) / 3;
h_total += hdisplay;
ha_end = ha_start + hdisplay;
}

-- 
2.40.1

[PATCH v14 3/9] drm/display/dsc: Add drm_dsc_get_bpp_int helper

[Jessica Zhang]

Add helper to get the integer value of drm_dsc_config.bits_per_pixel

Reviewed-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 13 +
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index b31fe9849784..4424380c6cb6 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -1436,6 +1436,19 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_compute_rc_parameters);
 
+/**
+ * drm_dsc_get_bpp_int() - Get integer bits per pixel value for the given DRM 
DSC config
+ * @vdsc_cfg: Pointer to DRM DSC config struct
+ *
+ * Return: Integer BPP value
+ */
+u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg)
+{
+   WARN_ON_ONCE(vdsc_cfg->bits_per_pixel & 0xf);
+   return vdsc_cfg->bits_per_pixel >> 4;
+}
+EXPORT_SYMBOL(drm_dsc_get_bpp_int);
+
 /**
  * drm_dsc_initial_scale_value() - Calculate the initial scale value for the 
given DSC config
  * @dsc: Pointer to DRM DSC config struct
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index f4e18e5d077a..913aa2071232 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -27,6 +27,7 @@ int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, 
enum drm_dsc_params
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 u8 drm_dsc_initial_scale_value(const struct drm_dsc_config *dsc);
 u32 drm_dsc_flatness_det_thresh(const struct drm_dsc_config *dsc);
+u32 drm_dsc_get_bpp_int(const struct drm_dsc_config *vdsc_cfg);
 
 #endif /* _DRM_DSC_HELPER_H_ */
 

-- 
2.40.1

[PATCH v14 0/9] Introduce MSM-specific DSC helpers

[Jessica Zhang]

There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.

This series moves these calculations to a shared msm_dsc_helper.c file and
defines drm_dsc_helper methods for initial_scale_value and
det_thresh_flatness.

Note: For now, the MSM specific helper methods are only called for the DSI
path, but will called for DP once DSC 1.2 support for DP has been added.

Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1]

[1] https://patchwork.freedesktop.org/series/114472/

---
Changes in v14:
- Added kernel docs and made DRM DSC helper functions (Jani)
- Link to v13: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v13-0-d7581e7be...@quicinc.com

Changes in v13:
- Reworded comment doc for msm_dsc_get_slices_per_intf()
- Changed intf_width to u32
- msm_dsc_calculate_slices_per_intf -> msm_dsc_get_slices_per_intf
- Link to v12: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v12-0-9cdb7401f...@quicinc.com

Changes in v12:
- Reworded summary comment for msm_dsc_helper.h
- msm_dsc_get_slices_per_intf -> msm_dsc_calculate_slices_per_intf
- Corrected total_bytes_per_intf math in dsc_update_dsc_timing
- Rebased on top of latest version of "drm/i915: move DSC RC tables to 
drm_dsc_helper.c"
- Link to v11: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v11-0-30270e1ee...@quicinc.com

Changes in v11:
- Fixed mismatched return types
- Moved MSM DSC helpers summary comment to under copyright
- Moved msm_dsc_get_bpp_int() to drm_dsc_helper.h
- Reworded MSM DSC helper comment docs for clarity
- Added const keyword where applicable
- Renamed msm_dsc_get_slice_per_intf to msm_dsc_get_slices_per_intf
- Removed msm_dsc_get_slice_per_intf()
- Reworded commit message for "drm/msm/dsi: update hdisplay calculation
  for dsi_timing_setup"
- Link to v10: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v10-0-4cb21168c...@quicinc.com

Changes in v10:
- Removed msm_dsc_get_bytes_per_slice helper
- Inlined msm_dsc_get_bytes_per_intf
- Refactored drm_dsc_set_initial_scale_value() to be a pure function
- Renamed DRM DSC initial_scale and flatness_det_thresh helpers
- Removed msm_dsc_helpers.o from Makefile
- Link to v9: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v9-0-87daeaec2...@quicinc.com

Changes in v9:
- Fixed incorrect math for msm_dsc_get_bytes_per_line()
- Link to v8: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v8-0-2c9b2bb12...@quicinc.com

Changes in v8:
- *_bytes_per_soft_slice --> *_bytes_per_slice
- Fixed comment doc formatting for MSM DSC helpers
- Use slice_chunk_size in msm_dsc_get_bytes_per_line calculation
- Reworded "drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness"
  commit title for clarity
- Picked up "Reviewed-by" tags
- Added duplicate Signed-off-by tag to "drm/display/dsc: Add flatness
  and initial scale value calculations" to reflect patch history
- Link to v7: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v7-0-df48a2c54...@quicinc.com

Changes in v7:
- Renamed msm_dsc_get_pclk_per_intf to msm_dsc_get_bytes_per_line
- Removed duplicate msm_dsc_get_dce_bytes_per_line
- Reworded commit message for "drm/msm/dpu: Use DRM DSC helper for
  det_thresh_flatness"
- Dropped slice_per_pkt change (it will be included in the later
  "Add DSC v1.2 Support for DSI" series)
- Picked up "drm/display/dsc: Add flatness and initial scale value
  calculations" and "drm/display/dsc: add helper to set semi-const
  parameters", which were dropped from "drm/i915: move DSC RC tables to
  drm_dsc_helper.c" series
- Picked up "Reviewed-by" tags
- Removed changelog in individual patches
- Link to v6: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v6-0-cb7f59f0f...@quicinc.com

Changes in v6:
- Documented return values for MSM DSC helpers
- Fixed dependency issue in msm_dsc_helper.c
- Link to v5: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v5-0-0108401d7...@quicinc.com

Changes in v5:
- Added extra line at end of msm_dsc_helper.h
- Simplified msm_dsc_get_bytes_per_soft_slice() math
- Simplified and inlined msm_dsc_get_pclk_per_intf() math
- "Fix calculations pkt_per_line" --> "... Fix calculation for pkt_per_line"
- Split dsc->slice_width check into a separate patch
- Picked up Dmitry's msm/dsi patch ("drm/msm/dsi: use new helpers for
  DSC setup")
- Removed unused headers in MSM DSC helper files
- Picked up Reviewed-by tags
- Link to v4: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v4-0-1b79c78b3...@quicinc.com

Changes in v4:
- Changed msm_dsc_get_uncompressed_pclk_per_intf to msm_dsc_get_pclk_per_intf
- Moved pclk_per_intf calculation for dsi_timing_setup to `if
  (msm_host->dsc)` block
- Link to v3: 
https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v3-0-6bec0d277...@quicinc.com

Changes in v3:
- Dropped src_bpp parameter 

[PATCH v14 5/9] drm/msm: Add MSM-specific DSC helper methods

[Jessica Zhang]

Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/msm_dsc_helper.h | 38 
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..b9049fe1e279
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ *
+ * Helper methods for MSM-specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+
+/**
+ * msm_dsc_get_slices_per_intf() - calculate number of slices per interface
+ * @dsc: Pointer to drm dsc config struct
+ * @intf_width: interface width in pixels
+ * Returns: Integer representing the number of slices for the given interface
+ */
+static inline u32 msm_dsc_get_slices_per_intf(const struct drm_dsc_config 
*dsc, u32 intf_width)
+{
+   return DIV_ROUND_UP(intf_width, dsc->slice_width);
+}
+
+/**
+ * msm_dsc_get_bytes_per_line() - calculate bytes per line
+ * @dsc: Pointer to drm dsc config struct
+ * Returns: Integer value representing bytes per line. DSI and DP need
+ *  to perform further calculations to turn this into pclk_per_intf,
+ *  such as dividing by different values depending on if widebus is 
enabled.
+ */
+static inline u32 msm_dsc_get_bytes_per_line(const struct drm_dsc_config *dsc)
+{
+   return dsc->slice_count * dsc->slice_chunk_size;
+}
+
+#endif /* MSM_DSC_HELPER_H_ */

-- 
2.40.1

Re: [PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional

[Dixit, Ashutosh]

On Wed, 24 May 2023 04:38:18 -0700, Tvrtko Ursulin wrote:
>

Hi Tvrtko,

> On 23/05/2023 16:19, Ashutosh Dixit wrote:
> > No functional changes but we can remove some unsightly index computation
> > and read/write functions if we convert the PMU sample array from a
> > one-dimensional to a two-dimensional array.
> >
> > Suggested-by: Tvrtko Ursulin 
> > Signed-off-by: Ashutosh Dixit 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
> >   drivers/gpu/drm/i915/i915_pmu.h |  2 +-
> >   2 files changed, 19 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index b47d890d4ada1..137e0df9573ee 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -195,33 +195,6 @@ static inline s64 ktime_since_raw(const ktime_t kt)
> > return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
> >   }
> >   -static unsigned int
> > -__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
> > -{
> > -   unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
> > -
> > -   GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
> > -
> > -   return idx;
> > -}
> > -
> > -static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int 
> > sample)
> > -{
> > -   return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
> > -}
> > -
> > -static void
> > -store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
> > -{
> > -   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
> > -}
> > -
> > -static void
> > -add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32 
> > val, u32 mul)
> > -{
> > -   pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val, 
> > mul);
> > -}
>
> IMO read and store helpers could have stayed and just changed the
> implementation. Like add_sample_mult which you just moved. I would have
> been a smaller patch. So dunno.. a bit of a reluctant r-b.

Are you referring just to add_sample_mult or to all the other functions
too? add_sample_mult I moved it to where it was before bc4be0a38b63
("drm/i915/pmu: Prepare for multi-tile non-engine counters"), could have
left it here I guess.

The other read and store helpers are not needed with the 2-d array at all
since the compiler itself will do that, so I thought it was better to get
rid of them completely.

Let me know if you want any changes, otherwise I will leave as is.

> Reviewed-by: Tvrtko Ursulin 

Thanks for the review. Thanks Andrzej too :)
--
Ashutosh

> > -
> >   static u64 get_rc6(struct intel_gt *gt)
> >   {
> > struct drm_i915_private *i915 = gt->i915;
> > @@ -240,7 +213,7 @@ static u64 get_rc6(struct intel_gt *gt)
> > spin_lock_irqsave(>lock, flags);
> > if (awake) {
> > -   store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
> > +   pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
> > } else {
> > /*
> >  * We think we are runtime suspended.
> > @@ -250,13 +223,13 @@ static u64 get_rc6(struct intel_gt *gt)
> >  * counter value.
> >  */
> > val = ktime_since_raw(pmu->sleep_last[gt_id]);
> > -   val += read_sample(pmu, gt_id, __I915_SAMPLE_RC6);
> > +   val += pmu->sample[gt_id][__I915_SAMPLE_RC6].cur;
> > }
> >   - if (val < read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED))
> > -   val = read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED);
> > +   if (val < pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur)
> > +   val = pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur;
> > else
> > -   store_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED, val);
> > +   pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
> > spin_unlock_irqrestore(>lock, flags);
> >   @@ -275,9 +248,8 @@ static void init_rc6(struct i915_pmu *pmu)
> > with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
> > u64 val = __get_rc6(gt);
> >   - store_sample(pmu, i, __I915_SAMPLE_RC6, val);
> > -   store_sample(pmu, i, __I915_SAMPLE_RC6_LAST_REPORTED,
> > -val);
> > +   pmu->sample[i][__I915_SAMPLE_RC6].cur = val;
> > +   pmu->sample[i][__I915_SAMPLE_RC6_LAST_REPORTED].cur = 
> > val;
> > pmu->sleep_last[i] = ktime_get_raw();
> > }
> > }
> > @@ -287,7 +259,7 @@ static void park_rc6(struct intel_gt *gt)
> >   {
> > struct i915_pmu *pmu = >i915->pmu;
> >   - store_sample(pmu, gt->info.id, __I915_SAMPLE_RC6, __get_rc6(gt));
> > +   pmu->sample[gt->info.id][__I915_SAMPLE_RC6].cur = __get_rc6(gt);
> > pmu->sleep_last[gt->info.id] = ktime_get_raw();
> >   }
> >   @@ -428,6 +400,12 @@ engines_sample(struct intel_gt *gt, unsigned int
> > period_ns)
> > }
> >   }
> >   +static void
> > +add_sample_mult(struct 

Re: [PATCH 7/9] HID: i2c-hid: Support being a panel follower

[Doug Anderson]

Hi,

On Tue, May 23, 2023 at 12:31 PM Douglas Anderson  wrote:
>
> As talked about in the patch ("drm/panel: Add a way for other devices
> to follow panel state"), we really want to keep the power states of a
> touchscreen and the panel it's attached to in sync with each other. In
> that spirit, add support to i2c-hid to be a panel follower. This will
> let the i2c-hid driver get informed when the panel is powered on and
> off. From there we can match the i2c-hid device's power state to that
> of the panel.
>
> NOTE: this patch specifically _doesn't_ use pm_runtime to keep track
> of / manage the power state of the i2c-hid device, even though my
> first instinct said that would be the way to go. Specific problems
> with using pm_runtime():
> * The initial power up couldn't happen in a runtime resume function
>   since it create sub-devices and, apparently, that's not good to do
>   in your resume function.
> * Managing our power state with pm_runtime meant fighting to make the
>   right thing happen at system suspend to prevent the system from
>   trying to resume us only to suspend us again. While this might be
>   able to be solved, it added complexity.
> Overall the code without pm_runtime() ended up being smaller and
> easier to understand.
>
> Signed-off-by: Douglas Anderson 
> ---
>
>  drivers/hid/i2c-hid/i2c-hid-core.c | 82 +-
>  1 file changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 34c0d98b4976..f1bb89377e8d 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -38,6 +38,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "../hid-ids.h"
>  #include "i2c-hid.h"
>
> @@ -107,6 +109,8 @@ struct i2c_hid {
> struct mutexreset_lock;
>
> struct i2chid_ops   *ops;
> +   struct drm_panel_follower panel_follower;
> +   boolis_panel_follower;
>  };
>
>  static const struct i2c_hid_quirks {
> @@ -1058,6 +1062,34 @@ int i2c_hid_core_initial_power_up(struct i2c_hid *ihid)
> return ret;
>  }
>
> +int i2c_hid_core_panel_prepared(struct drm_panel_follower *follower)

As pointed out by the kernel test robot, I clearly missed making
several functions "static" in this patch series. :( I'll fix that in
v2, but for now I'll hold off sending v2 to wait for additional
feedback.

-Doug