Re: [PATCH] Revert "drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes"
On Wed, Feb 28, 2024 at 12:08:08AM +0200, Dmitry Baryshkov wrote:
> This reverts commit e467e0bde881 ("drm/msm/dp: use
> drm_bridge_hpd_notify() to report HPD status changes").
>
> The commit changed the way how the MSM DP driver communicates
> HPD-related events to the userspace. The mentioned commit made some of
> the HPD events being reported earlier. This way userspace starts poking
> around. It interacts in a bad way with the dp_bridge_detect and the
> driver's state machine, ending up either with the very long delays
> during hotplug detection or even inability of the DP driver to report
> the display as connected.
>
> A proper fix will involve redesigning of the HPD handling in the MSM DP
> driver. It is underway, but it will be intrusive and can not be thought
> about as a simple fix for the issue. Thus, revert the offending commit.
>
> Fixes: e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify() to report HPD
> status changes")
> Link: https://gitlab.freedesktop.org/drm/msm/-/issues/50
> Reported-by: Johan Hovold
> Link: https://lore.kernel.org/r/zd3ypgmrprxv-...@hovoldconsulting.com/
> Signed-off-by: Dmitry Baryshkov
Tested-by: Johan Hovold
Re: [PATCH 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document
On 27/02/2024 16:18, Alexandre Mergnat wrote: >> >>> +type: boolean >>> + >>> + mediatek,dmic-iir-on: >>> +description: >>> + Boolean which specifies whether the DMIC IIR is enabled. >>> + If this property is not present the IIR is disabled. >> >> "is enabled" or "enable it"? >> >> You described the desired Linux feature or behavior, not the actual >> hardware. The bindings are about the latter, so instead you need to >> rephrase the property and its description to match actual hardware >> capabilities/features/configuration etc. > > I will rephrase: > > True to enable the Infinite Impulse Response (IIR) filter > on the digital microphone inputs. I still don't know why this is DT-specific. You still tell driver what to do... > >> >>> +type: boolean >>> + >>> + mediatek,dmic-irr-mode: >>> +$ref: /schemas/types.yaml#/definitions/uint32 >>> +description: >>> + Selects stop band of IIR DC-removal filter. >>> + 0 = Software programmable custom coeff loaded by the driver. >> >> Bindings are for hardware, not drivers. Why is this a property of board DTS? > > Actually this is a hardware feature. Mode 1 t 5 are predefined filters. > Mode 0, the HW will read some "coef filter registers" to setup the > custom filter. the "coef filter regs" are written by the driver. > Currently the coef values are hardcoded in the driver. You don't get the point. Just because you choose some mode it does not mean is hardware feature for DT. Sampling frequency done by hardware is also "hardware feature", but do you put it to DT? No. Explain why this is board-specific, not runtime configuration. > >> >>> + 1 = 5Hz if 48KHz mode. >>> + 2 = 10Hz if 48KHz mode. >>> + 3 = 25Hz if 48KHz mode. >>> + 4 = 50Hz if 48KHz mode. >>> + 5 = 65Hz if 48KHz mode. >> >> Use proper unit suffixes - hz. >> >> >>> +enum: >>> + - 0 >>> + - 1 >>> + - 2 >>> + - 3 >>> + - 4 >>> + - 5 >>> + >>> + mediatek,dmic-two-wire-mode: >>> +description: >>> + Boolean which turns on digital microphone for two wire mode. >>> + If this property is not present the two wire mode is disabled. >> >> This looks like hardware property, but the naming looks like SW. Again >> you instruct what driver should do. Standard disclaimer: >> >> You described the desired Linux feature or behavior, not the actual >> hardware. The bindings are about the latter, so instead you need to >> rephrase the property and its description to match actual hardware >> capabilities/features/configuration etc. > > Actually this is a hardware feature. This is ALL I have to describe the > HW behavior from the datasheet: > " > bit name: ul_dmic_two_wire_ctl > Turns on digital microphone for two wire mode. > 0: Turn off > 1: Turn on That's rather suggestion it is not a description of hardware but you want driver to do something... > " > > On the board schematic, SoC and DMIC and linked by 3 pins: > - clk > - data0 > - data1 > > IMHO, "two-wire-mode" means the HW use 2 pins for data, and the SoC must > be aware of that by reading the register value written by the driver, > using the value found in the DTS. So this depends on type of connection of DMIC? Then rephrase description property like this. > > I don't get why you think it wouldn't be hardware behavior. Because telling what to write to the registers which is typical sign of people stuffing to DT whatever they need to configure the hardware. > > Rephrase description: > "True to enable the two wire mode of the digital microphone" > Is it better ? No, because again you describe some sort of mode. If you insist on such description, then my answer is: it's runtime, so not suitable for DT. Instead describe what is the hardware problem/configuration, e.g. "DMIC is connected with only CLK and DATA0, without third pin" etc. > > About the property name, "mediatek,dmic-two-wire-ctl" sound better for you ? To sound more like a register less like physical characteristic of the board? No. The name can stay, I don't have better ideas. Best regards, Krzysztof
Re: [PATCH 1/6] drm/tests/drm_buddy: fix 32b build
Am 26.02.24 um 10:58 schrieb Matthew Auld:
On 19/02/2024 12:24, Matthew Auld wrote:
On 19/02/2024 10:48, Matthew Auld wrote:
On 19/02/2024 10:30, Christian König wrote:
Am 19.02.24 um 11:28 schrieb Matthew Auld:
On 19/02/2024 09:53, Christian König wrote:
Am 19.02.24 um 10:42 schrieb Matthew Auld:
On 15/02/2024 17:44, Matthew Auld wrote:
Doesn't seem to compile on 32b, presumably due to u64
mod/division.
Simplest is to just switch over to u32 here. Also make print
modifiers
consistent with that.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous
test")
Reported-by: Geert Uytterhoeven
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
Cc: Maxime Ripard
Any chance someone can push just this single patch here, since
it fixes 32b build? It already has an r-b from Arun.
Already working on this. Just give me a few more minutes.
Thanks.
No, problem. I would have pushed this earlier, but my build server
doesn't want to work any more. Looks like the SSD has passed its
warranty :(
Should I push the other three patches to drm-misc-fixes as well? I
currently can't even build test them.
Need to send a v2 for that. One minor change in the test just to be
consistent with using u32. Thanks.
Sent v2. If you could push that when you get a chance. Thanks.
https://patchwork.freedesktop.org/series/130075/
Gentle ping on merging v2.
Pushed all three to drm-misc-fixes.
Regards,
Christian.
Thanks,
Christian.
Thanks,
Christian.
---
drivers/gpu/drm/tests/drm_buddy_test.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index fee6bec757d1..edacc1adb28f 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -21,7 +21,7 @@ static inline u64 get_size(int order, u64
chunk_size)
static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
{
- u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ u32 mm_size, ps = SZ_4K, i, n_pages, total;
struct drm_buddy_block *block;
struct drm_buddy mm;
LIST_HEAD(left);
@@ -56,30 +56,30 @@ static void
drm_test_buddy_alloc_contiguous(struct kunit *test)
KUNIT_ASSERT_FALSE_MSG(test,
drm_buddy_alloc_blocks(&mm, 0, mm_size,
ps, ps, list, 0),
- "buddy_alloc hit an error size=%d\n",
+ "buddy_alloc hit an error size=%u\n",
ps);
} while (++i < n_pages);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
3 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%d\n", 3 * ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
drm_buddy_free_list(&mm, &middle);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
3 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 3 *
ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
2 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 2 *
ps);
+ "buddy_alloc didn't error size=%u\n", 2 * ps);
drm_buddy_free_list(&mm, &right);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
3 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 3 *
ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
/*
* At this point we should have enough contiguous space
for 2 blocks,
* however they are never buddies (since we freed middle
and right) so
@@ -88,13 +88,13 @@ static void
drm_test_buddy_alloc_contiguous(struct kunit *test)
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
2 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%d\n", 2 * ps);
+ "buddy_alloc hit an error size=%u\n", 2 * ps);
drm_buddy_free_list(&mm, &left);
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm,
0, mm_size,
3 * ps, ps, &allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%d\n", 3 * ps);
+ "buddy_alloc hit an error size=%u\n", 3 * ps);
total = 0;
list_for_each_entry(block, &allocated, link)
Re: [PATCH] dt-bindings: display: atmel,lcdc: convert to dtschema
On 28/02/2024 07:59, dharm...@microchip.com wrote: > >> >> I don't know what's this exactly, but if embedded display then maybe >> could be part of this device node. If some other display, then maybe you >> need another schema, with compatible? But first I would check how others >> are doing this. > > Okay, then I think the driver also needs to be modified, currently the > driver parses the phandle and looks for these properties. Also the > corresponding dts files. Driver does not have to be modified in my proposal. You would still have phandle. Best regards, Krzysztof
Re: [PATCH] dt-bindings: display: atmel,lcdc: convert to dtschema
Hi Krzysztof,
On 27/02/24 5:33 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 23/02/2024 10:14, Dharma Balasubiramani wrote:
>> Convert the atmel,lcdc bindings to DT schema.
>> Changes during conversion: add missing clocks and clock-names properties.
>>
>> Signed-off-by: Dharma Balasubiramani
>> ---
>> .../devicetree/bindings/display/atmel,lcdc.txt | 87 --
>> .../devicetree/bindings/display/atmel,lcdc.yaml| 133
>> +
>> 2 files changed, 133 insertions(+), 87 deletions(-)
>
> You have several patch errors... check your git repo (git show). You
> will easily spot them. Or just use decent text editor to clean it up.
> Run checkpatch...
>
There seems to be an issue with my git hooks, Thanks for letting me know
these errors, I will fix it.
> ...
>
>> diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.yaml
>> b/Documentation/devicetree/bindings/display/atmel,lcdc.yaml
>> new file mode 100644
>> index ..4a1de5a8d64b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/atmel,lcdc.yaml
>> @@ -0,0 +1,133 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/atmel,lcdc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip's LCDC Framebuffer
>> +
>> +maintainers:
>> + - Nicolas Ferre
>> + - Dharma Balasubiramani
>> +
>> +description:
>> + The LCDC works with a framebuffer, which is a section of memory that
>> contains
>> + a complete frame of data representing pixel values for the display. The
>> LCDC
>> + reads the pixel data from the framebuffer and sends it to the LCD panel to
>> + render the image.
>> +
>> +properties:
>> + compatible:
>> +enum:
>> + - atmel,at91sam9261-lcdc
>> + - atmel,at91sam9263-lcdc
>> + - atmel,at91sam9g10-lcdc
>> + - atmel,at91sam9g45-lcdc
>> + - atmel,at91sam9g45es-lcdc
>> + - atmel,at91sam9rl-lcdc
>> +
>> + reg:
>> +maxItems: 1
>> +
>> + interrupts:
>> +maxItems: 1
>> +
>> + clocks:
>> +maxItems: 2
>> +
>> + clock-names:
>> +items:
>> + - const: hclk
>> + - const: lcdc_clk
>> +
>> + display:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description: A phandle pointing to the display node.
>
> Phandle does not have properties. Didn't you want object?
>
> This cannot work - just test it. Change the properties in the example,
> remove or add something. Do you see errors? No, because it does not work
> at all.
Yes Indeed, I thought its working as expected as I had all required
property.
>
> I don't know what's this exactly, but if embedded display then maybe
> could be part of this device node. If some other display, then maybe you
> need another schema, with compatible? But first I would check how others
> are doing this.
Okay, then I think the driver also needs to be modified, currently the
driver parses the phandle and looks for these properties. Also the
corresponding dts files.
>
>
>> +
>> +properties:
>> + atmel,dmacon:
>> +$ref: /schemas/types.yaml#/definitions/uint32
>> +description: dma controller configuration
>> +
>> + atmel,lcdcon2:
>> +$ref: /schemas/types.yaml#/definitions/uint32
>> +description: lcd controller configuration
>> +
>> + atmel,guard-time:
>> +$ref: /schemas/types.yaml#/definitions/uint32
>> +description: lcd guard time (Delay in frame periods)
>> +
>> + bits-per-pixel:
>> +$ref: /schemas/types.yaml#/definitions/uint32
>> +description: lcd panel bit-depth.
>> +
>> + atmel,lcdcon-backlight:
>> +$ref: /schemas/types.yaml#/definitions/flag
>> +description: enable backlight
>> +
>> + atmel,lcdcon-backlight-inverted:
>> +$ref: /schemas/types.yaml#/definitions/flag
>> +description: invert backlight PWM polarity
>> +
>> + atmel,lcd-wiring-mode:
>> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +description: lcd wiring mode "RGB" or "BRG"
>> +
>> + atmel,power-control-gpio:
>> +description: gpio to power on or off the LCD (as many as needed)
>> +
>> +required:
>> + - atmel,dmacon
>> + - atmel,lcdcon2
>> + - atmel,guard-time
>> + - bits-per-pixel
>> +
>> +additionalProperties: false
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - clocks
>> + - clock-names
>> + - display
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +#include
>> +fb@50 {
>> + compatible = "atmel,at91sam9g45-lcdc";
>> + reg = <0x0050 0x1000>;
>> + interrupts = <23 3 0>;
>
> Aren't here some standard interrupt flags?
I will update the flags as well in the next revision.
>
>> + pinctrl-names = "default";
>> + p
Re: [PATCH 1/1] drm/bridge: ti-sn65dsi83: Fix enable error path
Hi Luca,
Am Dienstag, 27. Februar 2024, 18:41:44 CET schrieb Luca Ceresoli:
> Hi Alexander,
>
> thanks for your feedback!
>
> On Tue, 27 Feb 2024 13:05:46 +0100
> Alexander Stein wrote:
>
> > Hi Luca,
> >
> > Am Donnerstag, 22. Februar 2024, 16:36:37 CET schrieb Luca Ceresoli:
> > > Hello Alexander,
> > >
> > > On Thu, 4 May 2023 08:53:16 +0200
> > > Alexander Stein wrote:
> > >
> > > > If PLL locking failed, the regulator needs to be disabled again.
> > > >
> > > > Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply
> > > > regulator support")
> > > > Signed-off-by: Alexander Stein
> > > > ---
> > > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > index 75286c9afbb9..1f5c07989e2b 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > @@ -478,6 +478,7 @@ static void sn65dsi83_atomic_enable(struct
> > > > drm_bridge *bridge,
> > > > dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> > > > /* On failure, disable PLL again and exit. */
> > > > regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> > > > + regulator_disable(ctx->vcc);
> > > > return;
> > > > }
> > >
> > > I'm reviving this thread as I've been investigating a bug that appears
> > > related to this patch.
> > >
> > > Symptom: with a v6.8-rc5 kernel, if PLL fails locking, later on during
> > > atomic disable I get:
> > >
> > > [ 41.065198] [ cut here ]
> > > [ 41.069823] unbalanced disables for DOCK_SYS_1V8
> > > [ 41.074482] WARNING: CPU: 0 PID: 58 at drivers/regulator/core.c:2999
> > > _regulator_disable+0xf8/0x1d8
> > > [ 41.083457] Modules linked in: smsc smsc95xx usbnet mii imx_cpufreq_dt
> > > exc3000 imx8mm_thermal snd_soc_tlv320aic3x_spi snd_soc_tlv320aic3x_i2c
> > > snd_soc_tlv320aic3x tmp103 snd_soc_simple_card snd_soc_simple_card_utils
> > > fsl_ldb rtc_snvs snvs_pwrkey snd_soc_fsl_sai imx8mp_interconnect
> > > snd_soc_fsl_utils imx_interconnect imx_pcm_dma rtc_rs5c372 ti_sn65dsi83
> > > pwm_imx27 st_pressure_spi st_sensors_spi st_pressure_i2c st_pressure
> > > st_sensors_i2c industrialio_triggered_buffer lm75 kfifo_buf st_sensors
> > > opt3001 panel_simple etnaviv gpu_sched iio_hwmon governor_userspace
> > > imx_bus imx8mp_hdmi_tx dw_hdmi drm_display_helper samsung_dsim imx_sdma
> > > imx_lcdif drm_dma_helper imx8mp_hdmi_pvi drm_kms_helper drm
> > > drm_panel_orientation_quirks fsl_imx8_ddr_perf caam error sbs_battery
> > > pwm_bl backlight ltc2497 ltc2497_core crct10dif_ce
> > > [ 41.157281] CPU: 0 PID: 58 Comm: kworker/0:2 Not tainted 6.8.0-rc5+ #7
> > > [ 41.170339] Workqueue: events drm_mode_rmfb_work_fn [drm]
> > > [ 41.175798] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
> > > BTYPE=--)
> > > [ 41.182762] pc : _regulator_disable+0xf8/0x1d8
> > > [ 41.187209] lr : _regulator_disable+0xf8/0x1d8
> > > [ 41.191654] sp : 800081aaba90
> > > [ 41.194967] x29: 800081aaba90 x28: x27:
> > > 02647e80
> > > [ 41.202109] x26: 02d7a180 x25: 037858a0 x24:
> > > 800079748ac8
> > > [ 41.209250] x23: 02647ed8 x22: 0263f800 x21:
> > > 0373d000
> > > [ 41.216392] x20: 0373d000 x19: 01de6480 x18:
> > > 0006
> > > [ 41.223533] x17: x16: 1fffe03423e1 x15:
> > > 800081aab520
> > > [ 41.230674] x14: x13: 3856315f5359535f x12:
> > > 4b434f4420726f66
> > > [ 41.237815] x11: 2073656c62617369 x10: 8000814647a0 x9 :
> > > 8000801b10e0
> > > [ 41.244957] x8 : 8000814bc7a0 x7 : 00017fe8 x6 :
> > > 8000814bc7a0
> > > [ 41.252098] x5 : x4 : x3 :
> > >
> > > [ 41.259239] x2 : x1 : x0 :
> > > 011b6600
> > > [ 41.266380] Call trace:
> > > [ 41.268826] _regulator_disable+0xf8/0x1d8
> > > [ 41.272925] regulator_disable+0x4c/0x98
> > > [ 41.276850] sn65dsi83_atomic_disable+0x70/0xc0 [ti_sn65dsi83]
> > > [ 41.282692] drm_atomic_bridge_chain_disable+0x78/0x110 [drm]
> > > [ 41.288481] disable_outputs+0x100/0x350 [drm_kms_helper]
> > > [ 41.293902] drm_atomic_helper_commit_tail_rpm+0x2c/0xb0
> > > [drm_kms_helper]
> > > [ 41.300705] commit_tail+0xac/0x1a0 [drm_kms_helper]
> > > [ 41.305685] drm_atomic_helper_commit+0x16c/0x188 [drm_kms_helper]
> > > [ 41.311881] drm_atomic_commit+0xac/0xf0 [drm]
> > > [ 41.316365] drm_framebuffer_remove+0x464/0x550 [drm]
> > > [ 41.321458] drm_mode_rmfb_work_fn+0x84/0xb0 [drm]
> > > [ 41.326291] process_one_work+0x148/0x3b8
> > > [ 41.330309] worker_thread+0x32c/0x450
> > > [ 41.334061] kthread+0x11c
Re: [PATCH] drm/amdgpu: Fix assignment errors in 'si_common_early_init' functions
Am 28.02.24 um 02:44 schrieb Lu Yao: uvd_ctx_rreg/uvd_ctx_wreg correct value requires function pointer. Yeah, but that is completely irrelevant here. We usually don't use the & for function pointers since that is unnecessary in C. Regards, Christian. Signed-off-by: Lu Yao --- drivers/gpu/drm/amd/amdgpu/si.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c index a757526153e5..455d49f7bd9c 100644 --- a/drivers/gpu/drm/amd/amdgpu/si.c +++ b/drivers/gpu/drm/amd/amdgpu/si.c @@ -2032,8 +2032,8 @@ static int si_common_early_init(void *handle) adev->pcie_wreg = &si_pcie_wreg; adev->pciep_rreg = &si_pciep_rreg; adev->pciep_wreg = &si_pciep_wreg; - adev->uvd_ctx_rreg = si_uvd_ctx_rreg; - adev->uvd_ctx_wreg = si_uvd_ctx_wreg; + adev->uvd_ctx_rreg = &si_uvd_ctx_rreg; + adev->uvd_ctx_wreg = &si_uvd_ctx_wreg; adev->didt_rreg = NULL; adev->didt_wreg = NULL;
Re: [PATCH] drm/i915/ttm: Fix TTM_PL_FLAG_DESIRED
Am 27.02.24 um 21:26 schrieb Ville Syrjala:
From: Ville Syrjälä
inlined from ‘i915_ttm_get_pages’ at
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: warning: ‘places[0].flags’
is used uninitialized [-Wuninitialized]
165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
| ~^~
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_get_pages’:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:837:26: note: ‘places’ declared here
837 | struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
| ^~
Furhermore we then proceed to call i915_ttm_place_from_region() which
memset()s the whole thing back to zero anyway. So in the end we lose
the TTM_PL_FLAG_DESIRED flag (and fortunately also whatever else stack
garbage happened to be in the flags at this point).
No idea what functional changes this will result in...
I've already send out the same patch yesterday. Please review that one.
Sorry for the noise, didn't realized that i915_ttm_place_from_region()
was initializing the flags and not the caller while converting this.
Thanks,
Christian.
Cc: Somalapuram Amaranath
Cc: Christian König
Cc: Zack Rusin
Cc: Thomas Zimmermann
Cc: Thomas Hellström
Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27dcfd8a34bb..e6f177183c0f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -162,10 +162,10 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
unsigned int flags = obj->flags;
unsigned int i;
- places[0].flags |= TTM_PL_FLAG_DESIRED;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
obj->mm.region, &places[0], obj->bo_offset,
obj->base.size, flags);
+ places[0].flags |= TTM_PL_FLAG_DESIRED;
/* Cache this on object? */
for (i = 0; i < num_allowed; ++i) {
[PATCH v3 2/2] drm/omapdrm: Fix console with deferred ops
Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
stopped console from updating for command mode displays because there is
no damage handling in fb_sys_write() unlike we had earlier in
drm_fb_helper_sys_write().
Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and
FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the
FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly
for write-combine.
Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
Suggested-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/Kconfig | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 28 ++--
drivers/video/fbdev/core/Kconfig | 6 ++
include/linux/fb.h | 4
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -4,7 +4,7 @@ config DRM_OMAP
depends on DRM && OF
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
- select FB_DMAMEM_HELPERS if DRM_FBDEV_EMULATION
+ select FB_DMAMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -51,6 +51,10 @@ static void pan_worker(struct work_struct *work)
omap_gem_roll(bo, fbi->var.yoffset * npages);
}
+FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS(omap_fbdev,
+ drm_fb_helper_damage_range,
+ drm_fb_helper_damage_area)
+
static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
{
@@ -78,11 +82,9 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo
*var,
static int omap_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
- struct drm_fb_helper *helper = info->par;
- struct drm_framebuffer *fb = helper->fb;
- struct drm_gem_object *bo = drm_gem_fb_get_obj(fb, 0);
+ vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
- return drm_gem_mmap_obj(bo, omap_gem_mmap_size(bo), vma);
+ return fb_deferred_io_mmap(info, vma);
}
static void omap_fbdev_fb_destroy(struct fb_info *info)
@@ -94,6 +96,7 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
DBG();
+ fb_deferred_io_cleanup(info);
drm_fb_helper_fini(helper);
omap_gem_unpin(bo);
@@ -104,15 +107,19 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
kfree(fbdev);
}
+/*
+ * For now, we cannot use FB_DEFAULT_DEFERRED_OPS and fb_deferred_io_mmap()
+ * because we use write-combine.
+ */
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_DMAMEM_OPS_RDWR,
+ __FB_DEFAULT_DEFERRED_OPS_RDWR(omap_fbdev),
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
- __FB_DEFAULT_DMAMEM_OPS_DRAW,
+ __FB_DEFAULT_DEFERRED_OPS_DRAW(omap_fbdev),
.fb_ioctl = drm_fb_helper_ioctl,
.fb_mmap= omap_fbdev_fb_mmap,
.fb_destroy = omap_fbdev_fb_destroy,
@@ -213,6 +220,15 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
fbi->fix.smem_start = dma_addr;
fbi->fix.smem_len = bo->size;
+ /* deferred I/O */
+ helper->fbdefio.delay = HZ / 20;
+ helper->fbdefio.deferred_io = drm_fb_helper_deferred_io;
+
+ fbi->fbdefio = &helper->fbdefio;
+ ret = fb_deferred_io_init(fbi);
+ if (ret)
+ goto fail;
+
/* if we have DMM, then we can use it for scrolling by just
* shuffling pages around in DMM rather than doing sw blit.
*/
diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig
--- a/drivers/video/fbdev/core/Kconfig
+++ b/drivers/video/fbdev/core/Kconfig
@@ -144,6 +144,12 @@ config FB_DMAMEM_HELPERS
select FB_SYS_IMAGEBLIT
select FB_SYSMEM_FOPS
+config FB_DMAMEM_HELPERS_DEFERRED
+ bool
+ depends on FB_CORE
+ select FB_DEFERRED_IO
+ select FB_DMAMEM_HELPERS
+
config FB_IOMEM_FOPS
tristate
depends on FB_CORE
diff --git a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -686,6 +686,10 @@ extern int fb_deferred_io_fsync(struct file *file, loff_t
start,
__FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range, sys) \
__FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area, sys)
+#define
[PATCH v3 1/2] drm/omapdrm: Fix console by implementing fb_dirty
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
custom fb helper").
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update
logic")
Reviewed-by: Thomas Zimmermann
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -238,8 +238,20 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
return ret;
}
+static int omap_fbdev_dirty(struct drm_fb_helper *helper, struct drm_clip_rect
*clip)
+{
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty)
+ return helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip,
1);
+
+ return 0;
+}
+
static const struct drm_fb_helper_funcs omap_fb_helper_funcs = {
.fb_probe = omap_fbdev_create,
+ .fb_dirty = omap_fbdev_dirty,
};
static struct drm_fb_helper *get_fb(struct fb_info *fbi)
--
2.43.1
[PATCH v3 0/2] Fixes for omapdrm console
Here are two fixes for omapdrm for missing drm_framebuffer_funcs.dirty that needs to be paired with omap_framebuffer_dirty(), and to add FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS so things behave as earlier with drm_fb_helper_sys_write(). Without these fixes, the console won't update for the command mode displays. And likely mmap() using writes can miss updates as noted by Thomas. Regards, Tony Changes since v2: - Fix cache issue noted by Tomi using custom omap_fbdev_fb_mmap() as suggested by Thomas - Add FB_DMAMEM_HELPERS_DEFERRED Kconfig option and use it for omapdrm as noted by Thomas Changes since v1: - Add FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS to use with FB_DEFAULT_DEFERRED_OPS as suggested by Thomas Tony Lindgren (2): drm/omapdrm: Fix console by implementing fb_dirty drm/omapdrm: Fix console with deferred ops drivers/gpu/drm/omapdrm/Kconfig | 2 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 40 +++- drivers/video/fbdev/core/Kconfig | 6 + include/linux/fb.h | 4 +++ 4 files changed, 45 insertions(+), 7 deletions(-) -- 2.43.1
[PATCH v2] drm: tests: Fix invalid printf format specifiers in KUnit tests
The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
which was then updated to be an 'unsigned long' to avoid 64-bit
multiplication division helpers.
However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the
'%d' or '%llu' format specifiers, the former of which is always wrong,
and the latter is no longer correct now that ps is no longer a u64. Fix
these to all use '%lu'.
Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the
message. gcc and clang warns if a printf format string is empty, so
give these some more detailed error messages, which should be more
useful anyway.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Fixes: fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
Reviewed-by: Matthew Auld
Acked-by: Christian König
Tested-by: Guenter Roeck
Reviewed-by: Justin Stitt
Signed-off-by: David Gow
---
Changes since v1:
https://lore.kernel.org/linux-kselftest/20240221092728.1281499-8-david...@google.com/
- Split this patch out, as the others have been applied already.
- Rebase on 6.8-rc6
- Add everyone's {Reviewed,Acked,Tested}-by tags. Thanks!
---
drivers/gpu/drm/tests/drm_buddy_test.c | 14 +++---
drivers/gpu/drm/tests/drm_mm_test.c| 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 2f32fb2f12e7..3dbfa3078449 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -55,30 +55,30 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
KUNIT_ASSERT_FALSE_MSG(test,
drm_buddy_alloc_blocks(&mm, 0, mm_size,
ps, ps, list, 0),
- "buddy_alloc hit an error size=%u\n",
+ "buddy_alloc hit an error size=%lu\n",
ps);
} while (++i < n_pages);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
3 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%u\n", 3 * ps);
+ "buddy_alloc didn't error size=%lu\n", 3 * ps);
drm_buddy_free_list(&mm, &middle);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
3 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%u\n", 3 * ps);
+ "buddy_alloc didn't error size=%lu\n", 3 * ps);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
2 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%u\n", 2 * ps);
+ "buddy_alloc didn't error size=%lu\n", 2 * ps);
drm_buddy_free_list(&mm, &right);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
3 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%u\n", 3 * ps);
+ "buddy_alloc didn't error size=%lu\n", 3 * ps);
/*
* At this point we should have enough contiguous space for 2 blocks,
* however they are never buddies (since we freed middle and right) so
@@ -87,13 +87,13 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
2 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%u\n", 2 * ps);
+ "buddy_alloc hit an error size=%lu\n", 2 * ps);
drm_buddy_free_list(&mm, &left);
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size,
3 * ps, ps,
&allocated,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%u\n", 3 * ps);
+ "buddy_alloc hit an error size=%lu\n"
Re: [PATCH v2 2/3] drm/panel: panel-edp: Match edp_panels with panel name
On Wed, 28 Feb 2024 at 03:11, Hsin-Yi Wang wrote:
>
> It's found that some panels have variants that they share the same panel id
> although their EDID and names are different. When matching generic edp
> panels, we should first match with both panel id and panel name by checking
> if edid contains the name string. If not found, match with panel id only.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> v1->v2:
> match with panel name instead of crc hash.
> Note that we can't directly use drm_edid_get_monitor_name(), because some
> panel store the name after EDID_DETAIL_MONITOR_STRING instead of
> EDID_DETAIL_MONITOR_NAME.
> ---
> drivers/gpu/drm/drm_edid.c| 69 +++
> drivers/gpu/drm/panel/panel-edp.c | 44 +---
> include/drm/drm_edid.h| 2 +-
> 3 files changed, 54 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 15b97c8ed993..c4126475ff0a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2764,7 +2764,19 @@ const struct drm_edid *drm_edid_read(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_edid_read);
>
> -static u32 edid_extract_panel_id(const struct edid *edid)
> +/**
> + * edid_extract_panel_id - Extract a panel's ID from EDID
> + * @edid: EDID used to extract the panel's ID.
> + *
> + * Extract panel ID from EDID.
> + *
> + * Return: A 32-bit ID that should be different for each make/model of panel.
> + * See the functions drm_edid_encode_panel_id() and
> + * drm_edid_decode_panel_id() for some details on the structure of
> this
> + * ID.
> + */
> +
> +u32 edid_extract_panel_id(const struct edid *edid)
drm_edid_extract_panel_id(), please
> {
> /*
> * We represent the ID as a 32-bit number so it can easily be compared
[skipeed the rest, LGTM]
--
With best wishes
Dmitry
Re: [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console
On Tue, Feb 27, 2024 at 6:38 AM Thomas Zimmermann wrote:
>
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
> for vmap and mmap have been posted at [1][2]
>
> Most DRM drivers and memory managers acquire the buffer object's
> reservation lock within their GEM pin and unpin callbacks. This
> violates dma-buf locking semantics. We get away with it because PRIME
> does not provide pin/unpin, but attach/detach, for which the locking
> semantics is correct.
>
> Patches 1 to 8 rework DRM GEM code in various implementations to
> acquire the reservation lock when entering the pin and unpin callbacks.
> This prepares them for the next patch. Drivers that are not affected
> by these patches either don't acquire the reservation lock (amdgpu)
> or don't need preparation (loongson).
>
> Patch 9 moves reservation locking from the GEM pin/unpin callbacks
> into drm_gem_pin() and drm_gem_unpin(). As PRIME uses these functions
> internally it still gets the reservation lock.
>
> With the updated GEM callbacks, the rest of the patchset fixes the
> fbdev emulation's buffer locking. Fbdev emulation needs to keep its
> GEM buffer object inplace while updating its content. This required
> a implicit pinning and apparently amdgpu didn't do this at all.
>
> Patch 10 introduces drm_client_buffer_vmap_local() and _vunmap_local().
> The former function map a GEM buffer into the kernel's address space
> with regular vmap operations, but keeps holding the reservation lock.
> The _vunmap_local() helper undoes the vmap and releases the lock. The
> updated GEM callbacks make this possible. Between the two calls, the
> fbdev emulation can update the buffer content without have the buffer
> moved or evicted. Update fbdev-generic to use vmap_local helpers,
> which fix amdgpu. The idea of adding a "local vmap" has previously been
> attempted at [3] in a different form.
>
> Patch 11 adds implicit pinning to the DRM client's regular vmap
> helper so that long-term vmap'ed buffers won't be evicted. This only
> affects fbdev-dma, but GEM DMA helpers don't require pinning. So
> there are no practical changes.
>
> Patches 12 and 13 remove implicit pinning from the vmap and vunmap
> operations in gem-vram and qxl. These pin operations are not supposed
> to be part of vmap code, but were required to keep the buffers in place
> for fbdev emulation. With the conversion o ffbdev-generic to to
> vmap_local helpers, that code can finally be removed.
>
> Tested with amdgpu, nouveau, radeon, simpledrm and vc4.
>
> [1] https://patchwork.freedesktop.org/series/106371/
> [2] https://patchwork.freedesktop.org/series/116001/
> [3] https://patchwork.freedesktop.org/series/84732/
>
> Thomas Zimmermann (13):
> drm/gem-shmem: Acquire reservation lock in GEM pin/unpin callbacks
> drm/gem-vram: Acquire reservation lock in GEM pin/unpin callbacks
> drm/msm: Provide msm_gem_get_pages_locked()
> drm/msm: Acquire reservation lock in GEM pin/unpin callback
> drm/nouveau: Provide nouveau_bo_{pin,unpin}_locked()
> drm/nouveau: Acquire reservation lock in GEM pin/unpin callbacks
> drm/qxl: Provide qxl_bo_{pin,unpin}_locked()
> drm/qxl: Acquire reservation lock in GEM pin/unpin callbacks
> drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()
> drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
> drm/client: Pin vmap'ed GEM buffers
> drm/gem-vram: Do not pin buffer objects for vmap
> drm/qxl: Do not pin buffer objects for vmap
>
> drivers/gpu/drm/drm_client.c| 92 ++---
> drivers/gpu/drm/drm_fbdev_generic.c | 4 +-
> drivers/gpu/drm/drm_gem.c | 34 +++-
> drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 101 ++--
> drivers/gpu/drm/drm_internal.h | 2 +
> drivers/gpu/drm/loongson/lsdc_gem.c | 13 +--
> drivers/gpu/drm/msm/msm_gem.c | 20 ++---
> drivers/gpu/drm/msm/msm_gem.h | 4 +-
> drivers/gpu/drm/msm/msm_gem_prime.c | 20 +++--
> drivers/gpu/drm/nouveau/nouveau_bo.c| 43 +++---
> drivers/gpu/drm/nouveau/nouveau_bo.h| 2 +
> drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +-
> drivers/gpu/drm/qxl/qxl_object.c| 26 +++---
> drivers/gpu/drm/qxl/qxl_object.h| 2 +
> drivers/gpu/drm/qxl/qxl_prime.c | 4 +-
> drivers/gpu/drm/radeon/radeon_prime.c | 11 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 25 ++
> include/drm/drm_client.h| 10 +++
> include/drm/drm_gem.h | 3 +
> include/drm/drm_gem_shmem_helper.h | 7 +-
> 21 files changed, 265 insertions(+), 172 deletions(-)
>
>
> base-commit: 7291e2e67dff0ff573900266382c9c9248a7dea5
> prerequisite-patch-id: bdfa0e6341b30cc9d7647172760b3473007c1216
> prerequisite-patch
Re: [PATCH 09/13] drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the buffer object's reservation lock in drm_gem_pin() and
> remove locking the drivers' GEM callbacks where necessary. Same for
> unpin().
>
> DRM drivers and memory managers modified by this patch will now have
> correct dma-buf locking semantics: the caller is responsible for
> holding the reservation lock when calling the pin or unpin callback.
>
> DRM drivers and memory managers that are not modified will now be
> protected against concurent invocation of their pin and unpin callbacks.
>
> PRIME does not implement struct dma_buf_ops.pin, which requires
> the caller to hold the reservation lock. It does implement struct
> dma_buf_ops.attach, which requires to callee to acquire the
> reservation lock. The PRIME code uses drm_gem_pin(), so locks
> are now taken as specified. Same for unpin and detach.
>
> The patch harmonizes GEM pin and unpin to have non-interruptible
> reservation locking across all drivers, as is already the case for
> vmap and vunmap. This affects gem-shmem, gem-vram, loongson, qxl and
> radeon.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem.c | 22 --
> drivers/gpu/drm/drm_gem_vram_helper.c | 15 +--
> drivers/gpu/drm/drm_internal.h | 2 ++
> drivers/gpu/drm/loongson/lsdc_gem.c | 13 ++---
> drivers/gpu/drm/msm/msm_gem_prime.c | 4
> drivers/gpu/drm/nouveau/nouveau_prime.c | 11 ---
> drivers/gpu/drm/qxl/qxl_prime.c | 14 +-
> drivers/gpu/drm/radeon/radeon_prime.c | 11 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 25 ++---
> include/drm/drm_gem_shmem_helper.h | 11 +--
> 10 files changed, 33 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 44a948b80ee14..e0f80c6a7096f 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1161,7 +1161,7 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
> int indent,
> obj->funcs->print_info(p, indent, obj);
> }
>
> -int drm_gem_pin(struct drm_gem_object *obj)
> +int drm_gem_pin_locked(struct drm_gem_object *obj)
> {
> if (obj->funcs->pin)
> return obj->funcs->pin(obj);
> @@ -1169,12 +1169,30 @@ int drm_gem_pin(struct drm_gem_object *obj)
> return 0;
> }
>
> -void drm_gem_unpin(struct drm_gem_object *obj)
> +void drm_gem_unpin_locked(struct drm_gem_object *obj)
> {
> if (obj->funcs->unpin)
> obj->funcs->unpin(obj);
> }
>
> +int drm_gem_pin(struct drm_gem_object *obj)
> +{
> + int ret;
> +
> + dma_resv_lock(obj->resv, NULL);
> + ret = drm_gem_pin_locked(obj);
> + dma_resv_unlock(obj->resv);
> +
> + return ret;
> +}
> +
> +void drm_gem_unpin(struct drm_gem_object *obj)
> +{
> + dma_resv_lock(obj->resv, NULL);
> + drm_gem_unpin_locked(obj);
> + dma_resv_unlock(obj->resv);
> +}
> +
> int drm_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> {
> int ret;
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 15029d89badf8..5a16b3e0a4134 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -774,11 +774,6 @@
> EXPORT_SYMBOL(drm_gem_vram_simple_display_pipe_cleanup_fb);
> static int drm_gem_vram_object_pin(struct drm_gem_object *gem)
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> - int ret;
> -
> - ret = ttm_bo_reserve(&gbo->bo, true, false, NULL);
> - if (ret)
> - return ret;
>
> /*
> * Fbdev console emulation is the use case of these PRIME
> @@ -789,10 +784,7 @@ static int drm_gem_vram_object_pin(struct drm_gem_object
> *gem)
> * the buffer to be pinned to VRAM, implement a callback that
> * sets the flags accordingly.
> */
> - ret = drm_gem_vram_pin_locked(gbo, 0);
> - ttm_bo_unreserve(&gbo->bo);
> -
> - return ret;
> + return drm_gem_vram_pin_locked(gbo, 0);
> }
>
> /**
> @@ -803,13 +795,8 @@ static int drm_gem_vram_object_pin(struct drm_gem_object
> *gem)
> static void drm_gem_vram_object_unpin(struct drm_gem_object *gem)
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> - int ret;
>
> - ret = ttm_bo_reserve(&gbo->bo, true, false, NULL);
> - if (ret)
> - return;
> drm_gem_vram_unpin_locked(gbo);
> - ttm_bo_unreserve(&gbo->bo);
> }
>
> /**
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 8e4faf0a28e6c..40b2d3a274d6c 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -170,6 +170,8 @@ void drm_gem_release(struct drm_device *dev, struct
> drm_file *file_private);
> void drm_gem_print_info(st
Re: [PATCH 08/13] drm/qxl: Acquire reservation lock in GEM pin/unpin callbacks
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the reservation lock directly in GEM pin callback. Same for
> unpin. Prepares for further changes.
>
> Dma-buf locking semantics require callers to hold the buffer's
> reservation lock when invoking the pin and unpin callbacks. Prepare
> qxl accordingly by pushing locking out of the implementation. A
> follow-up patch will fix locking for all GEM code at once.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/qxl/qxl_prime.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
> index 9169c26357d36..f2646603e12eb 100644
> --- a/drivers/gpu/drm/qxl/qxl_prime.c
> +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> @@ -31,15 +31,27 @@
> int qxl_gem_prime_pin(struct drm_gem_object *obj)
> {
> struct qxl_bo *bo = gem_to_qxl_bo(obj);
> + int r;
>
> - return qxl_bo_pin(bo);
> + r = qxl_bo_reserve(bo);
> + if (r)
> + return r;
> + r = qxl_bo_pin_locked(bo);
> + qxl_bo_unreserve(bo);
> +
> + return r;
> }
>
> void qxl_gem_prime_unpin(struct drm_gem_object *obj)
> {
> struct qxl_bo *bo = gem_to_qxl_bo(obj);
> + int r;
>
> - qxl_bo_unpin(bo);
> + r = qxl_bo_reserve(bo);
> + if (r)
> + return;
> + qxl_bo_unpin_locked(bo);
> + qxl_bo_unreserve(bo);
> }
It looks like gem_prime_pin/unpin is largely the same between a lot of
drivers now. That might be a nice cleanup in the future.
z
Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch
On 27/2/24 21:47, Hans de Goede wrote: > Hi, > > On 2/27/24 02:06, Daniel van Vugt wrote: >> On 27/2/24 02:23, Hans de Goede wrote: >>> Hi All, >>> >>> On 2/2/24 09:53, Daniel van Vugt wrote: Until now, deferred console takeover only meant defer until there is output. But that risks stepping on the toes of userspace splash screens, as console messages may appear before the splash screen. So check for the "splash" parameter (as used by Plymouth) and if present then extend the deferral until the first switch. >>> >>> Daniel, thank you for your patch but I do not believe that this >>> is the right solution. Deferring fbcon takeover further then >>> after the first text is output means that any errors about e.g. >>> a corrupt initrd or the kernel erroring out / crashing will not >>> be visible. >> >> That's not really correct. If a boot failure has occurred after the splash >> then >> pressing escape shows the log. > > Hmm, I guess this is with the latest plymouth which has a builtin terminal > emulator for kernels without VT support ? Pressing ESC does not to a VC > switch and AFAICT that is what you are triggering on to allow fbcon takeover > after this patches. > >> If a boot failure has occurred before the splash >> then it can be debugged visually by rebooting without the "splash" parameter. > > Which requires the user to know this and requires the user to know how to > edit kernel cmdline parameters in e.g. grub. This is not a good user > experience. We want inexperienced users to just be able to point > a phone camera at the screen and take a picture of the errors. As the person who contributes most to Ubuntu bug triage I have a pretty good idea of what users experience. And when they do experience boot failures it's either with a blank screen already (because userspace, not the kernel's fault), or they report an error message to us that's not relevant to the real failure. In both cases our users understand (or learn quickly) the ease with which they can reboot either to recovery mode, or a previous kernel. We then direct them to collect the full log of the failed boot. Because even if they were booting with a full text console, most of those bugs don't reveal themselves on the console. If they did then they'd be visible in the system journal along with everything else. What is not a "good user experience" is the boot messages people are shown on every boot. > > >>> When the kernel e.g. oopses or panics because of not finding >>> its rootfs (I tested the latter option when writing the original >>> deferred fbcon takeover code) then fbcon must takeover and >>> print the messages from the dying kernel so that the user has >>> some notion of what is going wrong. >> >> Indeed, just reboot without the "splash" parameter to do that. > > Again not something beginning Linux users will be able to do, > what happened to "Ubuntu: Linux for Human Beings" ? It is more user-friendly than it sounds. Just reboot, trigger the grub menu and select recovery mode or an older kernel (which is always available). I think some boot failures also take you to the grub menu automatically next time? > >>> And since your patch seems to delay switching till the first >>> vc-switch this means that e.g. even after say gdm refusing >>> to start because of issues there still will be no text >>> output. This makes debugging various issues much harder. >> >> I've debugged many gdm failures and it is never useful to use the console for >> those. Reboot and get the system journal instead. > > But users will not see any errors now, meaning they don't > even know where to begin with troubleshooting ... Indeed. I deal with those users every day and they log their bugs against the wrong components, understandably. We then work with them to triage and reassign the issue to the right place. > >>> Moreover Fedora has been doing flickerfree boot for many >>> years without needing this. >> >> I believe Fedora has a mostly working solution, but not totally reliable, as >> mentioned in the commit message: >> >> "even systems whose splash exists in initrd may not be not immune because >> they >> still rely on racing against all possible kernel messages that might >> trigger the fbcon takeover" > > Only very serious kernel errors like oopses or panics will > trigger the takeover and that is *exactly* what we want. > > There is a race where plymouth may hide such vary serious > messages, if plymouth does manage to start before the errors, > but that is actually an existing issue which we don't want > to make bigger by *always* hiding such errors. > >>> The kernel itself will be quiet as long as you set >>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this >>> to 4 which means any kernel pr_err() or dev_err() >>> messages will get through and since there are quite >>> a few false positives of those Ubuntu really needs >>> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of: >>> https://bugs.launc
[PATCH] drm/amdgpu: Fix assignment errors in 'si_common_early_init' functions
uvd_ctx_rreg/uvd_ctx_wreg correct value requires function pointer. Signed-off-by: Lu Yao --- drivers/gpu/drm/amd/amdgpu/si.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c index a757526153e5..455d49f7bd9c 100644 --- a/drivers/gpu/drm/amd/amdgpu/si.c +++ b/drivers/gpu/drm/amd/amdgpu/si.c @@ -2032,8 +2032,8 @@ static int si_common_early_init(void *handle) adev->pcie_wreg = &si_pcie_wreg; adev->pciep_rreg = &si_pciep_rreg; adev->pciep_wreg = &si_pciep_wreg; - adev->uvd_ctx_rreg = si_uvd_ctx_rreg; - adev->uvd_ctx_wreg = si_uvd_ctx_wreg; + adev->uvd_ctx_rreg = &si_uvd_ctx_rreg; + adev->uvd_ctx_wreg = &si_uvd_ctx_wreg; adev->didt_rreg = NULL; adev->didt_wreg = NULL; -- 2.25.1
[PATCH] drm/imagination: Kconfig: add 'PAGE_SIZE=4K' dependency
When 'PAGE_SIZE=64K',the following compilation error occurs:
"
../drivers/gpu/drm/imagination/pvr_fw_mips.c: In function
‘pvr_mips_fw_process’:
../drivers/gpu/drm/imagination/pvr_fw_mips.c:140:60: error: array
subscript 0 is outside the bounds of an interior zero-length array
‘dma_addr_t[0]’ {aka ‘long long unsigned int[]’}
[-Werror=zero-length-bounds]
140 | boot_data->pt_phys_addr[page_nr] =
mips_data->pt_dma_addr[src_page_nr] +
~~^
In file included from ../drivers/gpu/drm/imagination/pvr_fw_mips.c:6:
../drivers/gpu/drm/imagination/pvr_fw_mips.h:30:13: note: while
referencing ‘pt_dma_addr’
30 | dma_addr_t pt_dma_addr[PVR_MIPS_PT_PAGE_COUNT];
"
This is because 'PVR_MIPS_PT_PAGE_COUNT' is defined as
'(ROGUE_MIPSFW_MAX_NUM_PAGETABLE_PAGES * ROGUE_MIPSFW_PAGE_SIZE_4K) \
>> PAGE_SHIFT', and under the above conditions, 'PAGE_SHIFT' is '16',
'ROGUE_MIPSFW_MAX_NUM_PAGETABLE_PAGES' is '4','ROGUE_MIPSFW_PAGE_SIZE_4K'
is '4096',so 'PVR_MIPS_PT_PAGE_COUNT' is '0' causing the member
'pt_dma_addr' to be incorrectly defined.
Signed-off-by: Lu Yao
---
drivers/gpu/drm/imagination/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imagination/Kconfig
b/drivers/gpu/drm/imagination/Kconfig
index 3bfa2ac212dc..e585922f634d 100644
--- a/drivers/gpu/drm/imagination/Kconfig
+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -3,7 +3,7 @@
config DRM_POWERVR
tristate "Imagination Technologies PowerVR (Series 6 and later) & IMG
Graphics"
- depends on ARM64
+ depends on (ARM64 && ARM64_PAGE_SHIFT=12)
depends on DRM
depends on PM
select DRM_EXEC
--
2.25.1
Re: [PATCH v2 1/3] drm_edid: Support getting EDID through ddc without connector
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> Some panels are interested in the EDID during early probe when connector
> is still unknown.
>
> Add a function drm_get_edid_no_connector() to get edid without connector.
> No functional change for existing usage.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> v1->v2:
> add a function to return the entire edid without updating connector.
> ---
> drivers/gpu/drm/drm_edid.c | 45 --
> include/drm/drm_edid.h | 1 +
> 2 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1ad94473e400..15b97c8ed993 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2364,7 +2364,7 @@ static struct edid *_drm_do_get_edid(struct
> drm_connector *connector,
> struct edid *edid, *new;
> size_t alloc_size = EDID_LENGTH;
>
> - override = drm_edid_override_get(connector);
> + override = connector ? drm_edid_override_get(connector) : false;
typo: should be NULL here. I'll update in the next version with other comments.
> if (override) {
> alloc_size = override->size;
> edid = kmemdup(override->edid, alloc_size, GFP_KERNEL);
> @@ -2385,18 +2385,20 @@ static struct edid *_drm_do_get_edid(struct
> drm_connector *connector,
> if (status == EDID_BLOCK_READ_FAIL)
> goto fail;
>
> - /* FIXME: Clarify what a corrupt EDID actually means. */
> - if (status == EDID_BLOCK_OK || status == EDID_BLOCK_VERSION)
> - connector->edid_corrupt = false;
> - else
> - connector->edid_corrupt = true;
> + if (connector) {
> + /* FIXME: Clarify what a corrupt EDID actually means. */
> + if (status == EDID_BLOCK_OK || status == EDID_BLOCK_VERSION)
> + connector->edid_corrupt = false;
> + else
> + connector->edid_corrupt = true;
>
> - if (!edid_block_status_valid(status, edid_block_tag(edid))) {
> - if (status == EDID_BLOCK_ZERO)
> - connector->null_edid_counter++;
> + if (!edid_block_status_valid(status, edid_block_tag(edid))) {
> + if (status == EDID_BLOCK_ZERO)
> + connector->null_edid_counter++;
>
> - connector_bad_edid(connector, edid, 1);
> - goto fail;
> + connector_bad_edid(connector, edid, 1);
> + goto fail;
> + }
> }
>
> if (!edid_extension_block_count(edid))
> @@ -2444,7 +2446,8 @@ static struct edid *_drm_do_get_edid(struct
> drm_connector *connector,
> }
>
> if (invalid_blocks) {
> - connector_bad_edid(connector, edid, num_blocks);
> + if (connector)
> + connector_bad_edid(connector, edid, num_blocks);
>
> edid = edid_filter_invalid_blocks(edid, &alloc_size);
> }
> @@ -2637,6 +2640,24 @@ struct edid *drm_get_edid(struct drm_connector
> *connector,
> }
> EXPORT_SYMBOL(drm_get_edid);
>
> +/**
> + * drm_get_edid_no_connector - get EDID data without updating connector
> status
> + * @adapter: I2C adapter to use for DDC
> + *
> + * Similar to drm_edid_read_ddc(), but not checking any connector status. Use
> + * this function to get EDID when connector is still unknown.
> + *
> + * Return: Pointer to valid EDID or NULL if we couldn't find any.
> + */
> +struct edid *drm_get_edid_no_connector(struct i2c_adapter *adapter)
> +{
> + if (!drm_probe_ddc(adapter))
> + return NULL;
> +
> + return _drm_do_get_edid(NULL, drm_do_probe_ddc_edid, adapter, NULL);
> +}
> +EXPORT_SYMBOL(drm_get_edid_no_connector);
> +
> /**
> * drm_edid_read_custom - Read EDID data using given EDID block read function
> * @connector: Connector to use
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 70ae6c290bdc..80c9e32ff80e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -565,6 +565,7 @@ struct edid *drm_do_get_edid(struct drm_connector
> *connector,
> void *data);
> struct edid *drm_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter);
> +struct edid *drm_get_edid_no_connector(struct i2c_adapter *adapter);
> u32 drm_edid_get_panel_id(struct i2c_adapter *adapter);
> struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> struct i2c_adapter *adapter);
> --
> 2.44.0.rc1.240.g4c46232300-goog
>
Re: [PATCH 1/2] drm_edid: Add a function to get EDID base block
On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula wrote:
>
> On Fri, 23 Feb 2024, Hsin-Yi Wang wrote:
> > It's found that some panels have variants that they share the same panel id
> > although their EDID and names are different. Besides panel id, now we need
> > the hash of entire EDID base block to distinguish these panel variants.
> >
> > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> > further use it to get panel id and/or the hash.
>
> Please reconsider the whole approach here.
>
> Please let's not add single-use special case functions to read an EDID
> base block.
>
> Please consider reading the whole EDID, using the regular EDID reading
> functions, and use that instead.
>
> Most likely you'll only have 1-2 blocks anyway. And you might consider
> caching the EDID in struct panel_edp if reading the entire EDID is too
> slow. (And if it is, this is probably sensible even if the EDID only
> consists of one block.)
>
> Anyway, please do *not* merge this as-is.
>
hi Jani,
I sent a v2 here implementing this method:
https://lore.kernel.org/lkml/20240228011133.1238439-2-hsi...@chromium.org/
We still have to read edid twice due to:
1. The first caller is in panel probe, at that time, connector is
still unknown, so we can't update connector status (eg. update
edid_corrupt).
2. It's possible that the connector can have some override
(drm_edid_override_get) to EDID, that is still unknown during the
first read.
> BR,
> Jani.
>
> >
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > drivers/gpu/drm/drm_edid.c| 55 +--
> > drivers/gpu/drm/panel/panel-edp.c | 8 +++--
> > include/drm/drm_edid.h| 3 +-
> > 3 files changed, 38 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 923c4423151c..55598ca4a5d1 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid
> > *edid)
> > }
> >
> > /**
> > - * drm_edid_get_panel_id - Get a panel's ID through DDC
> > - * @adapter: I2C adapter to use for DDC
> > + * drm_edid_get_panel_id - Get a panel's ID from EDID base block
> > + * @base_bock: EDID base block that contains panel ID.
> > *
> > - * This function reads the first block of the EDID of a panel and (assuming
> > + * This function uses the first block of the EDID of a panel and (assuming
> > * that the EDID is valid) extracts the ID out of it. The ID is a 32-bit
> > value
> > * (16 bits of manufacturer ID and 16 bits of per-manufacturer ID) that's
> > * supposed to be different for each different modem of panel.
> > *
> > + * Return: A 32-bit ID that should be different for each make/model of
> > panel.
> > + * See the functions drm_edid_encode_panel_id() and
> > + * drm_edid_decode_panel_id() for some details on the structure of
> > this
> > + * ID.
> > + */
> > +u32 drm_edid_get_panel_id(void *base_block)
> > +{
> > + return edid_extract_panel_id(base_block);
> > +}
> > +EXPORT_SYMBOL(drm_edid_get_panel_id);
> > +
> > +/**
> > + * drm_edid_get_base_block - Get a panel's EDID base block
> > + * @adapter: I2C adapter to use for DDC
> > + *
> > + * This function returns the first block of the EDID of a panel.
> > + *
> > * This function is intended to be used during early probing on devices
> > where
> > * more than one panel might be present. Because of its intended use it
> > must
> > - * assume that the EDID of the panel is correct, at least as far as the ID
> > - * is concerned (in other words, we don't process any overrides here).
> > + * assume that the EDID of the panel is correct, at least as far as the
> > base
> > + * block is concerned (in other words, we don't process any overrides
> > here).
> > *
> > * NOTE: it's expected that this function and drm_do_get_edid() will both
> > * be read the EDID, but there is no caching between them. Since we're only
> > * reading the first block, hopefully this extra overhead won't be too big.
> > *
> > - * Return: A 32-bit ID that should be different for each make/model of
> > panel.
> > - * See the functions drm_edid_encode_panel_id() and
> > - * drm_edid_decode_panel_id() for some details on the structure of
> > this
> > - * ID.
> > + * Caller should free the base block after use.
> > */
> > -
> > -u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
> > +void *drm_edid_get_base_block(struct i2c_adapter *adapter)
> > {
> > enum edid_block_status status;
> > void *base_block;
> > - u32 panel_id = 0;
> > -
> > - /*
> > - * There are no manufacturer IDs of 0, so if there is a problem
> > reading
> > - * the EDID then we'll just return 0.
> > - */
> >
> > base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
> > if (!base_block)
> > - return 0;
> > + return NULL;
> >
> > statu
[PATCH v2 1/3] drm_edid: Support getting EDID through ddc without connector
Some panels are interested in the EDID during early probe when connector
is still unknown.
Add a function drm_get_edid_no_connector() to get edid without connector.
No functional change for existing usage.
Signed-off-by: Hsin-Yi Wang
---
v1->v2:
add a function to return the entire edid without updating connector.
---
drivers/gpu/drm/drm_edid.c | 45 --
include/drm/drm_edid.h | 1 +
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1ad94473e400..15b97c8ed993 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2364,7 +2364,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
struct edid *edid, *new;
size_t alloc_size = EDID_LENGTH;
- override = drm_edid_override_get(connector);
+ override = connector ? drm_edid_override_get(connector) : false;
if (override) {
alloc_size = override->size;
edid = kmemdup(override->edid, alloc_size, GFP_KERNEL);
@@ -2385,18 +2385,20 @@ static struct edid *_drm_do_get_edid(struct
drm_connector *connector,
if (status == EDID_BLOCK_READ_FAIL)
goto fail;
- /* FIXME: Clarify what a corrupt EDID actually means. */
- if (status == EDID_BLOCK_OK || status == EDID_BLOCK_VERSION)
- connector->edid_corrupt = false;
- else
- connector->edid_corrupt = true;
+ if (connector) {
+ /* FIXME: Clarify what a corrupt EDID actually means. */
+ if (status == EDID_BLOCK_OK || status == EDID_BLOCK_VERSION)
+ connector->edid_corrupt = false;
+ else
+ connector->edid_corrupt = true;
- if (!edid_block_status_valid(status, edid_block_tag(edid))) {
- if (status == EDID_BLOCK_ZERO)
- connector->null_edid_counter++;
+ if (!edid_block_status_valid(status, edid_block_tag(edid))) {
+ if (status == EDID_BLOCK_ZERO)
+ connector->null_edid_counter++;
- connector_bad_edid(connector, edid, 1);
- goto fail;
+ connector_bad_edid(connector, edid, 1);
+ goto fail;
+ }
}
if (!edid_extension_block_count(edid))
@@ -2444,7 +2446,8 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
}
if (invalid_blocks) {
- connector_bad_edid(connector, edid, num_blocks);
+ if (connector)
+ connector_bad_edid(connector, edid, num_blocks);
edid = edid_filter_invalid_blocks(edid, &alloc_size);
}
@@ -2637,6 +2640,24 @@ struct edid *drm_get_edid(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_get_edid);
+/**
+ * drm_get_edid_no_connector - get EDID data without updating connector status
+ * @adapter: I2C adapter to use for DDC
+ *
+ * Similar to drm_edid_read_ddc(), but not checking any connector status. Use
+ * this function to get EDID when connector is still unknown.
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+struct edid *drm_get_edid_no_connector(struct i2c_adapter *adapter)
+{
+ if (!drm_probe_ddc(adapter))
+ return NULL;
+
+ return _drm_do_get_edid(NULL, drm_do_probe_ddc_edid, adapter, NULL);
+}
+EXPORT_SYMBOL(drm_get_edid_no_connector);
+
/**
* drm_edid_read_custom - Read EDID data using given EDID block read function
* @connector: Connector to use
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 70ae6c290bdc..80c9e32ff80e 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -565,6 +565,7 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
void *data);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
+struct edid *drm_get_edid_no_connector(struct i2c_adapter *adapter);
u32 drm_edid_get_panel_id(struct i2c_adapter *adapter);
struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
struct i2c_adapter *adapter);
--
2.44.0.rc1.240.g4c46232300-goog
[PATCH v2 2/3] drm/panel: panel-edp: Match edp_panels with panel name
It's found that some panels have variants that they share the same panel id
although their EDID and names are different. When matching generic edp
panels, we should first match with both panel id and panel name by checking
if edid contains the name string. If not found, match with panel id only.
Signed-off-by: Hsin-Yi Wang
---
v1->v2:
match with panel name instead of crc hash.
Note that we can't directly use drm_edid_get_monitor_name(), because some
panel store the name after EDID_DETAIL_MONITOR_STRING instead of
EDID_DETAIL_MONITOR_NAME.
---
drivers/gpu/drm/drm_edid.c| 69 +++
drivers/gpu/drm/panel/panel-edp.c | 44 +---
include/drm/drm_edid.h| 2 +-
3 files changed, 54 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 15b97c8ed993..c4126475ff0a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2764,7 +2764,19 @@ const struct drm_edid *drm_edid_read(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_edid_read);
-static u32 edid_extract_panel_id(const struct edid *edid)
+/**
+ * edid_extract_panel_id - Extract a panel's ID from EDID
+ * @edid: EDID used to extract the panel's ID.
+ *
+ * Extract panel ID from EDID.
+ *
+ * Return: A 32-bit ID that should be different for each make/model of panel.
+ * See the functions drm_edid_encode_panel_id() and
+ * drm_edid_decode_panel_id() for some details on the structure of this
+ * ID.
+ */
+
+u32 edid_extract_panel_id(const struct edid *edid)
{
/*
* We represent the ID as a 32-bit number so it can easily be compared
@@ -2783,60 +2795,7 @@ static u32 edid_extract_panel_id(const struct edid *edid)
(u32)edid->mfg_id[1] << 16 |
(u32)EDID_PRODUCT_ID(edid);
}
-
-/**
- * drm_edid_get_panel_id - Get a panel's ID through DDC
- * @adapter: I2C adapter to use for DDC
- *
- * This function reads the first block of the EDID of a panel and (assuming
- * that the EDID is valid) extracts the ID out of it. The ID is a 32-bit value
- * (16 bits of manufacturer ID and 16 bits of per-manufacturer ID) that's
- * supposed to be different for each different modem of panel.
- *
- * This function is intended to be used during early probing on devices where
- * more than one panel might be present. Because of its intended use it must
- * assume that the EDID of the panel is correct, at least as far as the ID
- * is concerned (in other words, we don't process any overrides here).
- *
- * NOTE: it's expected that this function and drm_do_get_edid() will both
- * be read the EDID, but there is no caching between them. Since we're only
- * reading the first block, hopefully this extra overhead won't be too big.
- *
- * Return: A 32-bit ID that should be different for each make/model of panel.
- * See the functions drm_edid_encode_panel_id() and
- * drm_edid_decode_panel_id() for some details on the structure of this
- * ID.
- */
-
-u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
-{
- enum edid_block_status status;
- void *base_block;
- u32 panel_id = 0;
-
- /*
-* There are no manufacturer IDs of 0, so if there is a problem reading
-* the EDID then we'll just return 0.
-*/
-
- base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
- if (!base_block)
- return 0;
-
- status = edid_block_read(base_block, 0, drm_do_probe_ddc_edid, adapter);
-
- edid_block_status_print(status, base_block, 0);
-
- if (edid_block_status_valid(status, edid_block_tag(base_block)))
- panel_id = edid_extract_panel_id(base_block);
- else
- edid_block_dump(KERN_NOTICE, base_block, 0);
-
- kfree(base_block);
-
- return panel_id;
-}
-EXPORT_SYMBOL(drm_edid_get_panel_id);
+EXPORT_SYMBOL(edid_extract_panel_id);
/**
* drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 3fb5fcd326a4..72ad552bff24 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -761,11 +761,13 @@ static void panel_edp_parse_panel_timing_node(struct
device *dev,
dev_err(dev, "Reject override mode: No display_timing found\n");
}
-static const struct edp_panel_entry *find_edp_panel(u32 panel_id);
+static bool edid_has_name(struct edid *edid, const char *panel_name);
+static const struct edp_panel_entry *find_edp_panel(u32 panel_id, struct edid
*edid);
static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
{
struct panel_desc *desc;
+ struct edid *edid;
u32 panel_id;
char vend[4];
u16 product_id;
@@ -795,15 +797,19 @@ static int generic_edp_panel_probe(struct device *dev,
struct panel_edp *panel)
goto exit;
}
-
[PATCH v2 0/3] Match panel with id and name
This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
product id. One of them requires an overridden mode, while the other should
use the mode directly from edid.
Match the panel for both name and id. If not found, fallback to match id.
v1: https://lore.kernel.org/lkml/20240223223958.3887423-1-hsi...@chromium.org/T/
Hsin-Yi Wang (3):
drm_edid: Support getting EDID through ddc without connector
drm/panel: panel-edp: Match edp_panels with panel name
drm/panel: panel-edp: Fix AUO 0x405c panel naming and add a variant
drivers/gpu/drm/drm_edid.c| 114 --
drivers/gpu/drm/panel/panel-edp.c | 61 ++--
include/drm/drm_edid.h| 3 +-
3 files changed, 104 insertions(+), 74 deletions(-)
--
2.44.0.rc1.240.g4c46232300-goog
[PATCH v2 3/3] drm/panel: panel-edp: Fix AUO 0x405c panel naming and add a variant
There are 2 different AUO panels using the same panel id. One of the
variants requires using overridden modes to resolve glitching issue as
described in commit 70e0d5550f5c ("drm/panel-edp: Add auo_b116xa3_mode").
Other variants should use the modes parsed from EDID.
Signed-off-by: Hsin-Yi Wang
---
v2: new
---
drivers/gpu/drm/panel/panel-edp.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 72ad552bff24..e39af92342e8 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1013,6 +1013,19 @@ static const struct panel_desc auo_b101ean01 = {
},
};
+static const struct drm_display_mode auo_b116xa3_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1990,7 +2003,9 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, &delay_200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, &delay_200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, &delay_200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAK01.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAN04.0 "),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAK01.0 ",
+&auo_b116xa3_mode),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x435c, &delay_200_500_e50, "Unknown"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, &delay_200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50,
"B116XAN06.1"),
--
2.44.0.rc1.240.g4c46232300-goog
[PATCH v2] drm/i915/guc: Use context hints for GT freq
Allow user to provide a low latency context hint. When set, KMD
sends a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.
We need to enable the use of SLPC Compute strategy during init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new param-
I915_PARAM_HAS_CONTEXT_FREQ_HINTS. This flag is true for all guc submission
enabled platforms as they use SLPC for frequency management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
v2: Rename flags as per review suggestions (Rodrigo, Tvrtko).
Also, use flag bits in intel_context as it allows finer control for
toggling per engine if needed (Tvrtko).
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Sushma Venkatesh Reddy
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +++--
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_rps.c | 5 +
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++
drivers/gpu/drm/i915/i915_getparam.c | 12 +++
include/uapi/drm/i915_drm.h | 15 +
10 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..0799cb0b2803 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
struct i915_gem_proto_context *pc,
struct drm_i915_gem_context_param *args)
{
+ struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
+ case I915_CONTEXT_PARAM_LOW_LATENCY:
+ if (intel_uc_uses_guc_submission(&to_gt(i915)->uc))
+ pc->user_flags |= BIT(UCONTEXT_LOW_LATENCY);
+ else
+ ret = -EINVAL;
+ break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
@@ -992,6 +1000,9 @@ static int intel_context_set_gem(struct intel_context *ce,
if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
ret = intel_context_reconfigure_sseu(ce, sseu);
+ if (test_bit(UCONTEXT_LOW_LATENCY, &ctx->user_flags))
+ set_bit(CONTEXT_LOW_LATENCY, &ce->flags);
+
return ret;
}
@@ -1630,6 +1641,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
if (vm)
ctx->vm = vm;
+ ctx->user_flags = pc->user_flags;
+
mutex_init(&ctx->engines_mutex);
if (pc->num_user_engines >= 0) {
i915_gem_context_set_user_engines(ctx);
@@ -1652,8 +1665,6 @@ i915_gem_create_context(struct drm_i915_private *i915,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(i915);
- ctx->user_flags = pc->user_flags;
-
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..b6d97da63d1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
#define UCONTEXT_PERSISTENCE 4
+#define UCONTEXT_LOW_LATENCY 5
/**
* @flags: small set of booleans
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 7eccbd70d89f..ed95a7b57cbb 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -130,6 +130,7 @@ struct intel_context {
#define CONTEXT_PERMA_PIN 11
#define CONTEXT_IS_PARKING 12
#define CONTEXT_EXITING13
+#define CONTEXT_LOW_L
Re: [PATCH 0/9] kunit: Fix printf format specifier issues in KUnit assertions
On 2/21/24 02:27, David Gow wrote: KUnit has several macros which accept a log message, which can contain printf format specifiers. Some of these (the explicit log macros) already use the __printf() gcc attribute to ensure the format specifiers are valid, but those which could fail the test, and hence used __kunit_do_failed_assertion() behind the scenes, did not. These include: - KUNIT_EXPECT_*_MSG() - KUNIT_ASSERT_*_MSG() - KUNIT_FAIL() This series adds the __printf() attribute, and fixes all of the issues uncovered. (Or, at least, all of those I could find with an x86_64 allyesconfig, and the default KUnit config on a number of other architectures. Please test!) The issues in question basically take the following forms: - int / long / long long confusion: typically a type being updated, but the format string not. - Use of integer format specifiers (%d/%u/%li/etc) for types like size_t or pointer differences (technically ptrdiff_t), which would only work on some architectures. - Use of integer format specifiers in combination with PTR_ERR(), where %pe would make more sense. - Use of empty messages which, whilst technically not incorrect, are not useful and trigger a gcc warning. We'd like to get these (or equivalent) in for 6.9 if possible, so please do take a look if possible. Thanks, -- David Reported-by: Linus Torvalds Closes: https://lore.kernel.org/linux-kselftest/CAHk-=wgjmoqudo5f8shh1f4rzzwzapnvcw643m5-yj+bfsf...@mail.gmail.com/ David Gow (9): kunit: test: Log the correct filter string in executor_test lib/cmdline: Fix an invalid format specifier in an assertion msg lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg time: test: Fix incorrect format specifier rtc: test: Fix invalid format specifier. net: test: Fix printf format specifier in skb_segment kunit test drm: tests: Fix invalid printf format specifiers in KUnit tests drm/xe/tests: Fix printf format specifiers in xe_migrate test kunit: Annotate _MSG assertion variants with gnu printf specifiers Applied all patches in this series except to linux-ksefltest kunit for linux 6.9-rc1 drm: tests: Fix invalid printf format specifiers in KUnit tests David, as requtested in 7/9 thread, if you can send me patch on top pf 6.8-rc6, will apply it 7-9 drm: tests: Fix invalid printf format specifiers in KUnit tests thanks, -- Shuah
Re: [PATCH] drm/udl: Add ARGB8888 as a format
On Wed, 28 Feb 2024 at 00:19, Douglas Anderson wrote:
>
> Even though the UDL driver converts to RGB565 internally (see
> pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
> compatibility. Let's add ARGB to that list.
>
> This makes UDL devices work on ChromeOS again after commit
> c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that
> commit things were "working" because we'd silently treat the ARGB
> that ChromeOS wanted as XRGB.
>
> Fixes: c91acda3a380 ("drm/gem: Check for valid formats")
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/udl/udl_modeset.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH 7/9] drm: tests: Fix invalid printf format specifiers in KUnit tests
On 2/21/24 14:29, Justin Stitt wrote:
Hi,
On Wed, Feb 21, 2024 at 05:27:20PM +0800, David Gow wrote:
The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
which was then updated to be an 'unsigned long' to avoid 64-bit
multiplication division helpers.
However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the
'%d' or '%llu' format specifiers, the former of which is always wrong,
and the latter is no longer correct now that ps is no longer a u64. Fix
these to all use '%lu'.
Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the
message. gcc warns if a printf format string is empty (apparently), so
clang does too; under -Wformat-zero-length
give these some more detailed error messages, which should be more
useful anyway.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Fixes: fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
Signed-off-by: David Gow
Reviewed-by: Justin Stitt
David,
Please send this on top of Linux 6.9-rc6 - this one doesn't
apply as is due to conflict between this one and fca7526b7d89
I think if we can fix this here - we won't problems during pull
request merge.
thanks,
-- Shuah
Re: [PATCH] Revert "drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes"
On 2/27/2024 2:11 PM, Abhinav Kumar wrote:
On 2/27/2024 2:08 PM, Dmitry Baryshkov wrote:
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the userspace. The mentioned commit made some of
the HPD events being reported earlier. This way userspace starts poking
around. It interacts in a bad way with the dp_bridge_detect and the
driver's state machine, ending up either with the very long delays
during hotplug detection or even inability of the DP driver to report
the display as connected.
A proper fix will involve redesigning of the HPD handling in the MSM DP
driver. It is underway, but it will be intrusive and can not be thought
about as a simple fix for the issue. Thus, revert the offending commit.
Yes, for fixing this on 6.9 I am fine with this.
I hope there were not other changes which were built on top of this.
So it will be better if we retest internal HPD case as well with this.
We will do that in a day or two and give Tested-by.
Fixes: e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify() to
report HPD status changes")
Link: https://gitlab.freedesktop.org/drm/msm/-/issues/50
Reported-by: Johan Hovold
Link: https://lore.kernel.org/r/zd3ypgmrprxv-...@hovoldconsulting.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
For the change itself,
Reviewed-by: Abhinav Kumar
Tested-by: Paloma Arellano
Re: [PATCH 5/9] rtc: test: Fix invalid format specifier.
On 27/02/2024 14:23:29-0700, Shuah Khan wrote:
> On 2/27/24 13:32, Alexandre Belloni wrote:
> > Hello,
> >
> > On 21/02/2024 17:27:18+0800, David Gow wrote:
> > > 'days' is a s64 (from div_s64), and so should use a %lld specifier.
> > >
> > > This was found by extending KUnit's assertion macros to use gcc's
> > > __printf attribute.
> > >
> > > Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add
> > > tests.")
> > > Signed-off-by: David Gow
> >
> > Who do you expect to take this patch?
> >
>
> I am going to be applying this series to linux-kselftest kunit next
> in just a bit. Would you like to ack the pacth?
Sure,
Acked-by: Alexandre Belloni
>
> thanks,
> -- Shuah
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v7 29/36] drm/vc4: tests: Remove vc4_dummy_plane structure
Hi Maxime, On 2/27/24 10:02, Maxime Ripard wrote: Hi Maíra, Thanks for you reviews! On Mon, Feb 26, 2024 at 09:29:32AM -0300, Maíra Canal wrote: On 2/22/24 15:14, Maxime Ripard wrote: The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we Maybe I understood incorrectly, but isn't the vc4_dummy_plane structure equivalent to drm_plane? Both statements are true :) vc4 itself uses vc4_plane to holds its plane-related content, but it turns out that there's nothing in that structure anymore and vc4_plane == drm_plane. In our mock driver, we have another structure meant to store the mock-plane-related content which doesn't have anything in it anymore, and is thus equivalent to vc4_plane. So, basically, vc4_dummy_plane == vc4_plane == drm_plane. This patch is only about getting rid of vc4_dummy_plane though. Is it clearer? Yeah, with that pointed out, you can add my: Reviewed-by: Maíra Canal Best Regards, - Maíra Maxime
DisplayPort: handling of HPD events / link training
Hello, We are currently looking at checking and/or possibly redesigning the way the MSM DRM driver handles the HPD events and link training. After a quick glance at the drivers implementing DP support, I noticed following main approaches: - Perform link training at the atomic_enable time, don't report failures (mtk, analogix, zynqmp, tegra, nouveau) - Perform link training at the atomic_enable time, report errors using link_status property (i915, mhdp8546) - Perform link training on the plug event (msm, it8605). - Perform link training from the DPMS handler, also calling it from the enable callback (AMDGPU, radeon). It looks like the majority wins and we should move HPD to atomic_enable time. Is that assumption correct? Also two related questions: - Is there a plan to actually make use of the link_status property? Intel presented it at FOSDEM 2018, but since that time it was not picked up by other drivers. - Is there any plan to create generic DP link training helpers? After glancing through the DP drivers there is a lot of similar code in the link training functions, with minor differences here and there. And it's those minor differences that bug me. It means that drivers might respond differently to similar devices. Or that there might be minor bugs here and there. -- With best wishes Dmitry
Re: [PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
On Sun, Feb 11, 2024 at 5:09 PM Adam Ford wrote:
>
> The P divider should be set based on the min and max values of
> the fin pll which may vary between different platforms.
> These ranges are defined per platform, but hard-coded values
> were used instead which resulted in a smaller range available
> on the i.MX8M[MNP] than what was possible.
>
> As noted by Frieder, there are descripencies between the reference
> manuals of the Mini, Nano and Plus, so I reached out to my NXP
> rep and got the following response regarding the varing notes
> in the documentation.
>
> "Yes it is definitely wrong, the one that is part of the NOTE in
> MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
> not correct. I will report this to Doc team, the one customer should
> be take into account is the Table 13-40 DPHY PLL Parameters and the
> Note above."
>
> With this patch, the clock rates now match the values used in NXP's
> downstream kernel.
>
Inki,
Any change either or both of these patches could get applied? It's
been several months since the first submission.
Fabio - Do you have an 8MP-evk that you could test to see if there is
any impact? Between these two patches, it fixes the 720p@60 and
likely others too.
adam
> Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
> Signed-off-by: Adam Ford
> Reviewed-by: Frieder Schrempf
> Tested-by: Frieder Schrempf
> ---
> V2: Only update the commit message to reflect why these values
> were chosen. No code change present
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 95fedc68b0ae..8476650c477c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
> samsung_dsim *dsi,
> u16 _m, best_m;
> u8 _s, best_s;
>
> - p_min = DIV_ROUND_UP(fin, (12 * MHZ));
> - p_max = fin / (6 * MHZ);
> + p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
> + p_max = fin / (driver_data->pll_fin_min * MHZ);
>
> for (_p = p_min; _p <= p_max; ++_p) {
> for (_s = 0; _s <= 5; ++_s) {
> --
> 2.43.0
>
[PATCH] drm/udl: Add ARGB8888 as a format
Even though the UDL driver converts to RGB565 internally (see
pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
compatibility. Let's add ARGB to that list.
This makes UDL devices work on ChromeOS again after commit
c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that
commit things were "working" because we'd silently treat the ARGB
that ChromeOS wanted as XRGB.
Fixes: c91acda3a380 ("drm/gem: Check for valid formats")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/udl/udl_modeset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 7702359c90c2..0f8d3678770e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -253,6 +253,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
static const uint32_t udl_primary_plane_formats[] = {
DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
};
static const uint64_t udl_primary_plane_fmtmods[] = {
--
2.44.0.rc1.240.g4c46232300-goog
Re: [PATCH] Revert "drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes"
On 2/27/2024 2:08 PM, Dmitry Baryshkov wrote:
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the userspace. The mentioned commit made some of
the HPD events being reported earlier. This way userspace starts poking
around. It interacts in a bad way with the dp_bridge_detect and the
driver's state machine, ending up either with the very long delays
during hotplug detection or even inability of the DP driver to report
the display as connected.
A proper fix will involve redesigning of the HPD handling in the MSM DP
driver. It is underway, but it will be intrusive and can not be thought
about as a simple fix for the issue. Thus, revert the offending commit.
Yes, for fixing this on 6.9 I am fine with this.
I hope there were not other changes which were built on top of this. So
it will be better if we retest internal HPD case as well with this.
We will do that in a day or two and give Tested-by.
Fixes: e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status
changes")
Link: https://gitlab.freedesktop.org/drm/msm/-/issues/50
Reported-by: Johan Hovold
Link: https://lore.kernel.org/r/zd3ypgmrprxv-...@hovoldconsulting.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
For the change itself,
Reviewed-by: Abhinav Kumar
[PATCH] Revert "drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes"
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the userspace. The mentioned commit made some of
the HPD events being reported earlier. This way userspace starts poking
around. It interacts in a bad way with the dp_bridge_detect and the
driver's state machine, ending up either with the very long delays
during hotplug detection or even inability of the DP driver to report
the display as connected.
A proper fix will involve redesigning of the HPD handling in the MSM DP
driver. It is underway, but it will be intrusive and can not be thought
about as a simple fix for the issue. Thus, revert the offending commit.
Fixes: e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify() to report HPD
status changes")
Link: https://gitlab.freedesktop.org/drm/msm/-/issues/50
Reported-by: Johan Hovold
Link: https://lore.kernel.org/r/zd3ypgmrprxv-...@hovoldconsulting.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d37d599aec27..4c72124ffb5d 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -329,10 +329,26 @@ static const struct component_ops dp_display_comp_ops = {
.unbind = dp_display_unbind,
};
+static void dp_display_send_hpd_event(struct msm_dp *dp_display)
+{
+ struct dp_display_private *dp;
+ struct drm_connector *connector;
+
+ dp = container_of(dp_display, struct dp_display_private, dp_display);
+
+ connector = dp->dp_display.connector;
+ drm_helper_hpd_irq_event(connector->dev);
+}
+
static int dp_display_send_hpd_notification(struct dp_display_private *dp,
bool hpd)
{
- struct drm_bridge *bridge = dp->dp_display.bridge;
+ if ((hpd && dp->dp_display.link_ready) ||
+ (!hpd && !dp->dp_display.link_ready)) {
+ drm_dbg_dp(dp->drm_dev, "HPD already %s\n",
+ (hpd ? "on" : "off"));
+ return 0;
+ }
/* reset video pattern flag on disconnect */
if (!hpd) {
@@ -348,7 +364,7 @@ static int dp_display_send_hpd_notification(struct
dp_display_private *dp,
drm_dbg_dp(dp->drm_dev, "type=%d hpd=%d\n",
dp->dp_display.connector_type, hpd);
- drm_bridge_hpd_notify(bridge, dp->dp_display.link_ready);
+ dp_display_send_hpd_event(&dp->dp_display);
return 0;
}
--
2.39.2
Re: [PATCH 5/9] rtc: test: Fix invalid format specifier.
On 2/27/24 13:32, Alexandre Belloni wrote:
Hello,
On 21/02/2024 17:27:18+0800, David Gow wrote:
'days' is a s64 (from div_s64), and so should use a %lld specifier.
This was found by extending KUnit's assertion macros to use gcc's
__printf attribute.
Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add
tests.")
Signed-off-by: David Gow
Who do you expect to take this patch?
I am going to be applying this series to linux-kselftest kunit next
in just a bit. Would you like to ack the pacth?
thanks,
-- Shuah
Re: [PATCH 5/9] rtc: test: Fix invalid format specifier.
Hello,
On 21/02/2024 17:27:18+0800, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add
> tests.")
> Signed-off-by: David Gow
Who do you expect to take this patch?
> ---
> drivers/rtc/lib_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/lib_test.c b/drivers/rtc/lib_test.c
> index d5caf36c56cd..225c859d6da5 100644
> --- a/drivers/rtc/lib_test.c
> +++ b/drivers/rtc/lib_test.c
> @@ -54,7 +54,7 @@ static void rtc_time64_to_tm_test_date_range(struct kunit
> *test)
>
> days = div_s64(secs, 86400);
>
> - #define FAIL_MSG "%d/%02d/%02d (%2d) : %ld", \
> + #define FAIL_MSG "%d/%02d/%02d (%2d) : %lld", \
> year, month, mday, yday, days
>
> KUNIT_ASSERT_EQ_MSG(test, year - 1900, result.tm_year,
> FAIL_MSG);
> --
> 2.44.0.rc0.258.g7320e95886-goog
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 27, 2024 at 09:35:22PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Add a new immutable plane property by which a plane can advertise > a handful of recommended plane sizes. This would be mostly exposed > by cursor planes as a slightly more capable replacement for > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > a one size fits all limit for the whole device. > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > size via the cursor size caps. But always using the max sized > cursor can waste a surprising amount of power, so a better > stragey is desirable. > > Most other drivers don't specify any cursor size at all, in > which case the ioctl code just claims that 64x64 is a great > choice. Whether that is actually true is debatable. > > A poll of various compositor developers informs us that > blindly probing with setcursor/atomic ioctl to determine > suitable cursor sizes is not acceptable, thus the > introduction of the new property to supplant the cursor > size caps. The compositor will now be free to select a > more optimal cursor size from the short list of options. > > Note that the reported sizes (either via the property or the > caps) make no claims about things such as plane scaling. So > these things should only really be consulted for simple > "cursor like" use cases. > > Userspace consumer in the form of mutter seems ready: > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 > > v2: Try to add some docs > v3: Specify that value 0 is reserved for future use (basic idea from Jonas) > Drop the note about typical hardware (Pekka) > v4: Update the docs to indicate the list is "in order of preference" > Add a a link to the mutter MR > > Cc: Simon Ser > Cc: Jonas Ådahl > Cc: Daniel Stone > Cc: Sameer Lattannavar > Cc: Sebastian Wick > Acked-by: Harry Wentland > Acked-by: Pekka Paalanen > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_mode_config.c | 7 + > drivers/gpu/drm/drm_plane.c | 52 +++ > include/drm/drm_mode_config.h | 5 +++ > include/drm/drm_plane.h | 4 +++ > include/uapi/drm/drm_mode.h | 11 +++ > 5 files changed, 79 insertions(+) > > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 48fd2d67f352..568972258222 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c > @@ -372,6 +372,13 @@ static int drm_mode_create_standard_properties(struct > drm_device *dev) > return -ENOMEM; > dev->mode_config.modifiers_property = prop; > > + prop = drm_property_create(dev, > +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, > +"SIZE_HINTS", 0); > + if (!prop) > + return -ENOMEM; > + dev->mode_config.size_hints_property = prop; > + > return 0; > } > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 672c655c7a8e..4135ce16e608 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -140,6 +140,25 @@ > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have > been > * various bugs in this area with inconsistencies between the capability > * flag and per-plane properties. > + * > + * SIZE_HINTS: > + * Blob property which contains the set of recommended plane size > + * which can used for simple "cursor like" use cases (eg. no scaling). > + * Using these hints frees userspace from extensive probing of > + * supported plane sizes through atomic/setcursor ioctls. > + * > + * The blob contains an array of struct drm_plane_size_hint, in > + * order of preference. For optimal usage userspace should pick > + * the first size that satisfies its own requirements. > + * > + * Drivers should only attach this property to planes that > + * support a very limited set of sizes. > + * > + * Note that property value 0 (ie. no blob) is reserved for potential > + * future use. Current userspace is expected to ignore the property > + * if the value is 0, and fall back to some other means (eg. > + * &DRM_CAP_CURSOR_WIDTH and &DRM_CAP_CURSOR_HEIGHT) to determine > + * the appropriate plane size to use. > */ > > static unsigned int drm_num_planes(struct drm_device *dev) > @@ -1729,3 +1748,36 @@ int drm_plane_create_scaling_filter_property(struct > drm_plane *plane, > return 0; > } > EXPORT_SYMBOL(drm_plane_create_scaling_filter_property); > + > +/** > + * drm_plane_add_size_hint_property - create a size hint property > + * > + * @plane: drm plane > + * @hints: size hints > + * @num_hints: number of size hints > + * > + * Create a size hints property for the plane. > + * > + * RETURNS: > + * Zero for success or -errno > + */ > +int drm_plane_add_size_hints_property(struct drm_plane *plane, > +
[PATCH] drm/i915/ttm: Fix TTM_PL_FLAG_DESIRED
From: Ville Syrjälä
inlined from ‘i915_ttm_get_pages’ at
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: warning: ‘places[0].flags’
is used uninitialized [-Wuninitialized]
165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
| ~^~
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_get_pages’:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:837:26: note: ‘places’ declared here
837 | struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
| ^~
Furhermore we then proceed to call i915_ttm_place_from_region() which
memset()s the whole thing back to zero anyway. So in the end we lose
the TTM_PL_FLAG_DESIRED flag (and fortunately also whatever else stack
garbage happened to be in the flags at this point).
No idea what functional changes this will result in...
Cc: Somalapuram Amaranath
Cc: Christian König
Cc: Zack Rusin
Cc: Thomas Zimmermann
Cc: Thomas Hellström
Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27dcfd8a34bb..e6f177183c0f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -162,10 +162,10 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
unsigned int flags = obj->flags;
unsigned int i;
- places[0].flags |= TTM_PL_FLAG_DESIRED;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
obj->mm.region, &places[0], obj->bo_offset,
obj->base.size, flags);
+ places[0].flags |= TTM_PL_FLAG_DESIRED;
/* Cache this on object? */
for (i = 0; i < num_allowed; ++i) {
--
2.43.0
Re: [PATCH v2 2/3] drm/msm/dp: Add support for setting the eDP mode from devicetree
On Thu, Feb 22, 2024 at 05:55:07PM +0200, Abel Vesa wrote:
> Instead of relying on different compatibles for eDP and DP, use
> the is-edp property from DT to figure out the connector type and
> then pass on that information to the PHY.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Abel Vesa
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
> drivers/gpu/drm/msm/dp/dp_ctrl.h| 1 +
> drivers/gpu/drm/msm/dp/dp_display.c | 17 ++---
> 3 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 320f17fce9a6..bd81cc6bd5e3 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1533,6 +1533,17 @@ void dp_ctrl_set_psr(struct dp_ctrl *dp_ctrl, bool
> enter)
> }
> }
>
> +int dp_ctrl_phy_set_mode(struct dp_ctrl *dp_ctrl, int submode)
> +{
> + struct dp_ctrl_private *ctrl;
> + struct phy *phy;
> +
> + ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
> + phy = ctrl->phy;
> +
> + return phy_set_mode_ext(phy, PHY_MODE_DP, submode);
> +}
> +
> void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
> {
> struct dp_ctrl_private *ctrl;
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h
> b/drivers/gpu/drm/msm/dp/dp_ctrl.h
> index fa014cee7e21..a10d1b19d172 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
> @@ -32,6 +32,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
> dp_link *link,
> struct phy *phy);
>
> void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable);
> +int dp_ctrl_phy_set_mode(struct dp_ctrl *dp_ctrl, int mode);
> void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl);
> void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl);
> void dp_ctrl_irq_phy_exit(struct dp_ctrl *dp_ctrl);
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index e4433891becb..e01b41ad2e2a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1229,6 +1229,7 @@ static int dp_display_probe(struct platform_device
> *pdev)
> int rc = 0;
> struct dp_display_private *dp;
> const struct msm_dp_desc *desc;
> + bool is_edp;
>
> if (!pdev || !pdev->dev.of_node) {
> DRM_ERROR("pdev not found\n");
> @@ -1243,13 +1244,17 @@ static int dp_display_probe(struct platform_device
> *pdev)
> if (!desc)
> return -EINVAL;
>
> + is_edp = (desc->connector_type == DRM_MODE_CONNECTOR_eDP) ||
> + of_property_read_bool(pdev->dev.of_node, "is-edp");
> +
> dp->dp_display.pdev = pdev;
> dp->name = "drm_dp";
> dp->id = desc->id;
> - dp->dp_display.connector_type = desc->connector_type;
> + dp->dp_display.connector_type = is_edp ?
> + DRM_MODE_CONNECTOR_eDP :
> + DRM_MODE_CONNECTOR_DisplayPort;
> dp->wide_bus_en = desc->wide_bus_en;
> - dp->dp_display.is_edp =
> - (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP);
> + dp->dp_display.is_edp = is_edp;
>
> rc = dp_init_sub_modules(dp);
> if (rc) {
> @@ -1257,6 +1262,12 @@ static int dp_display_probe(struct platform_device
> *pdev)
> return -EPROBE_DEFER;
> }
>
> + rc = dp_ctrl_phy_set_mode(dp->ctrl, is_edp ? PHY_SUBMODE_EDP :
> PHY_SUBMODE_DP);
> + if (rc) {
> + DRM_ERROR("setting PHY submode failed\n");
> + goto err;
> + }
> +
> /* setup event q */
> mutex_init(&dp->event_mutex);
> init_waitqueue_head(&dp->event_q);
>
> --
> 2.34.1
>
Re: [PATCH v2 6/9] drm/vkms: Add YUV support
On 27/02/24 12:02, Louis Chauvet wrote:
> Hi Pekka,
>
> For all the comment related to the conversion part, maybe Arthur have an
> opinion on it, I took his patch as a "black box" (I did not want to
> break (and debug) it).
>
> Le 26/02/24 - 14:19, Pekka Paalanen a écrit :
>> On Fri, 23 Feb 2024 12:37:26 +0100
>> Louis Chauvet wrote:
>>
>>> From: Arthur Grillo
>>>
>>> Add support to the YUV formats bellow:
>>>
>>> - NV12
>>> - NV16
>>> - NV24
>>> - NV21
>>> - NV61
>>> - NV42
>>> - YUV420
>>> - YUV422
>>> - YUV444
>>> - YVU420
>>> - YVU422
>>> - YVU444
>>>
>>> The conversion matrices of each encoding and range were obtained by
>>> rounding the values of the original conversion matrices multiplied by
>>> 2^8. This is done to avoid the use of fixed point operations.
>>>
>>> Signed-off-by: Arthur Grillo
>>> [Louis Chauvet: Adapted Arthur's work and implemented the read_line_t
>>> callbacks for yuv formats]
>>> Signed-off-by: Louis Chauvet
>>> ---
>>> drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
>>> drivers/gpu/drm/vkms/vkms_drv.h | 6 +-
>>> drivers/gpu/drm/vkms/vkms_formats.c | 289
>>> +--
>>> drivers/gpu/drm/vkms/vkms_formats.h | 4 +
>>> drivers/gpu/drm/vkms/vkms_plane.c| 14 +-
>>> 5 files changed, 295 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
>>> b/drivers/gpu/drm/vkms/vkms_composer.c
>>> index e555bf9c1aee..54fc5161d565 100644
>>> --- a/drivers/gpu/drm/vkms/vkms_composer.c
>>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
>>> @@ -312,7 +312,7 @@ static void blend(struct vkms_writeback_job *wb,
>>> * buffer [1]
>>> */
>>> current_plane->pixel_read_line(
>>> - current_plane->frame_info,
>>> + current_plane,
>>> x_start,
>>> y_start,
>>> direction,
>>> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
>>> b/drivers/gpu/drm/vkms/vkms_drv.h
>>> index ccc5be009f15..a4f6456cb971 100644
>>> --- a/drivers/gpu/drm/vkms/vkms_drv.h
>>> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
>>> @@ -75,6 +75,8 @@ enum pixel_read_direction {
>>> READ_RIGHT
>>> };
>>>
>>> +struct vkms_plane_state;
>>> +
>>> /**
>>> <<< HEAD
>>> * typedef pixel_read_line_t - These functions are used to read a pixel
>>> line in the source frame,
>>> @@ -87,8 +89,8 @@ enum pixel_read_direction {
>>> * @out_pixel: Pointer where to write the pixel value. Pixels will be
>>> written between x_start and
>>> * x_end.
>>> */
>>> -typedef void (*pixel_read_line_t)(struct vkms_frame_info *frame_info, int
>>> x_start, int y_start, enum
>>> - pixel_read_direction direction, int count, struct pixel_argb_u16
>>> out_pixel[]);
>>> +typedef void (*pixel_read_line_t)(struct vkms_plane_state *frame_info, int
>>> x_start, int y_start,
>>> + enum pixel_read_direction direction, int count, struct pixel_argb_u16
>>> out_pixel[]);
>>
>> This is the second or third time in this one series changing this type.
>> Could you not do the change once, in its own patch if possible?
>
> Sorry, this is not a change here, but a wrong formatting (missed when
> rebasing).
>
> Do you think that it make sense to re-order my patches and put this
> typedef at the end? This way it is never updated.
>
>>>
>>> /**
>>> * vkms_plane_state - Driver specific plane state
>>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
>>> b/drivers/gpu/drm/vkms/vkms_formats.c
>>> index 46daea6d3ee9..515c80866a58 100644
>>> --- a/drivers/gpu/drm/vkms/vkms_formats.c
>>> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
>>> @@ -33,7 +33,8 @@ static size_t packed_pixels_offset(const struct
>>> vkms_frame_info *frame_info, int
>>> */
>>> return fb->offsets[plane_index] +
>>>(y / drm_format_info_block_width(format, plane_index)) *
>>> fb->pitches[plane_index] +
>>> - (x / drm_format_info_block_height(format, plane_index)) *
>>> format->char_per_block[plane_index];
>>> + (x / drm_format_info_block_height(format, plane_index)) *
>>> + format->char_per_block[plane_index];
>>
>> Shouldn't this be in the patch that added this code in the first place?
>
> Same as above, a wrong formatting, I will remove this change and keep
> everything on one line (even if it's more than 100 chars, it is easier to
> read).
>
>>> }
>>>
>>> /**
>>> @@ -84,6 +85,32 @@ static int get_step_1x1(struct drm_framebuffer *fb, enum
>>> pixel_read_direction di
>>> }
>>> }
>>>
>>> +/**
>>> + * get_subsampling() - Get the subsampling value on a specific direction
>>
>> subsampling divisor
>
> Thanks for this precision.
>
>>> + */
>>> +static int get_subsampling(const struct drm_format_info *format,
>>> + enum pixel_read_direction direction)
>>> +{
>>> + if (direction == READ_LEFT || direction == READ_RIGHT)
>>> + return form
[linux-next:master] BUILD REGRESSION 22ba90670a51a18c6b36d285fddf92b9887c0bc3
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 22ba90670a51a18c6b36d285fddf92b9887c0bc3 Add linux-next specific
files for 20240227
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402271629.7zzu8scf-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
WARNING: modpost: vmlinux: section mismatch in reference: virtio_fs_init+0x8c
(section: .init.text) -> map_benchmark_cleanup (section: .exit.text)
WARNING: modpost: vmlinux: section mismatch in reference: virtio_fs_init+0xdc
(section: .init.text) -> sq_api_exit (section: .exit.text)
Unverified Error/Warning (likely false positive, please contact us if
interested):
{standard input}:1474: Error: unknown pseudo-op: `.l141'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arc-randconfig-001-20240227
| `--
fs-ubifs-journal.c:warning:expecting-prototype-for-wake_up_reservation().-Prototype-was-for-add_or_start_queue()-instead
|-- arm-randconfig-002-20240227
| `--
fs-ubifs-journal.c:warning:expecting-prototype-for-wake_up_reservation().-Prototype-was-for-add_or_start_queue()-instead
|-- arm64-defconfig
| |--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
| `--
fs-ubifs-journal.c:warning:expecting-prototype-for-wake_up_reservation().-Prototype-was-for-add_or_start_queue()-instead
|-- i386-buildonly-randconfig-002-20240227
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- parisc-defconfig
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- parisc64-defconfig
| `--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
|-- sh-buildonly-randconfig-r003-20230528
| `--
WARNING:modpost:vmlinux:section-mismatch-in-reference:virtio_fs_init-(section:.init.text)-map_benchmark_cleanup-(section:.exit.text)
|-- sh-randconfig-r003-20230713
| `-- standard-input:Error:unknown-pseudo-op:l141
`-- sh-randconfig-r004-20220501
`--
WARNING:modpost:vmlinux:section-mismatch-in-reference:virtio_fs_init-(section:.init.text)-sq_api_exit-(section:.exit.text)
clang_recent_errors
|-- hexagon-allmodconfig
| `--
fs-ubifs-journal.c:warning:expecting-prototype-for-wake_up_reservation().-Prototype-was-for-add_or_start_queue()-instead
|-- hexagon-allyesconfig
| `--
fs-ubifs-journal.c:warning:expecting-prototype-for-wake_up_reservation().-Prototype-was-for-add_or_start_queue()-instead
`-- riscv-defconfig
`--
drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
elapsed time: 724m
configs tested: 179
configs skipped: 3
tested configs:
alpha allnoconfig gcc
alphaallyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240227 gcc
arc randconfig-002-20240227 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
armkeystone_defconfig gcc
armmulti_v7_defconfig gcc
arm randconfig-001-20240227 gcc
arm randconfig-002-20240227 gcc
arm randconfig-003-20240227 gcc
arm randconfig-004-20240227 gcc
arm tegra_defconfig gcc
armvt8500_v6_v7_defconfig gcc
arm64allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240227 clang
arm64 randconfig-002-20240227 gcc
arm64 randconfig-003-20240227 gcc
arm64 randconfig-004-20240227 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
cskydefconfig gcc
csky randconfig-001-20240227 gcc
csky randconfig-002-20240227 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig cl
[PATCH v2 2/2] drm/i915: Add SIZE_HINTS property for cursors
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and max cursor limits.
Depending on the platform this will give us one of three
results:
- 64x64,128x128,256x256,512x512
- 64x64,128x128,256x256
- 64x64
Cc: Simon Ser
Cc: Jonas Ådahl
Cc: Daniel Stone
Cc: Sameer Lattannavar
Cc: Sebastian Wick
Cc: Harry Wentland
Cc: Pekka Paalanen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 24 +
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index f8b33999d43f..49e9b9be2235 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -823,6 +823,28 @@ static const struct drm_plane_funcs
intel_cursor_plane_funcs = {
.format_mod_supported = intel_cursor_format_mod_supported,
};
+static void intel_cursor_add_size_hints_property(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ const struct drm_mode_config *config = &i915->drm.mode_config;
+ struct drm_plane_size_hint hints[4];
+ int size, max_size, num_hints = 0;
+
+ max_size = min(config->cursor_width, config->cursor_height);
+
+ /* for simplicity only enumerate the supported square+POT sizes */
+ for (size = 64; size <= max_size; size *= 2) {
+ if (drm_WARN_ON(&i915->drm, num_hints >= ARRAY_SIZE(hints)))
+ break;
+
+ hints[num_hints].width = size;
+ hints[num_hints].height = size;
+ num_hints++;
+ }
+
+ drm_plane_add_size_hints_property(&plane->base, hints, num_hints);
+}
+
struct intel_plane *
intel_cursor_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe)
@@ -881,6 +903,8 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180);
+ intel_cursor_add_size_hints_property(cursor);
+
zpos = DISPLAY_RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
drm_plane_create_zpos_immutable_property(&cursor->base, zpos);
--
2.43.0
[PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.
Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
stragey is desirable.
Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.
A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.
Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.
Userspace consumer in the form of mutter seems ready:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165
v2: Try to add some docs
v3: Specify that value 0 is reserved for future use (basic idea from Jonas)
Drop the note about typical hardware (Pekka)
v4: Update the docs to indicate the list is "in order of preference"
Add a a link to the mutter MR
Cc: Simon Ser
Cc: Jonas Ådahl
Cc: Daniel Stone
Cc: Sameer Lattannavar
Cc: Sebastian Wick
Acked-by: Harry Wentland
Acked-by: Pekka Paalanen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_mode_config.c | 7 +
drivers/gpu/drm/drm_plane.c | 52 +++
include/drm/drm_mode_config.h | 5 +++
include/drm/drm_plane.h | 4 +++
include/uapi/drm/drm_mode.h | 11 +++
5 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 48fd2d67f352..568972258222 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -372,6 +372,13 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "SIZE_HINTS", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.size_hints_property = prop;
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 672c655c7a8e..4135ce16e608 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -140,6 +140,25 @@
* DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
* various bugs in this area with inconsistencies between the capability
* flag and per-plane properties.
+ *
+ * SIZE_HINTS:
+ * Blob property which contains the set of recommended plane size
+ * which can used for simple "cursor like" use cases (eg. no scaling).
+ * Using these hints frees userspace from extensive probing of
+ * supported plane sizes through atomic/setcursor ioctls.
+ *
+ * The blob contains an array of struct drm_plane_size_hint, in
+ * order of preference. For optimal usage userspace should pick
+ * the first size that satisfies its own requirements.
+ *
+ * Drivers should only attach this property to planes that
+ * support a very limited set of sizes.
+ *
+ * Note that property value 0 (ie. no blob) is reserved for potential
+ * future use. Current userspace is expected to ignore the property
+ * if the value is 0, and fall back to some other means (eg.
+ * &DRM_CAP_CURSOR_WIDTH and &DRM_CAP_CURSOR_HEIGHT) to determine
+ * the appropriate plane size to use.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
@@ -1729,3 +1748,36 @@ int drm_plane_create_scaling_filter_property(struct
drm_plane *plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_scaling_filter_property);
+
+/**
+ * drm_plane_add_size_hint_property - create a size hint property
+ *
+ * @plane: drm plane
+ * @hints: size hints
+ * @num_hints: number of size hints
+ *
+ * Create a size hints property for the plane.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_plane_add_size_hints_property(struct drm_plane *plane,
+ const struct drm_plane_size_hint *hints,
+ int num_hints)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_property_blob *blob;
+
+ blob = drm_property_create_blob(
[PATCH v2 0/2] drm: Add plane SIZE_HINTS property
From: Ville Syrjälä Final version for a new plane SIZE_HINTS property to essentially replace the cursor size caps, based on recent discussion in this gitlab bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7687 As for userspace, so far I only did a quick modetest blob decoder (mainly to verify that it looks correct): https://gitlab.freedesktop.org/vsyrjala/libdrm/-/commits/plane_size_hints Sameer & co. have done a real mutter implementation: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 This final version follows the original idea of having just a list of sizes in a blob, rather than the mode complex "2D bitmap" approach I also proposed later. I think that's fair, the bitmap was probably overly complicated. The only difference to the previous version of this approach is that the documentation now states that the list is sorted in order of preference, and thus userspace should pick the first suitable size from the list. This should match the aforementioned mutter implementation. Cc: Simon Ser Cc: Jonas Ådahl Cc: Daniel Stone Cc: Sameer Lattannavar Cc: Sebastian Wick Cc: Harry Wentland Cc: Pekka Paalanen Ville Syrjälä (2): drm: Introduce plane SIZE_HINTS property drm/i915: Add SIZE_HINTS property for cursors drivers/gpu/drm/drm_mode_config.c | 7 +++ drivers/gpu/drm/drm_plane.c | 52 + drivers/gpu/drm/i915/display/intel_cursor.c | 24 ++ include/drm/drm_mode_config.h | 5 ++ include/drm/drm_plane.h | 4 ++ include/uapi/drm/drm_mode.h | 11 + 6 files changed, 103 insertions(+) -- 2.43.0
[PATCH] drm/amd/display: check dc_link before dereferencing
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683
amdgpu_dm_connector_funcs_force()
warn: variable dereferenced before check 'dc_link' (see line 6663)
Fixes: 967176179215 ("drm/amd/display: fix null-pointer dereference on edid
reading")
Reported-by: Dan Carpenter
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 32efce81a5a7..46dd06e8fc7e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6653,7 +6653,7 @@ static void amdgpu_dm_connector_funcs_force(struct
drm_connector *connector)
struct edid *edid;
struct i2c_adapter *ddc;
- if (dc_link->aux_mode)
+ if (dc_link && dc_link->aux_mode)
ddc = &aconnector->dm_dp_aux.aux.ddc;
else
ddc = &aconnector->i2c->base;
--
2.43.0
Re: [PATCH] drm/panfrost: Replace fdinfo's profiling debugfs knob with sysfs
Hi Boris,
On 26.02.2024 09:51, Boris Brezillon wrote:
> On Wed, 21 Feb 2024 16:12:32 +
> Adrián Larumbe wrote:
>
> > Debugfs isn't always available in production builds that try to squeeze
> > every single byte out of the kernel image, but we still need a way to
> > toggle the timestamp and cycle counter registers so that jobs can be
> > profiled for fdinfo's drm engine and cycle calculations.
> >
> > Drop the debugfs knob and replace it with a sysfs file that accomplishes
> > the same functionality, and document its ABI in a separate file.
> >
> > Signed-off-by: Adrián Larumbe
> > ---
> > .../testing/sysfs-driver-panfrost-profiling | 10 +++
> > Documentation/gpu/panfrost.rst| 9 +++
> > drivers/gpu/drm/panfrost/Makefile | 5 +-
> > drivers/gpu/drm/panfrost/panfrost_debugfs.c | 21 --
> > drivers/gpu/drm/panfrost/panfrost_debugfs.h | 14
> > drivers/gpu/drm/panfrost/panfrost_device.h| 5 +-
> > drivers/gpu/drm/panfrost/panfrost_drv.c | 14 ++--
> > drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> > drivers/gpu/drm/panfrost/panfrost_sysfs.c | 74 +++
> > drivers/gpu/drm/panfrost/panfrost_sysfs.h | 15
> > 10 files changed, 124 insertions(+), 45 deletions(-)
> > create mode 100644
> > Documentation/ABI/testing/sysfs-driver-panfrost-profiling
> > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
> > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
> > create mode 100644 drivers/gpu/drm/panfrost/panfrost_sysfs.c
> > create mode 100644 drivers/gpu/drm/panfrost/panfrost_sysfs.h
> >
> > diff --git a/Documentation/ABI/testing/sysfs-driver-panfrost-profiling
> > b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling
> > new file mode 100644
> > index ..ce54069714f3
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling
> > @@ -0,0 +1,10 @@
> > +What:
> > /sys/bus/.../drivers/panfrost/.../drm/../profiling/status
> > +Date: February 2024
> > +KernelVersion: 6.8.0
> > +Contact: Adrian Larumbe
> > +Description:
> > +Get/set drm fdinfo's engine and cycles profiling status.
> > +Valid values are:
> > + 0: Disable fdinfo job profiling sources. This disables both the
> > GPU's
> > +timestamp and cycle counter registers.
> > + 1: Enable the above.
> > diff --git a/Documentation/gpu/panfrost.rst b/Documentation/gpu/panfrost.rst
> > index b80e41f4b2c5..be4ac282ef63 100644
> > --- a/Documentation/gpu/panfrost.rst
> > +++ b/Documentation/gpu/panfrost.rst
> > @@ -38,3 +38,12 @@ the currently possible format options:
> >
> > Possible `drm-engine-` key names are: `fragment`, and `vertex-tiler`.
> > `drm-curfreq-` values convey the current operating frequency for that
> > engine.
> > +
> > +Users must bear in mind that engine and cycle sampling are disabled by
> > default,
> > +because of power saving concerns. `fdinfo` users and benchmark
> > applications which
> > +query the fdinfo file must make sure to toggle the job profiling status of
> > the
> > +driver by writing into the appropriate sysfs node::
> > +
> > +echo >
> > /sys/bus/platform/drivers/panfrost/[a-f0-9]*.gpu/drm/card1/profiling
> > +
> > +Where `N` is either `0` or `1`, depending on the desired enablement status.
> > diff --git a/drivers/gpu/drm/panfrost/Makefile
> > b/drivers/gpu/drm/panfrost/Makefile
> > index 2c01c1e7523e..6e718595d8a6 100644
> > --- a/drivers/gpu/drm/panfrost/Makefile
> > +++ b/drivers/gpu/drm/panfrost/Makefile
> > @@ -10,8 +10,7 @@ panfrost-y := \
> > panfrost_job.o \
> > panfrost_mmu.o \
> > panfrost_perfcnt.o \
> > - panfrost_dump.o
> > -
> > -panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
> > + panfrost_dump.o \
> > + panfrost_sysfs.o
> >
> > obj-$(CONFIG_DRM_PANFROST) += panfrost.o
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> > b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> > deleted file mode 100644
> > index 72d4286a6bf7..
> > --- a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> > +++ /dev/null
> > @@ -1,21 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -/* Copyright 2023 Collabora ltd. */
> > -/* Copyright 2023 Amazon.com, Inc. or its affiliates. */
> > -
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -
> > -#include "panfrost_device.h"
> > -#include "panfrost_gpu.h"
> > -#include "panfrost_debugfs.h"
> > -
> > -void panfrost_debugfs_init(struct drm_minor *minor)
> > -{
> > - struct drm_device *dev = minor->dev;
> > - struct panfrost_device *pfdev =
> > platform_get_drvdata(to_platform_device(dev->dev));
> > -
> > - debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
> > &pfdev->profile_mode);
> > -}
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
> > b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
> > deleted file
Re: DRM Migration to Gitlab
Hi, On Tue, Feb 27, 2024 at 09:16:35AM +0100, Maxime Ripard wrote: > Sima, after becoming aware of the drm-misc transition to Gitlab in the > next couple of weeks, to do the same for DRM today. > > This is now done and all the various bits (nightly.conf, MAINTAINERS, > doc, etc.) should be there. > > If all goes well, the only thing you'll notice is that dim will complain > about the drm remote not having the right URLs. > > Any dim user should update the URL with either one of the two following > commands: > > git remote set-url drm ssh://g...@gitlab.freedesktop.org/drm/kernel.git > git remote set-url drm https://gitlab.freedesktop.org/drm/kernel.git > > And the rest should be transparent. So, it turns out it wasn't. With the help of Lucas, Jani and Sima today we rolled something that will convert anyone that hasn't changed anything yet automatically. The only thing you need to do is run `dim ub` *twice* and you'll be prompted to update the URL on the second run. If you've followed the instructions above and got stuck somewhere in the middle, you can get back to the state before today and then start over like described above by doing: cd $DIM_PREFIX/drm-rerere git checkout rerere-cache git reset --hard 044940a15536 cd $DIM_PREFIX/maintainer-tools git checkout master git reset --hard 0c154c094f54 cd $DIM_PREFIX/kernel git remote set-url drm ssh://git.freedesktop.org/git/drm/drm dim ub dim ub Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/i915/guc: Correct capture of EIR register on hang
On Fri, 2024-02-23 at 12:32 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
alan:snip
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -51,6 +51,7 @@
> { RING_ESR(0), 0, 0, "ESR" }, \
> { RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW" },
> \
> { RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UDW" },
> \
> + { RING_EIR(0), 0, 0, "EIR" }, \
> { RING_IPEIR(0), 0, 0, "IPEIR" }, \
> { RING_IPEHR(0), 0, 0, "IPEHR" }, \
> { RING_INSTPS(0), 0, 0, "INSTPS" }, \
> @@ -80,9 +81,6 @@
> { GEN8_RING_PDP_LDW(0, 3), 0, 0, "PDP3_LDW" }, \
> { GEN8_RING_PDP_UDW(0, 3), 0, 0, "PDP3_UDW" }
>
> -#define COMMON_BASE_HAS_EU \
> - { EIR, 0, 0, "EIR" }
> -
alan:snip
alan: Thanks for catching this one.
Reviewed-by: Alan Previn
Re: [DO NOT MERGE v6 34/37] sh: Add dtbs target support.
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 3/9] drm/vkms: write/update the documentation for pixel conversion and pixel write functions
On 27/02/24 12:02, Louis Chauvet wrote: > Le 26/02/24 - 10:07, Arthur Grillo a écrit : >> >> >> On 26/02/24 05:46, Louis Chauvet wrote: >>> Add some documentation on pixel conversion functions. >>> Update of outdated comments for pixel_write functions. >>> >>> Signed-off-by: Louis Chauvet >>> --- >>> drivers/gpu/drm/vkms/vkms_composer.c | 4 +++ >>> drivers/gpu/drm/vkms/vkms_drv.h | 13 >>> drivers/gpu/drm/vkms/vkms_formats.c | 58 >>> ++-- >>> 3 files changed, 66 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c >>> b/drivers/gpu/drm/vkms/vkms_composer.c >>> index c6d9b4a65809..5b341222d239 100644 >>> --- a/drivers/gpu/drm/vkms/vkms_composer.c >>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c >>> @@ -189,6 +189,10 @@ static void blend(struct vkms_writeback_job *wb, >>> >>> size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay; >>> >>> + /* >>> +* The planes are composed line-by-line. It is a necessary complexity >>> to avoid poor >>> +* blending performance. >> >> At this moment in the series, you have not yet reintroduced the >> line-by-line algorithm yet. Maybe it's better to add this comment when >> you do. > > Is it better with this: > > /* >* The planes are composed line-by-line to avoid heavy memory usage. It > is a necessary >* complexity to avoid poor blending performance. >* >* The function vkms_compose_row is used to read a line, > pixel-by-pixel, into the staging >* buffer. >*/ > >> Also, I think it's good to give more context, like: >> "The planes are composed line-by-line, instead of pixel-by-pixel" > > And after PATCHv3 5/9: > > /* >* The planes are composed line-by-line to avoid heavy memory usage. It > is a necessary >* complexity to avoid poor blending performance. >* >* The function pixel_read_line callback is used to read a line, using > an efficient >* algorithm for a specific format, into the staging buffer. >*/ > Hi, This looks good to me. Best Regards, ~Arthur Grillo > Kind regards, > Louis Chauvet > >> Best Regards, >> ~Arthur Grillo > > [...] >
Re: [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console
Am 27.02.24 um 19:14 schrieb Dmitry Osipenko: Hello, Thank you for the patches! On 2/27/24 13:14, Thomas Zimmermann wrote: Dma-buf locking semantics require the caller of pin and unpin to hold the buffer's reservation lock. Fix DRM to adhere to the specs. This enables to fix the locking in DRM's console emulation. Similar changes for vmap and mmap have been posted at [1][2] Most DRM drivers and memory managers acquire the buffer object's reservation lock within their GEM pin and unpin callbacks. This violates dma-buf locking semantics. We get away with it because PRIME does not provide pin/unpin, but attach/detach, for which the locking semantics is correct. Patches 1 to 8 rework DRM GEM code in various implementations to acquire the reservation lock when entering the pin and unpin callbacks. This prepares them for the next patch. Drivers that are not affected by these patches either don't acquire the reservation lock (amdgpu) or don't need preparation (loongson). Patch 9 moves reservation locking from the GEM pin/unpin callbacks into drm_gem_pin() and drm_gem_unpin(). As PRIME uses these functions internally it still gets the reservation lock. With the updated GEM callbacks, the rest of the patchset fixes the fbdev emulation's buffer locking. Fbdev emulation needs to keep its GEM buffer object inplace while updating its content. This required a implicit pinning and apparently amdgpu didn't do this at all. Patch 10 introduces drm_client_buffer_vmap_local() and _vunmap_local(). The former function map a GEM buffer into the kernel's address space with regular vmap operations, but keeps holding the reservation lock. The _vunmap_local() helper undoes the vmap and releases the lock. The updated GEM callbacks make this possible. Between the two calls, the fbdev emulation can update the buffer content without have the buffer moved or evicted. Update fbdev-generic to use vmap_local helpers, which fix amdgpu. The idea of adding a "local vmap" has previously been attempted at [3] in a different form. Patch 11 adds implicit pinning to the DRM client's regular vmap helper so that long-term vmap'ed buffers won't be evicted. This only affects fbdev-dma, but GEM DMA helpers don't require pinning. So there are no practical changes. Patches 12 and 13 remove implicit pinning from the vmap and vunmap operations in gem-vram and qxl. These pin operations are not supposed to be part of vmap code, but were required to keep the buffers in place for fbdev emulation. With the conversion o ffbdev-generic to to vmap_local helpers, that code can finally be removed. Isn't it a common behaviour for all DRM drivers to implicitly pin BO while it's vmapped? I was sure it should be common /o\ No, at least amdgpu and radon doesn't pin kmapped BOs and I don't think nouveau does either. Why would you want to kmap BO that isn't pinned? The usual use case is to call the ttm kmap function when you need CPU access. When the buffer hasn't moved we can use the cached CPU mapping, if the buffer has moved since the last time or this is the first time that is called we setup a new mapping. Shouldn't TTM's vmap() be changed to do the pinning? Absolutely not, no. That would break tons of use cases. Regards, Christian. I missed that TTM doesn't pin BO on vmap() and now surprised to see it. It should be a rather serious problem requiring backporting of the fixes, but I don't see the fixes tags on the patches (?)
Re: [PATCH] drm/panfrost: Replace fdinfo's profiling debugfs knob with sysfs
Hi Steve, On 21.02.2024 16:52, Steven Price wrote: > On 21/02/2024 16:12, Adrián Larumbe wrote: > > Debugfs isn't always available in production builds that try to squeeze > > every single byte out of the kernel image, but we still need a way to > > toggle the timestamp and cycle counter registers so that jobs can be > > profiled for fdinfo's drm engine and cycle calculations. > > > > Drop the debugfs knob and replace it with a sysfs file that accomplishes > > the same functionality, and document its ABI in a separate file. > > > > Signed-off-by: Adrián Larumbe > > --- > > .../testing/sysfs-driver-panfrost-profiling | 10 +++ > > Documentation/gpu/panfrost.rst| 9 +++ > > drivers/gpu/drm/panfrost/Makefile | 5 +- > > drivers/gpu/drm/panfrost/panfrost_debugfs.c | 21 -- > > drivers/gpu/drm/panfrost/panfrost_debugfs.h | 14 > > drivers/gpu/drm/panfrost/panfrost_device.h| 5 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 14 ++-- > > drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- > > drivers/gpu/drm/panfrost/panfrost_sysfs.c | 74 +++ > > drivers/gpu/drm/panfrost/panfrost_sysfs.h | 15 > > 10 files changed, 124 insertions(+), 45 deletions(-) > > create mode 100644 > > Documentation/ABI/testing/sysfs-driver-panfrost-profiling > > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c > > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h > > create mode 100644 drivers/gpu/drm/panfrost/panfrost_sysfs.c > > create mode 100644 drivers/gpu/drm/panfrost/panfrost_sysfs.h > > > > diff --git a/Documentation/ABI/testing/sysfs-driver-panfrost-profiling > > b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling > > new file mode 100644 > > index ..ce54069714f3 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling > > @@ -0,0 +1,10 @@ > > +What: > > /sys/bus/.../drivers/panfrost/.../drm/../profiling/status > > +Date: February 2024 > > +KernelVersion: 6.8.0 > > +Contact: Adrian Larumbe > > +Description: > > +Get/set drm fdinfo's engine and cycles profiling status. > > +Valid values are: > > + 0: Disable fdinfo job profiling sources. This disables both the > > GPU's > > +timestamp and cycle counter registers. > > + 1: Enable the above. > > Minor point, but if we're going to eventually come up with a generic way > of doing this, then we're going to have to think about backwards > compatibility for this sysfs file. I would expect in this new world '0' > would mean "default behaviour; off unless the new-fangled thing enables > profiling" and '1' means "force on". > > In which case perhaps wording like the below would be clearer: > > 0: Don't enable fdinfo job profiling sources. > 1: Enable fdinfo job profiling sources, this enables both the GPU's >timestamp and cycle counter registers. > > Or am I being too picky over the wording ;) I'm alright with this kind of wording, to keep things as generic as possible. Initially I thought just mentioning 0 and 1 as potential toggle values would be enough, and then every driver could describe their own profiling/status sysfs knob in similar terms, depending on what profiling resouces they act upon. > One other small issue below... > > > diff --git a/Documentation/gpu/panfrost.rst b/Documentation/gpu/panfrost.rst > > index b80e41f4b2c5..be4ac282ef63 100644 > > --- a/Documentation/gpu/panfrost.rst > > +++ b/Documentation/gpu/panfrost.rst > > @@ -38,3 +38,12 @@ the currently possible format options: > > > > Possible `drm-engine-` key names are: `fragment`, and `vertex-tiler`. > > `drm-curfreq-` values convey the current operating frequency for that > > engine. > > + > > +Users must bear in mind that engine and cycle sampling are disabled by > > default, > > +because of power saving concerns. `fdinfo` users and benchmark > > applications which > > +query the fdinfo file must make sure to toggle the job profiling status of > > the > > +driver by writing into the appropriate sysfs node:: > > + > > +echo > > > /sys/bus/platform/drivers/panfrost/[a-f0-9]*.gpu/drm/card1/profiling > > + > > +Where `N` is either `0` or `1`, depending on the desired enablement status. > > diff --git a/drivers/gpu/drm/panfrost/Makefile > > b/drivers/gpu/drm/panfrost/Makefile > > index 2c01c1e7523e..6e718595d8a6 100644 > > --- a/drivers/gpu/drm/panfrost/Makefile > > +++ b/drivers/gpu/drm/panfrost/Makefile > > @@ -10,8 +10,7 @@ panfrost-y := \ > > panfrost_job.o \ > > panfrost_mmu.o \ > > panfrost_perfcnt.o \ > > - panfrost_dump.o > > - > > -panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o > > + panfrost_dump.o \ > > + panfrost_sysfs.o > > > > obj-$(CONFIG_DRM_PANFROST) += panfrost.o > > diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c > > b/drivers/gpu/drm/panfrost/panfrost_debugfs.c >
Re: [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console
Hello, Thank you for the patches! On 2/27/24 13:14, Thomas Zimmermann wrote: > Dma-buf locking semantics require the caller of pin and unpin to hold > the buffer's reservation lock. Fix DRM to adhere to the specs. This > enables to fix the locking in DRM's console emulation. Similar changes > for vmap and mmap have been posted at [1][2] > > Most DRM drivers and memory managers acquire the buffer object's > reservation lock within their GEM pin and unpin callbacks. This > violates dma-buf locking semantics. We get away with it because PRIME > does not provide pin/unpin, but attach/detach, for which the locking > semantics is correct. > > Patches 1 to 8 rework DRM GEM code in various implementations to > acquire the reservation lock when entering the pin and unpin callbacks. > This prepares them for the next patch. Drivers that are not affected > by these patches either don't acquire the reservation lock (amdgpu) > or don't need preparation (loongson). > > Patch 9 moves reservation locking from the GEM pin/unpin callbacks > into drm_gem_pin() and drm_gem_unpin(). As PRIME uses these functions > internally it still gets the reservation lock. > > With the updated GEM callbacks, the rest of the patchset fixes the > fbdev emulation's buffer locking. Fbdev emulation needs to keep its > GEM buffer object inplace while updating its content. This required > a implicit pinning and apparently amdgpu didn't do this at all. > > Patch 10 introduces drm_client_buffer_vmap_local() and _vunmap_local(). > The former function map a GEM buffer into the kernel's address space > with regular vmap operations, but keeps holding the reservation lock. > The _vunmap_local() helper undoes the vmap and releases the lock. The > updated GEM callbacks make this possible. Between the two calls, the > fbdev emulation can update the buffer content without have the buffer > moved or evicted. Update fbdev-generic to use vmap_local helpers, > which fix amdgpu. The idea of adding a "local vmap" has previously been > attempted at [3] in a different form. > > Patch 11 adds implicit pinning to the DRM client's regular vmap > helper so that long-term vmap'ed buffers won't be evicted. This only > affects fbdev-dma, but GEM DMA helpers don't require pinning. So > there are no practical changes. > > Patches 12 and 13 remove implicit pinning from the vmap and vunmap > operations in gem-vram and qxl. These pin operations are not supposed > to be part of vmap code, but were required to keep the buffers in place > for fbdev emulation. With the conversion o ffbdev-generic to to > vmap_local helpers, that code can finally be removed. Isn't it a common behaviour for all DRM drivers to implicitly pin BO while it's vmapped? I was sure it should be common /o\ Why would you want to kmap BO that isn't pinned? Shouldn't TTM's vmap() be changed to do the pinning? I missed that TTM doesn't pin BO on vmap() and now surprised to see it. It should be a rather serious problem requiring backporting of the fixes, but I don't see the fixes tags on the patches (?) -- Best regards, Dmitry
Re: [PATCH v4 6/8] usb: misc: onboard_dev: use device supply names
On Tue, Feb 20, 2024 at 03:05:50PM +0100, Javier Carrasco wrote: > The current mechanism uses generic names for the power supplies, which > conflicts with proper name definitions in the device bindings. > > Add a per-device property to include real supply names and keep generic > names as a fallback mechanism for backward compatibility. > > Signed-off-by: Javier Carrasco For v5 you could consider making this [1/8] (i.e. before the renaming of the driver). That way support for new hubs doesn't necessarily have to wait for the entire series to land. Since this series is underway I think new bindings shouldn't use 'vdd-supply' but the device specific name of the supply.
Re: [PATCH v4 2/8] usb: misc: onboard_dev: add support for non-hub devices
On Thu, Feb 22, 2024 at 03:42:26PM +0100, Javier Carrasco wrote:
> On 21.02.24 20:24, Matthias Kaehlcke wrote:
> > On Tue, Feb 20, 2024 at 03:05:46PM +0100, Javier Carrasco wrote:
> >> Most of the functionality this driver provides can be used by non-hub
> >> devices as well.
> >>
> >> To account for the hub-specific code, add a flag to the device data
> >> structure and check its value for hub-specific code.
> >
> > Please mention that the driver doesn't power off non-hub devices
> > during system suspend.
> >
> >> Signed-off-by: Javier Carrasco
> >> ---
> >> drivers/usb/misc/onboard_usb_dev.c | 3 ++-
> >> drivers/usb/misc/onboard_usb_dev.h | 10 ++
> >> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/misc/onboard_usb_dev.c
> >> b/drivers/usb/misc/onboard_usb_dev.c
> >> index 2103af2cb2a6..f43130a6786f 100644
> >> --- a/drivers/usb/misc/onboard_usb_dev.c
> >> +++ b/drivers/usb/misc/onboard_usb_dev.c
> >> @@ -129,7 +129,8 @@ static int __maybe_unused onboard_dev_suspend(struct
> >> device *dev)
> >>if (!device_may_wakeup(node->udev->bus->controller))
> >>continue;
> >>
> >> - if (usb_wakeup_enabled_descendants(node->udev)) {
> >> + if (usb_wakeup_enabled_descendants(node->udev) ||
> >> + !onboard_dev->pdata->is_hub) {
> >
> >
> > This check isn't dependent on characteristics of the USB devices processed
> > in this loop, therefore it can be performed at function entry. Please
> > combine
> > it with the check of 'always_powered_in_suspend'. It's also an option to
> > omit the check completely, 'always_powered_in_suspend' will never be set for
> > non-hub devices (assuming the sysfs attribute isn't added).
> >
>
> The attribute will not be available for non-hub devices in v5. However,
> if the check is completely removed, will power_off not stay true at the
> end of the function, always leading to a device power off? As you said,
> 'always_powered_in_suspend' will not be set for non-hub devices.
Even without the sysfs attribute the field 'always_powered_in_suspend' could
be set to true by probe() for non-hub devices.
Re: [PATCH 1/1] drm/bridge: ti-sn65dsi83: Fix enable error path
Hi Alexander,
thanks for your feedback!
On Tue, 27 Feb 2024 13:05:46 +0100
Alexander Stein wrote:
> Hi Luca,
>
> Am Donnerstag, 22. Februar 2024, 16:36:37 CET schrieb Luca Ceresoli:
> > Hello Alexander,
> >
> > On Thu, 4 May 2023 08:53:16 +0200
> > Alexander Stein wrote:
> >
> > > If PLL locking failed, the regulator needs to be disabled again.
> > >
> > > Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator
> > > support")
> > > Signed-off-by: Alexander Stein
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > index 75286c9afbb9..1f5c07989e2b 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > @@ -478,6 +478,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
> > > *bridge,
> > > dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> > > /* On failure, disable PLL again and exit. */
> > > regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> > > + regulator_disable(ctx->vcc);
> > > return;
> > > }
> >
> > I'm reviving this thread as I've been investigating a bug that appears
> > related to this patch.
> >
> > Symptom: with a v6.8-rc5 kernel, if PLL fails locking, later on during
> > atomic disable I get:
> >
> > [ 41.065198] [ cut here ]
> > [ 41.069823] unbalanced disables for DOCK_SYS_1V8
> > [ 41.074482] WARNING: CPU: 0 PID: 58 at drivers/regulator/core.c:2999
> > _regulator_disable+0xf8/0x1d8
> > [ 41.083457] Modules linked in: smsc smsc95xx usbnet mii imx_cpufreq_dt
> > exc3000 imx8mm_thermal snd_soc_tlv320aic3x_spi snd_soc_tlv320aic3x_i2c
> > snd_soc_tlv320aic3x tmp103 snd_soc_simple_card snd_soc_simple_card_utils
> > fsl_ldb rtc_snvs snvs_pwrkey snd_soc_fsl_sai imx8mp_interconnect
> > snd_soc_fsl_utils imx_interconnect imx_pcm_dma rtc_rs5c372 ti_sn65dsi83
> > pwm_imx27 st_pressure_spi st_sensors_spi st_pressure_i2c st_pressure
> > st_sensors_i2c industrialio_triggered_buffer lm75 kfifo_buf st_sensors
> > opt3001 panel_simple etnaviv gpu_sched iio_hwmon governor_userspace imx_bus
> > imx8mp_hdmi_tx dw_hdmi drm_display_helper samsung_dsim imx_sdma imx_lcdif
> > drm_dma_helper imx8mp_hdmi_pvi drm_kms_helper drm
> > drm_panel_orientation_quirks fsl_imx8_ddr_perf caam error sbs_battery
> > pwm_bl backlight ltc2497 ltc2497_core crct10dif_ce
> > [ 41.157281] CPU: 0 PID: 58 Comm: kworker/0:2 Not tainted 6.8.0-rc5+ #7
> > [ 41.170339] Workqueue: events drm_mode_rmfb_work_fn [drm]
> > [ 41.175798] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
> > BTYPE=--)
> > [ 41.182762] pc : _regulator_disable+0xf8/0x1d8
> > [ 41.187209] lr : _regulator_disable+0xf8/0x1d8
> > [ 41.191654] sp : 800081aaba90
> > [ 41.194967] x29: 800081aaba90 x28: x27:
> > 02647e80
> > [ 41.202109] x26: 02d7a180 x25: 037858a0 x24:
> > 800079748ac8
> > [ 41.209250] x23: 02647ed8 x22: 0263f800 x21:
> > 0373d000
> > [ 41.216392] x20: 0373d000 x19: 01de6480 x18:
> > 0006
> > [ 41.223533] x17: x16: 1fffe03423e1 x15:
> > 800081aab520
> > [ 41.230674] x14: x13: 3856315f5359535f x12:
> > 4b434f4420726f66
> > [ 41.237815] x11: 2073656c62617369 x10: 8000814647a0 x9 :
> > 8000801b10e0
> > [ 41.244957] x8 : 8000814bc7a0 x7 : 00017fe8 x6 :
> > 8000814bc7a0
> > [ 41.252098] x5 : x4 : x3 :
> >
> > [ 41.259239] x2 : x1 : x0 :
> > 011b6600
> > [ 41.266380] Call trace:
> > [ 41.268826] _regulator_disable+0xf8/0x1d8
> > [ 41.272925] regulator_disable+0x4c/0x98
> > [ 41.276850] sn65dsi83_atomic_disable+0x70/0xc0 [ti_sn65dsi83]
> > [ 41.282692] drm_atomic_bridge_chain_disable+0x78/0x110 [drm]
> > [ 41.288481] disable_outputs+0x100/0x350 [drm_kms_helper]
> > [ 41.293902] drm_atomic_helper_commit_tail_rpm+0x2c/0xb0 [drm_kms_helper]
> > [ 41.300705] commit_tail+0xac/0x1a0 [drm_kms_helper]
> > [ 41.305685] drm_atomic_helper_commit+0x16c/0x188 [drm_kms_helper]
> > [ 41.311881] drm_atomic_commit+0xac/0xf0 [drm]
> > [ 41.316365] drm_framebuffer_remove+0x464/0x550 [drm]
> > [ 41.321458] drm_mode_rmfb_work_fn+0x84/0xb0 [drm]
> > [ 41.326291] process_one_work+0x148/0x3b8
> > [ 41.330309] worker_thread+0x32c/0x450
> > [ 41.334061] kthread+0x11c/0x128
> > [ 41.337292] ret_from_fork+0x10/0x20
> > [ 41.340873] ---[ end trace ]---
> >
> > The reason is clear from the code flow, which looks like this (after
> > removing unrelated code):
> >
> > static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
> >
Re: [PATCH] net: ethernet: ti: am65-cpsw: Add minimal XDP support
On Mon, Feb 26, 2024 at 06:48:25PM +0100, Julien Panis wrote:
> Hello Simon,
>
> Thank you for the review.
>
> On 2/26/24 18:25, Simon Horman wrote:
> > On Fri, Feb 23, 2024 at 12:01:37PM +0100, Julien Panis wrote:
> > > This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> > > Ethernet driver. The following features are implemented:
> > > - NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED)
> > > - NETDEV_XDP_ACT_REDIRECT (XDP_REDIRECT)
> > > - NETDEV_XDP_ACT_NDO_XMIT (ndo_xdp_xmit callback)
> > >
> > > Signed-off-by: Julien Panis
> > ...
> >
> > > @@ -440,6 +476,27 @@ static void am65_cpsw_nuss_tx_cleanup(void *data,
> > > dma_addr_t desc_dma)
> > > dev_kfree_skb_any(skb);
> > > }
> > > +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev,
> > > unsigned int len)
> > > +{
> > > + struct page *page;
> > > + struct sk_buff *skb;
> > nit: please arrange local variables in reverse xmas tree order,
> > from longest line to shortest in new code.
> >
> > This tool can be useful: https://github.com/ecree-solarflare/xmastree
>
> You mean, for the new functions introduced in this patch only ?
It's a bit loose. But generally the idea would be to move towards this
practice. So for new functions: yes. And when modifying old ones old ones:
if possible.
> > > +
> > > + page = dev_alloc_pages(0);
> > nit: Maybe dev_alloc_page() is appropriate here?
>
> Absolutely.
>
> >
> > > + if (unlikely(!page))
> > > + return NULL;
> > > +
> > > + len += AM65_CPSW_HEADROOM;
> > > +
> > > + skb = build_skb(page_address(page), len);
> > > + if (unlikely(!skb))
> > Does page need to be freed here?
>
> Of course it does ! This will be fixed in the next version.
Thanks!
>
> >
> > > + return NULL;
> > > +
> > > + skb_reserve(skb, AM65_CPSW_HEADROOM + NET_IP_ALIGN);
> > > + skb->dev = ndev;
> > > +
> > > + return skb;
> > > +}
> > ...
>
amdgpu kmemleaks
Hi folks, anyone interested in a bunch of amdgpu kmemleak reports from latest Linus tree + tip? GPU is: [ 11.317312] [drm] amdgpu kernel modesetting enabled. [ 11.363627] [drm] initializing kernel modesetting (CARRIZO 0x1002:0x9874 0x103C:0x807E 0xC4). [ 11.364077] [drm] register mmio base: 0xD0C0 [ 11.364547] [drm] register mmio size: 262144 [ 11.365347] [drm] add ip block number 0 [ 11.365580] [drm] add ip block number 1 [ 11.365840] [drm] add ip block number 2 [ 11.366047] [drm] add ip block number 3 [ 11.366263] [drm] add ip block number 4 [ 11.366470] [drm] add ip block number 5 [ 11.32] [drm] add ip block number 6 [ 11.366835] [drm] add ip block number 7 [ 11.367022] [drm] add ip block number 8 [ 11.382774] [drm] BIOS signature incorrect 5b 7 [ 11.383002] resource: resource sanity check: requesting [mem 0x000c-0x000d], which spans more than PCI Bus :00 [mem 0x000c-0x000cbfff window] [ 11.383655] caller pci_map_rom+0x68/0x1d0 mapping multiple BARs [ 11.384009] amdgpu :00:01.0: amdgpu: Fetched VBIOS from ROM BAR [ 11.384402] amdgpu: ATOM BIOS: SWBRT27354.001 [ 11.385827] [drm] UVD is enabled in physical mode [ 11.386063] [drm] VCE enabled in physical mode [ 11.386886] amdgpu :00:01.0: vgaarb: deactivate vga console [ 11.389089] Console: switching to colour dummy device 80x25 [ 11.389543] amdgpu :00:01.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported [ 11.390482] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit [ 11.390793] amdgpu :00:01.0: amdgpu: VRAM: 512M 0x00F4 - 0x00F41FFF (512M used) [ 11.391129] amdgpu :00:01.0: amdgpu: GART: 1024M 0x00FF - 0x00FF3FFF [ 11.391456] [drm] Detected VRAM RAM=512M, BAR=512M [ 11.391632] [drm] RAM width 128bits UNKNOWN [ 11.394546] [drm] amdgpu: 512M of VRAM memory ready [ 11.394751] [drm] amdgpu: 7622M of GTT memory ready. [ 11.395299] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 11.395813] [drm] PCIE GART of 1024M enabled (table at 0x00F400A0). [ 11.404914] amdgpu: hwmgr_sw_init smu backed is smu8_smu [ 11.407177] [drm] Found UVD firmware Version: 1.91 Family ID: 11 [ 11.407670] [drm] UVD ENC is disabled [ 11.409969] [drm] Found VCE firmware Version: 52.4 Binary ID: 3 [ 11.412601] amdgpu: smu version 18.62.00 [ 11.419275] [drm] DM_PPLIB: values for Engine clock [ 11.419480] [drm] DM_PPLIB: 30 [ 11.419610] [drm] DM_PPLIB: 36 [ 11.419740] [drm] DM_PPLIB: 423530 [ 11.419869] [drm] DM_PPLIB: 514290 [ 11.419998] [drm] DM_PPLIB: 626090 [ 11.420127] [drm] DM_PPLIB: 72 [ 11.420327] [drm] DM_PPLIB: Validation clocks: [ 11.420536] [drm] DM_PPLIB:engine_max_clock: 72000 [ 11.420722] [drm] DM_PPLIB:memory_max_clock: 8 [ 11.420907] [drm] DM_PPLIB:level : 8 [ 11.421083] [drm] DM_PPLIB: values for Display clock [ 11.421266] [drm] DM_PPLIB: 30 [ 11.421395] [drm] DM_PPLIB: 40 [ 11.421524] [drm] DM_PPLIB: 496560 [ 11.421652] [drm] DM_PPLIB: 626090 [ 11.421781] [drm] DM_PPLIB: 685720 [ 11.421910] [drm] DM_PPLIB: 757900 [ 11.422039] [drm] DM_PPLIB: Validation clocks: [ 11.422201] [drm] DM_PPLIB:engine_max_clock: 72000 [ 11.422386] [drm] DM_PPLIB:memory_max_clock: 8 [ 11.422572] [drm] DM_PPLIB:level : 8 [ 11.422746] [drm] DM_PPLIB: values for Memory clock [ 11.422923] [drm] DM_PPLIB: 333000 [ 11.423052] [drm] DM_PPLIB: 80 [ 11.423181] [drm] DM_PPLIB: Validation clocks: [ 11.423342] [drm] DM_PPLIB:engine_max_clock: 72000 [ 11.423528] [drm] DM_PPLIB:memory_max_clock: 8 [ 11.423713] [drm] DM_PPLIB:level : 8 [ 11.424561] [drm] Display Core v3.2.266 initialized on DCE 11.0 [ 11.516117] [drm] UVD initialized successfully. [ 11.716119] [drm] VCE initialized successfully. unreferenced object 0x88810e6faa80 (size 128): comm "systemd-udevd", pid 1219, jiffies 4294895080 hex dump (first 32 bytes): 18 cb 03 00 00 0a 28 0a 48 0a c8 0a 00 00 a0 05 ..(.H... aa 05 b4 05 dc 05 00 00 0a 00 00 00 00 00 00 00 backtrace (crc 5201319b): [<6e1e4989>] kmalloc_trace+0x25a/0x300 [<7b61fcfc>] do_detailed_mode+0x323/0x670 [<79955120>] drm_for_each_detailed_block.part.0+0x34/0x180 [<9a087c6a>] _drm_edid_connector_add_modes.part.0+0x8f/0x10b0 [] drm_add_edid_modes+0x14e/0x160 [<0a49b747>] amdgpu_dm_connector_get_modes+0x13b/0x470 [amdgpu] [<5f5da5a5>] amdgpu_dm_init.isra.0+0x12ed/0x1e50 [amdgpu] [ ] dm_hw_init+0xe/0x20 [amdgpu] [ ] amdgpu_device_init+0x1f17/0x2530 [amdgpu] [<9c22ce56>] amdgpu_driver_load_kms+0x23/0x1a0 [amdgpu] [<8bc75f74>] amdgpu_pci_probe+0x1b5/0x550 [amdg
Re: [PATCH] drm/vkms: Add information on how to benchmark
On 27/02/24 12:02, Louis Chauvet wrote: > Le 27/02/24 - 15:26, Pekka Paalanen a écrit : >> On Tue, 27 Feb 2024 09:29:58 -0300 >> Arthur Grillo wrote: >> >>> On 27/02/24 08:55, Pekka Paalanen wrote: On Tue, 27 Feb 2024 08:44:52 -0300 Arthur Grillo wrote: > On 27/02/24 06:19, Pekka Paalanen wrote: >> On Mon, 26 Feb 2024 17:42:11 -0300 >> Arthur Grillo wrote: >> >>> Now that we have a defined benchmark for testing the driver, add >>> documentation on how to run it. >>> >>> Signed-off-by: Arthur Grillo >>> --- >>> Documentation/gpu/vkms.rst | 6 ++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst >>> index ba04ac7c2167..6d07f79f77ff 100644 >>> --- a/Documentation/gpu/vkms.rst >>> +++ b/Documentation/gpu/vkms.rst >>> @@ -89,6 +89,12 @@ You can also run subtests if you do not want to run >>> the entire test:: >>>sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device >>> "sys:/sys/devices/platform/vkms" >>>sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" >>> ./build/tests/kms_flip --run-subtest basic-plain-flip >>> >>> +If you are developing features that may affect performance, you can >>> run the kms_fb_stress >> >> s/can/must/ >> >>> +benchmark:: >> >> before and after, and report the numbers. > > Did you mean to write the benchmarks logs here? I mean people should be required tell their before and after numbers in either commit message (my preference) or in series cover letter (if benchmarking commits is not useful). With the addition of YUV support in VKMS, maybe the benchmark needs to >>> >>> With the upcoming addition, I've sent a patch to arbitrarily change the >>> formats on the benchmark via command-line options. It's not adding a new >>> case, but maybe just this could already help. >>> >>> https://lore.kernel.org/all/20240226-kms_fb_stress-dev-v1-0-1c14942b1...@riseup.net/ >> >> In that case you would need to document exactly what command line >> options to use, and ask people to report the numbers of each test >> case. >> >> That works. Alternatively or additionally, the test cases could be >> built in to the benchmark, and it just reports numbers for all of them >> in a single invocation. Then people running the standard benchmark do >> not need to worry about getting the command line options right, or >> running multiple cases. And reviewers do not need to ask to re-run with >> the correct options. >> >> I suppose rotations might get added, too. >> >> Or maybe you'd provide a script that covers all the standard >> performance test cases? > > I agree with Pekka, it would be nice to have a simple "bench everything" > tool. Like kms_rotation is a test for all rotations, kms_plane for color > conversions... kms_fb_test can run a few combinations (rgb+norotation, > rgb+yuv, rgb+rotation...) and report a "global result" (this way it's easy > to spot a regression not related directly to your changes). > > I don't know the IGT benchmark API, but I think there is a way to create > "sub-benchmarks" so you can run a specific benchmark when developping and > the whole thing before pushing your series. > > Kind regards, > Louis Chauvet > Thank you guys for the ideas! I'm going to work on something along on those lines, having combinations of formats, rotations and whatever property that might be useful for stress testing the driver. Maybe query the driver for the supported properties (e.g. what formats and rotations it supports) and do many/all possible combinations. Best Regards, ~Arthur Grillo >> >> Thanks, >> pq >> start printing YUV numbers separately as a new case. Thanks, pq > >> >>> + >>> + sudo ./build/benchmarks/kms_fb_stress --device >>> "sys:/sys/devices/platform/vkms" >>> + sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" >>> ./build/benchmarks/kms_fb_stress >> >> Do people need to run both commands? > > No, they don't, just two options. > > Best Regards, > ~Arthur Grillo > >> >> Anyway, a good idea. >> >> Acked-by: Pekka Paalanen >> >> >> Thanks, >> pq >> >>> + >>> TODO >>> >>> >>> >>> --- >>> base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f >>> change-id: 20240226-bench-vkms-5b8b7aab255e >>> >>> Best regards, >> >> > > >
Re: [PATCH 1/2] drm_edid: Add a function to get EDID base block
Hi, On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula wrote: > > On Fri, 23 Feb 2024, Hsin-Yi Wang wrote: > > It's found that some panels have variants that they share the same panel id > > although their EDID and names are different. Besides panel id, now we need > > the hash of entire EDID base block to distinguish these panel variants. > > > > Add drm_edid_get_base_block to returns the EDID base block, so caller can > > further use it to get panel id and/or the hash. > > Please reconsider the whole approach here. > > Please let's not add single-use special case functions to read an EDID > base block. > > Please consider reading the whole EDID, using the regular EDID reading > functions, and use that instead. > > Most likely you'll only have 1-2 blocks anyway. And you might consider > caching the EDID in struct panel_edp if reading the entire EDID is too > slow. (And if it is, this is probably sensible even if the EDID only > consists of one block.) That makes a lot of sense! Not quite sure why I didn't just read the whole EDID in the first place when trying to get the panel ID. -Doug
Re: [DO NOT MERGE v6 13/37] dt-bindings: clock: sh7750-cpg: Add renesas,sh7750-cpg header.
Hi Sato-san,
Thanks for your patch!
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> SH7750 CPG Clock output define.
Please improve the patch description.
> Signed-off-by: Yoshinori Sato
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/renesas,sh7750-cpg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7750/7751 Clock Pulse Generator (CPG)
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + The Clock Pulse Generator (CPG) generates core clocks for the SoC. It
> + includes PLLs, and variable ratio dividers.
> +
> + The CPG may also provide a Clock Domain for SoC devices, in combination
> with
> + the CPG Module Stop (MSTP) Clocks.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,sh7750-cpg # SH7750
> + - renesas,sh7750s-cpg# SH775S
> + - renesas,sh7750r-cpg# SH7750R
> + - renesas,sh7751-cpg # SH7751
> + - renesas,sh7751r-cpg# SH7751R
> +
> + reg: true
> +
> + reg-names: true
> +
> + clocks: true
clocks:
maxItems: 1
> +
> + clock-names: true
clock-names:
const: extal
> +examples:
> + - |
> +#include
> +cpg: clock-controller@ffc0 {
> +#clock-cells = <1>;
> +#power-domain-cells = <0>;
> +compatible = "renesas,sh7751r-cpg";
> +clocks = <&xtal>;
> +clock-names = "xtal";
"extal"
"xtal" is an output pin, connected to a crystal resonator.
"extal" is the clock input put (either crystal resonator or exteral
clock input.
> +reg = <0xffc0 20>, <0xfe0a 16>;
> +reg-names = "FRQCR", "CLKSTP00";
> +renesas,mode = <0>;
> +};
> diff --git a/include/dt-bindings/clock/sh7750-cpg.h
> b/include/dt-bindings/clock/sh7750-cpg.h
> new file mode 100644
> index ..17d5a8076aac
> --- /dev/null
> +++ b/include/dt-bindings/clock/sh7750-cpg.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> + *
> + * Copyright 2023 Yoshinori Sato
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_SH7750_H__
> +#define __DT_BINDINGS_CLOCK_SH7750_H__
> +
> +#define SH7750_CPG_PLLOUT 0
> +
> +#define SH7750_CPG_FCK 1
PCK?
> +#define SH7750_CPG_BCK 2
> +#define SH7750_CPG_ICK 3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 15/37] clk: renesas: Add SH7750/7751 CPG Driver
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Renesas SH7750 and SH7751 series CPG driver.
> This driver supported frequency control and clock gating.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -193,6 +196,10 @@ config CLK_SH73A0
> select CLK_RENESAS_CPG_MSTP
> select CLK_RENESAS_DIV6
>
> +config CLK_SH7750
> + bool "SH7750/7751 family clock support" if COMPILE_TEST
> + help
> + This is a driver for SH7750 / SH7751 CPG.
This is a duplicate of the below. Please drop it.
>
> # Family
> config CLK_RCAR_CPG_LIB
> @@ -223,6 +230,11 @@ config CLK_RZG2L
> bool "Renesas RZ/{G2L,G2UL,G3S,V2L} family clock support" if
> COMPILE_TEST
> select RESET_CONTROLLER
>
> +config CLK_SH7750
> + bool "Renesas SH7750/7751 family clock support" if COMPILE_TEST
> + help
> + This is a driver for SH7750 / SH7751 CPG.
> +
> # Generic
> config CLK_RENESAS_CPG_MSSR
> bool "CPG/MSSR clock support" if COMPILE_TEST
> --- /dev/null
> +++ b/drivers/clk/renesas/clk-sh7750.c
> +static int register_pll(struct device_node *node, struct cpg_priv *cpg)
> +{
> + const char *clk_name = node->name;
> + const char *parent_name;
> + struct clk_init_data init = {
> + .name = PLLOUT,
> + .ops = &pll_ops,
> + .flags = 0,
> + .num_parents = 1,
> + };
> + int ret;
> +
> + parent_name = of_clk_get_parent_name(node, 0);
> + init.parent_names = &parent_name;
> + cpg->hw.init = &init;
> +
> + ret = of_clk_hw_register(node, &cpg->hw);
> + if (ret < 0) {
> + pr_err("%s: failed to register %s pll clock (%d)\n",
> + __func__, clk_name, ret);
> + return ret;
> + }
> + if (ret < 0)
> + pr_err("%s: failed to add provider %s (%d)\n",
> + __func__, clk_name, ret);
Bogus check and error message.
> + return ret;
> +}
> +static int register_div(struct device_node *node, struct cpg_priv *cpg)
> +{
> + static const char * const divout[] = {
> + "fck", "bck", "ick",
> + };
> + static const char * const stbcrout[] = {
> + "sci_clk", "rtc_clk", "tmu012_clk", /* STBCR */
> + "scif_clk", "dmac_clk", /* STBCR */
> + "ubc_clk", "sq_clk",/* STBCR2 */
> + };
> + static const char * const clkstpout[] = {
> + "intc_clk", "tmu34_clk", "pcic_clk",/* CLKSTP00 */
> + };
> +
> + unsigned int i;
> + int ret;
> + struct clk_hw_onecell_data *data;
> + struct clk_hw *reg_hw;
> + int num_clk = ARRAY_SIZE(divout) + ARRAY_SIZE(stbcrout) +
> ARRAY_SIZE(clkstpout);
> +
> + data = kzalloc(struct_size(data, hws, num_clk + 1), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + num_clk = 0;
> + for (i = 0; i < ARRAY_SIZE(divout); i++) {
> + reg_hw = __clk_hw_register_divider(NULL, node, divout[i],
> + PLLOUT, NULL, NULL,
> + 0, cpg->frqcr, i * 3, 3,
> + CLK_DIVIDER_REG_16BIT,
> + (i == 0) ? pdiv_table :
> div_table,
> + &cpg->clklock);
> + if (IS_ERR(reg_hw)) {
> + ret = PTR_ERR(reg_hw);
> + goto error;
> + }
> + data->hws[num_clk++] = reg_hw;
> + }
> + for (i = 0; i < ARRAY_SIZE(stbcrout); i++) {
> + u32 off = (i < 5) ? STBCR : STBCR2;
> +
> + if (i >= 5 && !(cpg->feat & MSTP_CR2))
> + break;
Alternatively, you could set the maximum loop counter upfront
n = cpg->feat & MSTP_CR2 ? ARRAY_SIZE(stbcrout) : 5;
for (i = 0; i < n; i++) ...
> + reg_hw = __clk_hw_register_gate(NULL, node, stbcrout[i],
> + divout[0], NULL, NULL,
> + 0, cpg->frqcr + off, i % 5,
> + CLK_GATE_REG_8BIT |
> CLK_GATE_SET_TO_DISABLE,
> + &cpg->clklock);
> + if (IS_ERR(reg_hw)) {
> + ret = PTR_ERR(reg_hw);
> + goto error;
> + }
> + data->hws[num_clk++] = reg_hw;
> + }
> + if (cpg->feat & MSTP_CLKSTP) {
> + for (i = 0; i < ARRAY_SIZE(clkstpout); i++) {
> + if (i == 2 && !(cpg->feat & MSTP_CSTP2))
> + continue;
Set maximum loop
Re: [PATCH] drm/test/shmem: set a DMA mask for the mock device
Hi, On Mon, Feb 26, 2024 at 04:48:51PM +0100, Marco Pagani wrote: > > On 2024-02-26 12:26, Maxime Ripard wrote: > > Hi, > > > > On Mon, Feb 26, 2024 at 12:00:27PM +0100, Marco Pagani wrote: > >> Set a DMA mask for the mock device to avoid warnings generated in > >> dma_map_sgtable(). > >> > >> Reported-by: Guenter Roeck > >> Signed-off-by: Marco Pagani > > > > I've submitted last week this patch: > > https://lore.kernel.org/all/20240221125324.718192-1-mrip...@kernel.org/ > > > > Which should be equivalent, but fixes the issue for all users in the > > tree. > > Hi, thanks for letting me know. Fixing this issue for all DRM tests that were > using platform devices through the helpers makes perfect sense to me. I'm a > little more thoughtful about setting the mask for all KUnit tests that use > fake > devices since there may be specific use cases. Just one curiosity: why setting > the default mask manually instead of using one of the dma_set_*() functions? I think the (well, mine at least) expectation is that a kunit device is a device that can be used in all reasonable contexts. Setting up the device to be able to use any DMA-related function (or functions that use a DMA-related function) makes total sense to me. But it's a discussion worth having I think, so it would make sense to raise this point with the kunit maintainers if you feel like it. Maxime signature.asc Description: PGP signature
[PULL] drm-intel-next
Hi Dave & Sima -
Final i915 feature pull for v6.9.
drm-intel-next-2024-02-27-1:
drm/i915 feature pull #2 for v6.9:
Features and functionality:
- DP tunneling and bandwidth allocation support (Imre)
- Add more ADL-N PCI IDs (Gustavo)
- Enable fastboot also on older platforms (Ville)
- Bigjoiner force enable debugfs option for testing (Stan)
Refactoring and cleanups:
- Remove unused structs and struct members (Jiri Slaby)
- Use per-device debug logging (Ville)
- State check improvements (Ville)
- Hardcoded cd2x divider cleanups (Ville)
- CDCLK documentation updates (Ville, Rodrigo)
Fixes:
- HDCP MST Type1 fixes (Suraj)
- Fix MTL C20 PHY PLL values (Ravi)
- More hardware access prevention during init (Imre)
- Always enable decompression with tile4 on Xe2 (Juha-Pekka)
- Improve LNL package C residency (Suraj)
drm core changes:
- DP tunneling and bandwidth allocation helpers (Imre)
BR,
Jani.
The following changes since commit 449c2d5948ba8c784dcbc5c67df1d8c54748caa4:
drm/i915/alpm: Alpm aux wake configuration for lnl (2024-02-07 09:58:04 +0200)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2024-02-27-1
for you to fetch changes up to e60cff453b82789a652239c6200bd90d5178d2a0:
drm/i915/dp: Enable DP tunnel BW allocation mode (2024-02-27 17:35:14 +0200)
drm/i915 feature pull #2 for v6.9:
Features and functionality:
- DP tunneling and bandwidth allocation support (Imre)
- Add more ADL-N PCI IDs (Gustavo)
- Enable fastboot also on older platforms (Ville)
- Bigjoiner force enable debugfs option for testing (Stan)
Refactoring and cleanups:
- Remove unused structs and struct members (Jiri Slaby)
- Use per-device debug logging (Ville)
- State check improvements (Ville)
- Hardcoded cd2x divider cleanups (Ville)
- CDCLK documentation updates (Ville, Rodrigo)
Fixes:
- HDCP MST Type1 fixes (Suraj)
- Fix MTL C20 PHY PLL values (Ravi)
- More hardware access prevention during init (Imre)
- Always enable decompression with tile4 on Xe2 (Juha-Pekka)
- Improve LNL package C residency (Suraj)
drm core changes:
- DP tunneling and bandwidth allocation helpers (Imre)
Bhanuprakash Modem (1):
drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
Gustavo Sousa (1):
drm/i915: Update ADL-N PCI IDs
Imre Deak (23):
drm/i915: Prevent HW access during init from SDVO TV get_modes hook
drm/i915: Prevent HW access during init from connector get_modes hooks
drm/dp: Add drm_dp_max_dprx_data_rate()
drm/dp: Add support for DP tunneling
drm/i915: Fix display bpp limit computation during system resume
drm/i915/dp: Add support to notify MST connectors to retry modesets
drm/i915/dp: Use drm_dp_max_dprx_data_rate()
drm/i915/dp: Factor out intel_dp_config_required_rate()
drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
drm/i915/dp: Factor out intel_dp_update_sink_caps()
drm/i915/dp: Factor out intel_dp_read_dprx_caps()
drm/i915/dp: Add intel_dp_max_link_data_rate()
drm/i915/dp: Sync instead of try-sync commits when getting active pipes
drm/i915/dp: Add support for DP tunnel BW allocation
drm/i915/dp: Add DP tunnel atomic state and check BW limit
drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()
drm/i915/dp: Compute DP tunnel BW during encoder state computation
drm/i915/dp: Allocate/free DP tunnel BW during modeset
drm/i915/dp: Handle DP tunnel IRQs
drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
drm/i915/dp: Suspend/resume DP tunnels
drm/i915/dp: Read DPRX for all long HPD pulses
drm/i915/dp: Enable DP tunnel BW allocation mode
Jiri Slaby (SUSE) (21):
drm/i915: remove unused intel_dvo_dev_ops hooks
drm/i915: remove structs intel_vgpu_pipe_format and intel_vgpu_fb_format
drm/i915: remove intel_dsi::{port_bits,hs}
drm/i915: remove intel_gvt_gtt::{mm_alloc_page_table, mm_free_page_table}
drm/i915: remove intel_gvt_mmio_info::{device, addr_range}
drm/i915: remove intel_vgpu_workload::{ring_context, restore_inhibit}
drm/i915: remove intel_vbt_panel_data::edp::initialized
drm/i915: remove intel_guc::ads_engine_usage_size
drm/i915: remove i915_drm_client::id
drm/i915: remove i915_perf_stream::size_exponent
drm/i915: remove intel_vgpu_gtt::active_ppgtt_mm_bitmap
drm/i915: remove intel_vgpu_fence::base
drm/i915: remove intel_vgpu_opregion::mapped
drm/i915: remove intel_vgpu::intx_trigger
drm/i915: remove gvt_mmio_block::device
drm/i915: remove intel_gvt_irq_info::warned
drm/i915: remove intel_gvt_event_info::policy
drm/i915: remove intel_gvt_irq::pending_events
drm/i915: remove execute_cb::signal
drm/i915: remove i915_
Re: [DO NOT MERGE v6 33/37] sh: j2_mimas_v2.dts update
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
Please enhance the one-line summary, e.g.
sh: j2_mimas_v2: Update CPU compatible value
For the actual changes:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [DO NOT MERGE v6 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/renesas/sh.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH Platform
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +properties:
> + $nodename:
> +const: '/'
> + compatible:
> +oneOf:
> + - description: RTS7751R2D Plus
> +items:
> + - enum:
> + - renesas,rts7751r2d # Renesas SH4 2D graphics board
> + - const: renesas,sh7751r
> +
> + - description: Julian board
> +items:
> + - enum:
> + - iodata,landisk # LANDISK HDL-U
> + - iodata,usl-5p # USL-5P
> + - const: renesas,sh7751r
As both use the same fallback compatible value, I would just merge
them into a single section for SH7751R.
> +
> +additionalProperties: true
> +
> +...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: Making drm_gpuvm work across gpu devices
From: Christian König Sent: Tuesday, February 27, 2024 1:54 AM To: Zeng, Oak ; Danilo Krummrich ; Dave Airlie ; Daniel Vetter ; Felix Kuehling ; jgli...@redhat.com Cc: Welty, Brian ; dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Bommu, Krishnaiah ; Ghimiray, Himal Prasad ; thomas.hellst...@linux.intel.com; Vishwanathapura, Niranjana ; Brost, Matthew ; Gupta, saurabhg Subject: Re: Making drm_gpuvm work across gpu devices Hi Oak, Am 23.02.24 um 21:12 schrieb Zeng, Oak: Hi Christian, I go back this old email to ask a question. sorry totally missed that one. Quote from your email: “Those ranges can then be used to implement the SVM feature required for higher level APIs and not something you need at the UAPI or even inside the low level kernel memory management.” “SVM is a high level concept of OpenCL, Cuda, ROCm etc.. This should not have any influence on the design of the kernel UAPI.” There are two category of SVM: 1. driver svm allocator: this is implemented in user space, i.g., cudaMallocManaged (cuda) or zeMemAllocShared (L0) or clSVMAlloc(openCL). Intel already have gem_create/vm_bind in xekmd and our umd implemented clSVMAlloc and zeMemAllocShared on top of gem_create/vm_bind. Range A..B of the process address space is mapped into a range C..D of the GPU address space, exactly as you said. 2. system svm allocator: This doesn’t introduce extra driver API for memory allocation. Any valid CPU virtual address can be used directly transparently in a GPU program without any extra driver API call. Quote from kernel Documentation/vm/hmm.hst: “Any application memory region (private anonymous, shared memory, or regular file backed memory) can be used by a device transparently” and “to share the address space by duplicating the CPU page table in the device page table so the same address points to the same physical memory for any valid main memory address in the process address space”. In system svm allocator, we don’t need that A..B C..D mapping. It looks like you were talking of 1). Were you? No, even when you fully mirror the whole address space from a process into the GPU you still need to enable this somehow with an IOCTL. And while enabling this you absolutely should specify to which part of the address space this mirroring applies and where it maps to. Lets say we have a hardware platform where both CPU and GPU support 57bit virtual address range, how do you decide “which part of the address space this mirroring applies”? You have to mirror the whole address space (0~2^57-1), do you? As you designed it, the gigantic vm_bind/mirroring happens at the process initialization time, and at that time, you don’t know which part of the address space will be used for gpu program. I see the system svm allocator as just a special case of the driver allocator where not fully backed buffer objects are allocated, but rather sparse one which are filled and migrated on demand. Above statement is true to me. We don’t have BO for system svm allocator. It is a sparse one as we don’t map the whole vma to GPU. Our migration policy decide which pages/how much of the vma is migrated/mapped to GPU page table. The difference b/t your mind and mine is, you want a gigantic vma (created during the gigantic vm_bind) to be sparsely populated to gpu. While I thought vma (xe_vma in xekmd codes) is a place to save memory attributes (such as caching, user preferred placement etc). All those memory attributes are range based, i.e., user can specify range1 is cached while range2 is uncached. So I don’t see how you can manage it with the gigantic vma. Regards, Oak Regards, Christian.
Re: ✗ Fi.CI.IGT: failure for drm/i915: Add Display Port tunnel BW allocation support (rev6)
On Tue, Feb 27, 2024 at 02:21:29PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add Display Port tunnel BW allocation support (rev6) > URL : https://patchwork.freedesktop.org/series/129082/ > State : failure Thanks for the reviews,acks, patchset is pushed to drm-intel-next. The failure is unrelated see below. > > == Summary == > > CI Bug Log - changes from CI_DRM_14345_full -> Patchwork_129082v6_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_129082v6_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_129082v6_full, please notify your bug team > (i915-ci-in...@lists.freedesktop.org) to allow them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (8 -> 8) > -- > > No changes in participating hosts > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_129082v6_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_fbcon_fbt@fbc-suspend: > - shard-snb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-snb7/igt@kms_fbcon_...@fbc-suspend.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129082v6/shard-snb7/igt@kms_fbcon_...@fbc-suspend.html No TBT/DP tunnels on the above machine, an unrelated system/suspend resume problem in the EPB driver: <7>[ 554.320951] Calling intel_epb_restore+0x0/0xb0 <4>[ 554.320956] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0x8104d4d3 (intel_epb_restore+0x13/0xb0) The same was already reported at: https://gitlab.freedesktop.org/drm/intel/-/issues/10007 > Warnings > > * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move: > - shard-snb: [SKIP][3] ([fdo#109271]) -> [FAIL][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-snb5/igt@kms_frontbuffer_track...@psr-2p-scndscrn-cur-indfb-move.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129082v6/shard-snb4/igt@kms_frontbuffer_track...@psr-2p-scndscrn-cur-indfb-move.html > > > Known issues > > > Here are the changes found in Patchwork_129082v6_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], > [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], > [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], > [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], > [PASS][27], [PASS][28], [FAIL][29]) ([i915#8293]) -> ([PASS][30], [PASS][31], > [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], > [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], > [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], > [PASS][50], [PASS][51], [PASS][52], [PASS][53]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk9/boot.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk9/boot.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk9/boot.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk8/boot.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk8/boot.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk8/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk7/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk7/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk7/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk5/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk5/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk5/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk4/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk4/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk4/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk3/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk3/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk3/boot.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14345/shard-glk3/boot.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On 22/02/2024 16:55, Abel Vesa wrote: > Add the X1E80100 to the list of compatibles and document the is-edp > flag. The controllers are expected to operate in DP mode by default, > and this flag can be used to select eDP mode. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > index ae53cbfb2193..ed11852e403d 100644 > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > @@ -27,6 +27,7 @@ properties: >- qcom,sdm845-dp >- qcom,sm8350-dp >- qcom,sm8650-dp > + - qcom,x1e80100-dp >- items: >- enum: >- qcom,sm8150-dp > @@ -73,6 +74,11 @@ properties: >- description: phy 0 parent >- description: phy 1 parent > > + is-edp: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + Tells the controller to switch to eDP mode DP controller cannot be edp, so property "is-edp" is confusing. Probably you want to choose some phy mode, so you should rather use "phy-mode" property. I am sure we've been here... Anyway, if you define completely new property without vendor prefix, that's a generic property, so you need to put it in some common schema for all Display Controllers, not only Qualcomm. Best regards, Krzysztof
Re: [DO NOT MERGE v6 14/37] clk: Compatible with narrow registers
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> divider and gate only support 32-bit registers.
> Older hardware uses narrower registers, so I want to be able to handle
> 8-bit and 16-bit wide registers.
>
> Seven clk_divider flags are used, and if I add flags for 8bit access and
> 16bit access, 8bit will not be enough, so I expanded it to u16.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/drivers/clk/clk-gate.c
> +++ b/drivers/clk/clk-gate.c
> @@ -143,6 +161,18 @@ struct clk_hw *__clk_hw_register_gate(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
Please add a check for invalid CLK_GATE_HIWORD_MASK
and register width combinations:
if (clk_gate_flags & (CLK_GATE_REG_16BIT | CLK_GATE_REG_8BIT)) {
pr_err("HIWORD_MASK needs 32-bit registers\n");
return ERR_PTR(-EINVAL);
}
> }
> + if (clk_gate_flags & CLK_GATE_REG_16BIT) {
> + if (bit_idx > 15) {
> + pr_err("gate bit exceeds 16 bits\n");
> + return ERR_PTR(-EINVAL);
> + }
> + }
> + if (clk_gate_flags & CLK_GATE_REG_8BIT) {
> + if (bit_idx > 7) {
> + pr_err("gate bit exceeds 8 bits\n");
> + return ERR_PTR(-EINVAL);
> + }
> + }
>
> /* allocate the gate */
> gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index ace3a4ce2fc9..e2dfc1f083f4 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -508,12 +508,16 @@ void of_fixed_clk_setup(struct device_node *np);
> * CLK_GATE_BIG_ENDIAN - by default little endian register accesses are used
> for
> * the gate register. Setting this flag makes the register accesses big
> * endian.
> + * CLK_GATE_REG_8BIT - by default 32bit register accesses are used for
> + * the gate register. Setting this flag makes the register accesses
> 8bit.
> + * CLK_GATE_REG_16BIT - by default 32bit register accesses are used for
> + * the gate register. Setting this flag makes the register accesses
> 16bit.
> */
> struct clk_gate {
> struct clk_hw hw;
> void __iomem*reg;
> u8 bit_idx;
> - u8 flags;
> + u32 flags;
There is no need to increase the size of the flags field for the gate clock.
> spinlock_t *lock;
> };
>
> @@ -522,6 +526,8 @@ struct clk_gate {
> #define CLK_GATE_SET_TO_DISABLEBIT(0)
> #define CLK_GATE_HIWORD_MASK BIT(1)
> #define CLK_GATE_BIG_ENDIANBIT(2)
> +#define CLK_GATE_REG_8BIT BIT(3)
> +#define CLK_GATE_REG_16BIT BIT(4)
>
> extern const struct clk_ops clk_gate_ops;
> struct clk_hw *__clk_hw_register_gate(struct device *dev,
The rest LGTM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console
Hi
Am 27.02.24 um 15:03 schrieb Christian König:
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Oh, wow. That was quick! Thanks a lot.
Best regards
Thomas
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM's console emulation. Similar changes
for vmap and mmap have been posted at [1][2]
Most DRM drivers and memory managers acquire the buffer object's
reservation lock within their GEM pin and unpin callbacks. This
violates dma-buf locking semantics. We get away with it because PRIME
does not provide pin/unpin, but attach/detach, for which the locking
semantics is correct.
Patches 1 to 8 rework DRM GEM code in various implementations to
acquire the reservation lock when entering the pin and unpin callbacks.
This prepares them for the next patch. Drivers that are not affected
by these patches either don't acquire the reservation lock (amdgpu)
or don't need preparation (loongson).
Patch 9 moves reservation locking from the GEM pin/unpin callbacks
into drm_gem_pin() and drm_gem_unpin(). As PRIME uses these functions
internally it still gets the reservation lock.
With the updated GEM callbacks, the rest of the patchset fixes the
fbdev emulation's buffer locking. Fbdev emulation needs to keep its
GEM buffer object inplace while updating its content. This required
a implicit pinning and apparently amdgpu didn't do this at all.
Patch 10 introduces drm_client_buffer_vmap_local() and _vunmap_local().
The former function map a GEM buffer into the kernel's address space
with regular vmap operations, but keeps holding the reservation lock.
The _vunmap_local() helper undoes the vmap and releases the lock. The
updated GEM callbacks make this possible. Between the two calls, the
fbdev emulation can update the buffer content without have the buffer
moved or evicted. Update fbdev-generic to use vmap_local helpers,
which fix amdgpu. The idea of adding a "local vmap" has previously been
attempted at [3] in a different form.
Patch 11 adds implicit pinning to the DRM client's regular vmap
helper so that long-term vmap'ed buffers won't be evicted. This only
affects fbdev-dma, but GEM DMA helpers don't require pinning. So
there are no practical changes.
Patches 12 and 13 remove implicit pinning from the vmap and vunmap
operations in gem-vram and qxl. These pin operations are not supposed
to be part of vmap code, but were required to keep the buffers in place
for fbdev emulation. With the conversion o ffbdev-generic to to
vmap_local helpers, that code can finally be removed.
Tested with amdgpu, nouveau, radeon, simpledrm and vc4.
[1] https://patchwork.freedesktop.org/series/106371/
[2] https://patchwork.freedesktop.org/series/116001/
[3] https://patchwork.freedesktop.org/series/84732/
Thomas Zimmermann (13):
drm/gem-shmem: Acquire reservation lock in GEM pin/unpin callbacks
drm/gem-vram: Acquire reservation lock in GEM pin/unpin callbacks
drm/msm: Provide msm_gem_get_pages_locked()
drm/msm: Acquire reservation lock in GEM pin/unpin callback
drm/nouveau: Provide nouveau_bo_{pin,unpin}_locked()
drm/nouveau: Acquire reservation lock in GEM pin/unpin callbacks
drm/qxl: Provide qxl_bo_{pin,unpin}_locked()
drm/qxl: Acquire reservation lock in GEM pin/unpin callbacks
drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()
drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
drm/client: Pin vmap'ed GEM buffers
drm/gem-vram: Do not pin buffer objects for vmap
drm/qxl: Do not pin buffer objects for vmap
drivers/gpu/drm/drm_client.c | 92 ++---
drivers/gpu/drm/drm_fbdev_generic.c | 4 +-
drivers/gpu/drm/drm_gem.c | 34 +++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 101 ++--
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/loongson/lsdc_gem.c | 13 +--
drivers/gpu/drm/msm/msm_gem.c | 20 ++---
drivers/gpu/drm/msm/msm_gem.h | 4 +-
drivers/gpu/drm/msm/msm_gem_prime.c | 20 +++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 43 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h | 2 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +-
drivers/gpu/drm/qxl/qxl_object.c | 26 +++---
drivers/gpu/drm/qxl/qxl_object.h | 2 +
drivers/gpu/drm/qxl/qxl_prime.c | 4 +-
drivers/gpu/drm/radeon/radeon_prime.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 25 ++
include/drm/drm_client.h | 10 +++
include/drm/drm_gem.h | 3 +
include/drm/drm_gem_shmem_helper.h | 7 +-
21 files changed, 265 insertions(+), 172 dele
Re: [PATCH 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document
On 27/02/2024 10:01, Krzysztof Kozlowski wrote: On 26/02/2024 15:01, Alexandre Mergnat wrote: Add MT8365 audio front-end bindings Signed-off-by: Alexandre Mergnat --- .../bindings/sound/mediatek,mt8365-afe.yaml| 164 + 1 file changed, 164 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml new file mode 100644 index ..1d7eb2532ad2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml @@ -0,0 +1,164 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mediatek,mt8365-afe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek AFE PCM controller for MT8365 + +maintainers: + - Alexandre Mergnat + +properties: + compatible: +const: mediatek,mt8365-afe-pcm + + reg: +maxItems: 2 You must describe the items. Actually, I've took downstream code that I'm not able to explain because the second reg isn't on my MTK documentation. So I've remove the second reg and passed all functional tests successfully. Then I will remove the extra reg for v2. + + interrupts: +maxItems: 1 + + mediatek,topckgen: +$ref: /schemas/types.yaml#/definitions/phandle +description: The phandle of the mediatek topckgen controller What for? Don't repeat the property name. Say something useful. got it + + power-domains: +maxItems: 1 + + "#sound-dai-cells": +const: 0 + + clocks: +items: + - description: 26M clock + - description: mux for audio clock + - description: audio i2s0 mck + - description: audio i2s1 mck + - description: audio i2s2 mck + - description: audio i2s3 mck + - description: engen 1 clock + - description: engen 2 clock + - description: audio 1 clock + - description: audio 2 clock + - description: mux for i2s0 + - description: mux for i2s1 + - description: mux for i2s2 + - description: mux for i2s3 + + clock-names: +items: + - const: top_clk26m_clk + - const: top_audio_sel + - const: audio_i2s0_m + - const: audio_i2s1_m + - const: audio_i2s2_m + - const: audio_i2s3_m + - const: engen1 + - const: engen2 + - const: aud1 + - const: aud2 + - const: i2s0_m_sel + - const: i2s1_m_sel + - const: i2s2_m_sel + - const: i2s3_m_sel + + mediatek,i2s-shared-clock: Why do you need this property? Linux (and other systems) handle sharing clocks properly. Indeed, not needed. It was used by the downstream code driver but I remove it for v2. +description: + i2s modules can share the same external clock pin. + If this property is not present the clock mode is separrate. Typo +type: boolean + + mediatek,dmic-iir-on: +description: + Boolean which specifies whether the DMIC IIR is enabled. + If this property is not present the IIR is disabled. "is enabled" or "enable it"? You described the desired Linux feature or behavior, not the actual hardware. The bindings are about the latter, so instead you need to rephrase the property and its description to match actual hardware capabilities/features/configuration etc. I will rephrase: True to enable the Infinite Impulse Response (IIR) filter on the digital microphone inputs. +type: boolean + + mediatek,dmic-irr-mode: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects stop band of IIR DC-removal filter. + 0 = Software programmable custom coeff loaded by the driver. Bindings are for hardware, not drivers. Why is this a property of board DTS? Actually this is a hardware feature. Mode 1 t 5 are predefined filters. Mode 0, the HW will read some "coef filter registers" to setup the custom filter. the "coef filter regs" are written by the driver. Currently the coef values are hardcoded in the driver. + 1 = 5Hz if 48KHz mode. + 2 = 10Hz if 48KHz mode. + 3 = 25Hz if 48KHz mode. + 4 = 50Hz if 48KHz mode. + 5 = 65Hz if 48KHz mode. Use proper unit suffixes - hz. +enum: + - 0 + - 1 + - 2 + - 3 + - 4 + - 5 + + mediatek,dmic-two-wire-mode: +description: + Boolean which turns on digital microphone for two wire mode. + If this property is not present the two wire mode is disabled. This looks like hardware property, but the naming looks like SW. Again you instruct what driver should do. Standard disclaimer: You described the desired Linux feature or behavior, not the actual hardware. The bindings are about the latter, so instead you need to rephrase the property and its description to match actual hardware capabilities/features/configuration etc. Actually this is a hardware feature. This is ALL I have to describe the HW behavior from the datasheet: " bit n
Re: [PATCH 4/6] arm64: dts: renesas: r8a77951: Enable GPU
On Tue, Feb 27, 2024 at 2:11 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> Thanks for your patch!
>
> On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> > The GPU on the R-Car H3 is a Rogue GX6650 which uses firmware
> > rogue_4.46.6.61_v1.fw available from Imagination.
>
> s/61/62/
>
> >
> > When enumerated, it appears as:
> > powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Do you have a different build number?
I don't actually have this board. I just copy-pasted what I thought
it was. If you have build number that's more appropriate, I can use
that in the future.
adam
>
> On Salvator-XS with R-Car H3 ES2.0:
>
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6538781 OS)
> [drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 1
>
> >
> > Signed-off-by: Adam Ford
>
> Tested-by: Geert Uytterhoeven
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > @@ -2771,6 +2771,16 @@ gic: interrupt-controller@f101 {
> > resets = <&cpg 408>;
> > };
> >
> > + gpu: gpu@fd00 {
> > + compatible = "renesas,r8a77951-gpu", "img,img-axe";
>
> renesas,r8a7795-gpu
>
> > + reg = <0 0xfd00 0 0x2>;
> > + clocks = <&cpg CPG_MOD 112>;
> > + clock-names = "core";
> > + interrupts = ;
> > + power-domains = <&sysc R8A7795_PD_3DG_E>;
> > + resets = <&cpg 112>;
> > + };
> > +
> > pciec0: pcie@fe00 {
> > compatible = "renesas,pcie-r8a7795",
> > "renesas,pcie-rcar-gen3";
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board
On Mon, Feb 26, 2024 at 03:01:38PM +0100, Alexandre Mergnat wrote: > This serie aim to add the following audio support for the Genio 350-evk: > - Playback > - 2ch Headset Jack (Earphone) > - 1ch Line-out Jack (Speaker) > - 8ch HDMI Tx > - Capture > - 1ch DMIC (On-board Digital Microphone) > - 1ch AMIC (On-board Analogic Microphone) > - 1ch Headset Jack (External Analogic Microphone) > > Of course, HDMI playback need the MT8365 display patches [1] and a DTS > change documented in "mediatek,mt8365-mt6357.yaml". Given the number of custom controls here could you please post the output of mixer-test and pcm-test from a system with this driver running next time you post, this will help with review since it checks a bunch of things around the new controls. signature.asc Description: PGP signature
Re: [PATCH v2 6/9] drm/vkms: Add YUV support
Hi Pekka,
For all the comment related to the conversion part, maybe Arthur have an
opinion on it, I took his patch as a "black box" (I did not want to
break (and debug) it).
Le 26/02/24 - 14:19, Pekka Paalanen a écrit :
> On Fri, 23 Feb 2024 12:37:26 +0100
> Louis Chauvet wrote:
>
> > From: Arthur Grillo
> >
> > Add support to the YUV formats bellow:
> >
> > - NV12
> > - NV16
> > - NV24
> > - NV21
> > - NV61
> > - NV42
> > - YUV420
> > - YUV422
> > - YUV444
> > - YVU420
> > - YVU422
> > - YVU444
> >
> > The conversion matrices of each encoding and range were obtained by
> > rounding the values of the original conversion matrices multiplied by
> > 2^8. This is done to avoid the use of fixed point operations.
> >
> > Signed-off-by: Arthur Grillo
> > [Louis Chauvet: Adapted Arthur's work and implemented the read_line_t
> > callbacks for yuv formats]
> > Signed-off-by: Louis Chauvet
> > ---
> > drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
> > drivers/gpu/drm/vkms/vkms_drv.h | 6 +-
> > drivers/gpu/drm/vkms/vkms_formats.c | 289
> > +--
> > drivers/gpu/drm/vkms/vkms_formats.h | 4 +
> > drivers/gpu/drm/vkms/vkms_plane.c| 14 +-
> > 5 files changed, 295 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index e555bf9c1aee..54fc5161d565 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -312,7 +312,7 @@ static void blend(struct vkms_writeback_job *wb,
> > * buffer [1]
> > */
> > current_plane->pixel_read_line(
> > - current_plane->frame_info,
> > + current_plane,
> > x_start,
> > y_start,
> > direction,
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index ccc5be009f15..a4f6456cb971 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -75,6 +75,8 @@ enum pixel_read_direction {
> > READ_RIGHT
> > };
> >
> > +struct vkms_plane_state;
> > +
> > /**
> > <<< HEAD
> > * typedef pixel_read_line_t - These functions are used to read a pixel
> > line in the source frame,
> > @@ -87,8 +89,8 @@ enum pixel_read_direction {
> > * @out_pixel: Pointer where to write the pixel value. Pixels will be
> > written between x_start and
> > * x_end.
> > */
> > -typedef void (*pixel_read_line_t)(struct vkms_frame_info *frame_info, int
> > x_start, int y_start, enum
> > - pixel_read_direction direction, int count, struct pixel_argb_u16
> > out_pixel[]);
> > +typedef void (*pixel_read_line_t)(struct vkms_plane_state *frame_info, int
> > x_start, int y_start,
> > + enum pixel_read_direction direction, int count, struct pixel_argb_u16
> > out_pixel[]);
>
> This is the second or third time in this one series changing this type.
> Could you not do the change once, in its own patch if possible?
Sorry, this is not a change here, but a wrong formatting (missed when
rebasing).
Do you think that it make sense to re-order my patches and put this
typedef at the end? This way it is never updated.
> >
> > /**
> > * vkms_plane_state - Driver specific plane state
> > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
> > b/drivers/gpu/drm/vkms/vkms_formats.c
> > index 46daea6d3ee9..515c80866a58 100644
> > --- a/drivers/gpu/drm/vkms/vkms_formats.c
> > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > @@ -33,7 +33,8 @@ static size_t packed_pixels_offset(const struct
> > vkms_frame_info *frame_info, int
> > */
> > return fb->offsets[plane_index] +
> >(y / drm_format_info_block_width(format, plane_index)) *
> > fb->pitches[plane_index] +
> > - (x / drm_format_info_block_height(format, plane_index)) *
> > format->char_per_block[plane_index];
> > + (x / drm_format_info_block_height(format, plane_index)) *
> > + format->char_per_block[plane_index];
>
> Shouldn't this be in the patch that added this code in the first place?
Same as above, a wrong formatting, I will remove this change and keep
everything on one line (even if it's more than 100 chars, it is easier to
read).
> > }
> >
> > /**
> > @@ -84,6 +85,32 @@ static int get_step_1x1(struct drm_framebuffer *fb, enum
> > pixel_read_direction di
> > }
> > }
> >
> > +/**
> > + * get_subsampling() - Get the subsampling value on a specific direction
>
> subsampling divisor
Thanks for this precision.
> > + */
> > +static int get_subsampling(const struct drm_format_info *format,
> > + enum pixel_read_direction direction)
> > +{
> > + if (direction == READ_LEFT || direction == READ_RIGHT)
> > + return format->hsub;
> > + else if (direction == READ_DOWN || direction == READ_UP)
> > +
Re: [PATCH v3 4/9] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions
[...]
> > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> > b/drivers/gpu/drm/vkms/vkms_plane.c
> > index d5203f531d96..f68b1b03d632 100644
> > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > @@ -106,6 +106,13 @@ static void vkms_plane_atomic_update(struct drm_plane
> > *plane,
> > return;
> >
> > fmt = fb->format->format;
> > + pixel_read_t pixel_read = get_pixel_read_function(fmt);
> > +
> > + if (!pixel_read) {
> > + DRM_WARN("Pixel format is not supported by VKMS planes. State
> > is inchanged\n");
>
> s/inchanged/unchanged/
Thanks for this correction. See my answer to [1], I changed the message a
bit.
[1]:
https://lore.kernel.org/dri-devel/20240226133646.174d3fb2.pekka.paala...@collabora.com/
Kind regards,
Louis Chauvet
> > + return;
> > + }
> > +
> > vkms_plane_state = to_vkms_plane_state(new_state);
> > shadow_plane_state = &vkms_plane_state->base;
> >
> > @@ -124,7 +131,7 @@ static void vkms_plane_atomic_update(struct drm_plane
> > *plane,
> > drm_rect_rotate(&frame_info->rotated,
> > drm_rect_width(&frame_info->rotated),
> > drm_rect_height(&frame_info->rotated),
> > frame_info->rotation);
> >
> > - vkms_plane_state->pixel_read = get_pixel_conversion_function(fmt);
> > + vkms_plane_state->pixel_read = pixel_read;
> > }
> >
> > static int vkms_plane_atomic_check(struct drm_plane *plane,
> > diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
> > b/drivers/gpu/drm/vkms/vkms_writeback.c
> > index c8582df1f739..c92b9f06c4a4 100644
> > --- a/drivers/gpu/drm/vkms/vkms_writeback.c
> > +++ b/drivers/gpu/drm/vkms/vkms_writeback.c
> > @@ -140,6 +140,13 @@ static void vkms_wb_atomic_commit(struct drm_connector
> > *conn,
> > if (!conn_state)
> > return;
> >
> > + pixel_write_t pixel_write = get_pixel_write_function(wb_format);
> > +
> > + if (!pixel_write) {
> > + DRM_WARN("Pixel format is not supported by VKMS writeback.
> > State is inchanged\n");
>
> Same here
>
> Best Regards,
> ~Arthur Grillo
>
> > + return;
> > + }
> > +
> > vkms_set_composer(&vkmsdev->output, true);
> >
> > active_wb = conn_state->writeback_job->priv;
> > @@ -150,7 +157,7 @@ static void vkms_wb_atomic_commit(struct drm_connector
> > *conn,
> > crtc_state->wb_pending = true;
> > spin_unlock_irq(&output->composer_lock);
> > drm_writeback_queue_job(wb_conn, connector_state);
> > - active_wb->pixel_write = get_pixel_write_function(wb_format);
> > + active_wb->pixel_write = pixel_write;
> > drm_rect_init(&wb_frame_info->src, 0, 0, crtc_width, crtc_height);
> > drm_rect_init(&wb_frame_info->dst, 0, 0, crtc_width, crtc_height);
> > }
> >
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v3 5/9] drm/vkms: Re-introduce line-per-line composition algorithm
Le 26/02/24 - 11:14, Arthur Grillo a écrit :
>
>
> On 26/02/24 05:46, Louis Chauvet wrote:
> > Re-introduce a line-by-line composition algorithm for each pixel format.
> > This allows more performance by not requiring an indirection per pixel
> > read. This patch is focused on readability of the code.
> >
> > Line-by-line composition was introduced by [1] but rewritten back to
> > pixel-by-pixel algorithm in [2]. At this time, nobody noticed the impact
> > on performance, and it was merged.
> >
> > This patch is almost a revert of [2], but in addition efforts have been
> > made to increase readability and maintainability of the rotation handling.
> > The blend function is now divided in two parts:
> > - Transformation of coordinates from the output referential to the source
> > referential
> > - Line conversion and blending
> >
> > Most of the complexity of the rotation management is avoided by using
> > drm_rect_* helpers. The remaining complexity is around the clipping, to
> > avoid reading/writing outside source/destination buffers.
> >
> > The pixel conversion is now done line-by-line, so the read_pixel_t was
> > replaced with read_pixel_line_t callback. This way the indirection is only
> > required once per line and per plane, instead of once per pixel and per
> > plane.
> >
> > The read_line_t callbacks are very similar for most pixel format, but it
> > is required to avoid performance impact. Some helpers were created to
> > avoid code repetition:
> > - get_step_1x1: get the step in byte to reach next pixel block in a
> > certain direction
> > - *_to_argb_u16: helpers to perform colors conversion. They should be
> > inlined by the compiler, and they are used to avoid repetition between
> > multiple variants of the same format (argb/xrgb and maybe in the
> > future for formats like bgr formats).
> >
> > This new algorithm was tested with:
> > - kms_plane (for color conversions)
> > - kms_rotation_crc (for rotations of planes)
> > - kms_cursor_crc (for translations of planes)
> > The performance gain was mesured with:
> > - kms_fb_stress
> >
> > [1]: commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to accept
> > new formats")
> >
> > https://lore.kernel.org/all/20220905190811.25024-7-igormtorre...@gmail.com/
> > [2]: commit 322d716a3e8a ("drm/vkms: isolate pixel conversion
> > functionality")
> > https://lore.kernel.org/all/20230418130525.128733-2-mca...@igalia.com/
> >
> > Signed-off-by: Louis Chauvet
> > ---
> > drivers/gpu/drm/vkms/vkms_composer.c | 219 +++---
> > drivers/gpu/drm/vkms/vkms_drv.h | 24 +++-
> > drivers/gpu/drm/vkms/vkms_formats.c | 253
> > ++-
> > drivers/gpu/drm/vkms/vkms_formats.h | 2 +-
> > drivers/gpu/drm/vkms/vkms_plane.c| 8 +-
> > 5 files changed, 349 insertions(+), 157 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 5b341222d239..e555bf9c1aee 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -24,9 +24,10 @@ static u16 pre_mul_blend_channel(u16 src, u16 dst, u16
> > alpha)
> >
> > /**
> > * pre_mul_alpha_blend - alpha blending equation
> > - * @frame_info: Source framebuffer's metadata
> > * @stage_buffer: The line with the pixels from src_plane
> > * @output_buffer: A line buffer that receives all the blends output
> > + * @x_start: The start offset to avoid useless copy
> > + * @count: The number of byte to copy
> > *
> > * Using the information from the `frame_info`, this blends only the
> > * necessary pixels from the `stage_buffer` to the `output_buffer`
> > @@ -37,51 +38,23 @@ static u16 pre_mul_blend_channel(u16 src, u16 dst, u16
> > alpha)
> > * drm_plane_create_blend_mode_property(). Also, this formula assumes a
> > * completely opaque background.
> > */
> > -static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info,
> > - struct line_buffer *stage_buffer,
> > - struct line_buffer *output_buffer)
> > +static void pre_mul_alpha_blend(
> > + struct line_buffer *stage_buffer,
> > + struct line_buffer *output_buffer,
> > + int x_start,
> > + int pixel_count)
> > {
> > - int x_dst = frame_info->dst.x1;
> > - struct pixel_argb_u16 *out = output_buffer->pixels + x_dst;
> > - struct pixel_argb_u16 *in = stage_buffer->pixels;
> > - int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> > - stage_buffer->n_pixels);
> > -
> > - for (int x = 0; x < x_limit; x++) {
> > - out[x].a = (u16)0x;
> > - out[x].r = pre_mul_blend_channel(in[x].r, out[x].r, in[x].a);
> > - out[x].g = pre_mul_blend_channel(in[x].g, out[x].g, in[x].a);
> > - out[x].b = pre_mul_blend_channel(in[x].b, out[x].b, in[x].a);
> > + struct pixel_argb_u16 *out = &output_buffer->pi
Re: [PATCH v2 9/9] drm/vkms: Create KUnit tests for YUV conversions
Le 26/02/24 - 13:39, Arthur Grillo a écrit : > > > On 23/02/24 08:37, Louis Chauvet wrote: > > From: Arthur Grillo > > > > Create KUnit tests to test the conversion between YUV and RGB. Test each > > conversion and range combination with some common colors. > > > > Signed-off-by: Arthur Grillo > > [Louis Chauvet: fix minor formating issues (whitespace, double line)] > > Signed-off-by: Louis Chauvet > > --- > > drivers/gpu/drm/vkms/Makefile | 1 + > > drivers/gpu/drm/vkms/tests/.kunitconfig | 4 + > > drivers/gpu/drm/vkms/tests/Makefile | 3 + > > drivers/gpu/drm/vkms/tests/vkms_format_test.c | 155 > > ++ > > drivers/gpu/drm/vkms/vkms_formats.c | 9 +- > > drivers/gpu/drm/vkms/vkms_formats.h | 5 + > > 6 files changed, 175 insertions(+), 2 deletions(-) > > You need to add the CONFIG_DRM_VKMS_KUNIT_TESTS config to > drivers/gpu/drm/vkms/Kconfig, like my previous patch did. I don't know how I merged your patch, but I missed the Kconfig file, it was not intended, sorry. Kind regards, Louis Chauvet [...] -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 4/9] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions
Le 26/02/24 - 13:36, Pekka Paalanen a écrit :
> On Fri, 23 Feb 2024 12:37:24 +0100
> Louis Chauvet wrote:
>
> > Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
> > compiler to check if the passed functions take the correct arguments.
> > Such typedefs will help ensuring consistency across the code base in
> > case of update of these prototypes.
> >
> > Introduce a check around the get_pixel_*_functions to avoid using a
> > nullptr as a function.
> >
> > Document for those typedefs.
> >
> > Signed-off-by: Louis Chauvet
> > ---
> > drivers/gpu/drm/vkms/vkms_drv.h | 23 +--
> > drivers/gpu/drm/vkms/vkms_formats.c | 8
> > drivers/gpu/drm/vkms/vkms_formats.h | 4 ++--
> > drivers/gpu/drm/vkms/vkms_plane.c | 9 -
> > drivers/gpu/drm/vkms/vkms_writeback.c | 9 -
> > 5 files changed, 43 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index 18086423a3a7..886c885c8cf5 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -53,12 +53,31 @@ struct line_buffer {
> > struct pixel_argb_u16 *pixels;
> > };
> >
> > +/**
> > + * typedef pixel_write_t - These functions are used to read a pixel from a
> > + * `struct pixel_argb_u16*`, convert it in a specific format and write it
> > in the @dst_pixels
> > + * buffer.
> > + *
> > + * @dst_pixel: destination address to write the pixel
> > + * @in_pixel: pixel to write
> > + */
> > +typedef void (*pixel_write_t)(u8 *dst_pixels, struct pixel_argb_u16
> > *in_pixel);
>
> There are some inconsistencies in pixel_write_t and pixel_read_t. At
> this point of the series they still operate on a single pixel, but you
> use dst_pixels and src_pixels, plural. Yet the documentation correctly
> talks about processing a single pixel.
I will fix this for v4.
> I would also expect the source to be always const, but that's a whole
> another patch to change.
The v4 will contains a new patch "drm/vkms: Use const pointer for
pixel_read and pixel_write functions"
[...]
> > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> > b/drivers/gpu/drm/vkms/vkms_plane.c
> > index d5203f531d96..f68b1b03d632 100644
> > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > @@ -106,6 +106,13 @@ static void vkms_plane_atomic_update(struct drm_plane
> > *plane,
> > return;
> >
> > fmt = fb->format->format;
> > + pixel_read_t pixel_read = get_pixel_read_function(fmt);
> > +
> > + if (!pixel_read) {
> > + DRM_WARN("Pixel format is not supported by VKMS planes. State
> > is inchanged\n");
>
> DRM_WARN() is the kernel equivalent to userspace assert(), right?
For the DRM_WARN it is just a standard prinkt(KERN_WARN, ...) (hidden
behind drm internal macros).
> In that failing the check means an internal invariant was violated,
> which means a code bug in kernel?
>
> Maybe this could be more specific about what invariant was violated?
> E.g. atomic check should have rejected this attempt already.
I'm not an expert (yet) in DRM, so please correct me:
When atomic_update is called, the new state is always validated by
atomic_check before? There is no way to pass something not validated by
atomic_check to atomic_update? If this is the case, yes, it should be an
ERROR and not a WARN as an invalid format passed the atomic_check
verification.
If so, is this better?
if (!pixel_read) {
/*
* This is a bug as the vkms_plane_atomic_check must forbid all
unsupported formats.
*/
DRM_ERROR("Pixel format %4cc is not supported by VKMS
planes.\n", fmt);
return;
}
I will put the same code in vkms_writeback.c.
[...]
Kind regards,
Louis Chauvet
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH] drm/vkms: Add information on how to benchmark
Le 27/02/24 - 15:26, Pekka Paalanen a écrit : > On Tue, 27 Feb 2024 09:29:58 -0300 > Arthur Grillo wrote: > > > On 27/02/24 08:55, Pekka Paalanen wrote: > > > On Tue, 27 Feb 2024 08:44:52 -0300 > > > Arthur Grillo wrote: > > > > > >> On 27/02/24 06:19, Pekka Paalanen wrote: > > >>> On Mon, 26 Feb 2024 17:42:11 -0300 > > >>> Arthur Grillo wrote: > > >>> > > Now that we have a defined benchmark for testing the driver, add > > documentation on how to run it. > > > > Signed-off-by: Arthur Grillo > > --- > > Documentation/gpu/vkms.rst | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > index ba04ac7c2167..6d07f79f77ff 100644 > > --- a/Documentation/gpu/vkms.rst > > +++ b/Documentation/gpu/vkms.rst > > @@ -89,6 +89,12 @@ You can also run subtests if you do not want to run > > the entire test:: > > sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device > > "sys:/sys/devices/platform/vkms" > > sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" > > ./build/tests/kms_flip --run-subtest basic-plain-flip > > > > +If you are developing features that may affect performance, you can > > run the kms_fb_stress > > >>> > > >>> s/can/must/ > > >>> > > +benchmark:: > > >>> > > >>> before and after, and report the numbers. > > >> > > >> Did you mean to write the benchmarks logs here? > > > > > > I mean people should be required tell their before and after numbers in > > > either commit message (my preference) or in series cover letter (if > > > benchmarking commits is not useful). > > > > > > With the addition of YUV support in VKMS, maybe the benchmark needs to > > > > With the upcoming addition, I've sent a patch to arbitrarily change the > > formats on the benchmark via command-line options. It's not adding a new > > case, but maybe just this could already help. > > > > https://lore.kernel.org/all/20240226-kms_fb_stress-dev-v1-0-1c14942b1...@riseup.net/ > > In that case you would need to document exactly what command line > options to use, and ask people to report the numbers of each test > case. > > That works. Alternatively or additionally, the test cases could be > built in to the benchmark, and it just reports numbers for all of them > in a single invocation. Then people running the standard benchmark do > not need to worry about getting the command line options right, or > running multiple cases. And reviewers do not need to ask to re-run with > the correct options. > > I suppose rotations might get added, too. > > Or maybe you'd provide a script that covers all the standard > performance test cases? I agree with Pekka, it would be nice to have a simple "bench everything" tool. Like kms_rotation is a test for all rotations, kms_plane for color conversions... kms_fb_test can run a few combinations (rgb+norotation, rgb+yuv, rgb+rotation...) and report a "global result" (this way it's easy to spot a regression not related directly to your changes). I don't know the IGT benchmark API, but I think there is a way to create "sub-benchmarks" so you can run a specific benchmark when developping and the whole thing before pushing your series. Kind regards, Louis Chauvet > > Thanks, > pq > > > > start printing YUV numbers separately as a new case. > > > > > > > > > Thanks, > > > pq > > > > > >> > > >>> > > + > > + sudo ./build/benchmarks/kms_fb_stress --device > > "sys:/sys/devices/platform/vkms" > > + sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" > > ./build/benchmarks/kms_fb_stress > > >>> > > >>> Do people need to run both commands? > > >> > > >> No, they don't, just two options. > > >> > > >> Best Regards, > > >> ~Arthur Grillo > > >> > > >>> > > >>> Anyway, a good idea. > > >>> > > >>> Acked-by: Pekka Paalanen > > >>> > > >>> > > >>> Thanks, > > >>> pq > > >>> > > + > > TODO > > > > > > > > --- > > base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f > > change-id: 20240226-bench-vkms-5b8b7aab255e > > > > Best regards, > > >>> > > > > -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 3/9] drm/vkms: write/update the documentation for pixel conversion and pixel write functions
Le 26/02/24 - 10:07, Arthur Grillo a écrit : > > > On 26/02/24 05:46, Louis Chauvet wrote: > > Add some documentation on pixel conversion functions. > > Update of outdated comments for pixel_write functions. > > > > Signed-off-by: Louis Chauvet > > --- > > drivers/gpu/drm/vkms/vkms_composer.c | 4 +++ > > drivers/gpu/drm/vkms/vkms_drv.h | 13 > > drivers/gpu/drm/vkms/vkms_formats.c | 58 > > ++-- > > 3 files changed, 66 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c > > b/drivers/gpu/drm/vkms/vkms_composer.c > > index c6d9b4a65809..5b341222d239 100644 > > --- a/drivers/gpu/drm/vkms/vkms_composer.c > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c > > @@ -189,6 +189,10 @@ static void blend(struct vkms_writeback_job *wb, > > > > size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay; > > > > + /* > > +* The planes are composed line-by-line. It is a necessary complexity > > to avoid poor > > +* blending performance. > > At this moment in the series, you have not yet reintroduced the > line-by-line algorithm yet. Maybe it's better to add this comment when > you do. Is it better with this: /* * The planes are composed line-by-line to avoid heavy memory usage. It is a necessary * complexity to avoid poor blending performance. * * The function vkms_compose_row is used to read a line, pixel-by-pixel, into the staging * buffer. */ > Also, I think it's good to give more context, like: > "The planes are composed line-by-line, instead of pixel-by-pixel" And after PATCHv3 5/9: /* * The planes are composed line-by-line to avoid heavy memory usage. It is a necessary * complexity to avoid poor blending performance. * * The function pixel_read_line callback is used to read a line, using an efficient * algorithm for a specific format, into the staging buffer. */ Kind regards, Louis Chauvet > Best Regards, > ~Arthur Grillo [...] -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 3/9] drm/vkms: write/update the documentation for pixel conversion and pixel write functions
[...]
> > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
> > b/drivers/gpu/drm/vkms/vkms_formats.c
> > index 172830a3936a..cb7a49b7c8e7 100644
> > --- a/drivers/gpu/drm/vkms/vkms_formats.c
> > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > @@ -9,6 +9,17 @@
> >
> > #include "vkms_formats.h"
> >
> > +/**
> > + * packed_pixels_offset() - Get the offset of the block containing the
> > pixel at coordinates x/y
> > + * in the first plane
> > + *
> > + * @frame_info: Buffer metadata
> > + * @x: The x coordinate of the wanted pixel in the buffer
> > + * @y: The y coordinate of the wanted pixel in the buffer
> > + *
> > + * The caller must be aware that this offset is not always a pointer to a
> > pixel. If individual
> > + * pixel values are needed, they have to be extracted from the resulting
> > block.
>
> Just wondering how the caller will be able to extract the right pixel
> from the block without re-using the knowledge already used in this
> function. I'd also expect the function to round down x,y to be
> divisible by block dimensions, but that's not visible in this email.
> Then the caller needs the remainder from the round-down, too?
You are right, the current implementation is only working when block_h ==
block_w == 1. I think I wrote the documentation for PATCHv2 5/9, but when
backporting this comment for PATCHv2 3/9 I forgot to update it.
The new comment will be:
* pixels_offset() - Get the offset of a given pixel data at coordinate
* x/y in the first plane
[...]
* The caller must ensure that the framebuffer associated with this
* request uses a pixel format where block_h == block_w == 1.
* If this requirement is not fulfilled, the resulting offset can be
* completly wrong.
And yes, even after PATCHv2 5/9 it is not clear what is the offset. Is
this better to replace the last sentence? (I will do the same update for
the last sentence of packed_pixels_addr)
[...]
* The returned offset correspond to the offset of the block containing the
pixel at coordinates
* x/y.
* The caller must use this offset with care, as for formats with block_h != 1
or block_w != 1
* the requested pixel value may have to be extracted from the block, even if
they are
* individually adressable.
> > + */
> > static size_t pixel_offset(const struct vkms_frame_info *frame_info, int
> > x, int y)
> > {
> > struct drm_framebuffer *fb = frame_info->fb;
> > @@ -17,12 +28,13 @@ static size_t pixel_offset(const struct vkms_frame_info
> > *frame_info, int x, int
> > + (x * fb->format->cpp[0]);
> > }
> >
[...]
> > +/**
> > + * Retrieve the correct read_pixel function for a specific format.
> > + * The returned pointer is NULL for unsupported pixel formats. The caller
> > must ensure that the
> > + * pointer is valid before using it in a vkms_plane_state.
> > + *
> > + * @format: 4cc of the format
>
> Since there are many different 4cc style pixel format definition tables
> in existence with conflicting definitions, it would not hurt to be more
> specific that this is about DRM_FORMAT_* or drm_fourcc.h.
Is this better?
@format: DRM_FORMAT_* value for which to obtain a conversion function (see
[drm_fourcc.h])
> > + */
> > void *get_pixel_conversion_function(u32 format)
> > {
> > switch (format) {
> > @@ -247,6 +280,13 @@ void *get_pixel_conversion_function(u32 format)
> > }
> > }
> >
> > +/**
> > + * Retrieve the correct write_pixel function for a specific format.
> > + * The returned pointer is NULL for unsupported pixel formats. The caller
> > must ensure that the
> > + * pointer is valid before using it in a vkms_writeback_job.
> > + *
> > + * @format: 4cc of the format
>
> This too.
Ack, I will use the same as above
> > + */
> > void *get_pixel_write_function(u32 format)
> > {
> > switch (format) {
> >
>
> I couldn't check if the docs are correct since the patch context is not
> wide enough, but they all sound plausible to me.
I checked again, I don't see other errors than your first comment.
>
> Thanks,
> pq
Kind regards,
Louis Chauvet
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 7/9] drm/vkms: Add range and encoding properties to pixel_read function
(same as for PATCHv2 6/9, I took the patch from Arthur with no modifications) Le 26/02/24 - 14:23, Pekka Paalanen a écrit : > On Fri, 23 Feb 2024 12:37:27 +0100 > Louis Chauvet wrote: > > > From: Arthur Grillo > > > > Create range and encoding properties. This should be noop, as none of > > the conversion functions need those properties. > > None of the conversion function needs this? How can one say so? > The previous patch is making use of them already, AFAICT? It's my fault, I mixed the commits (in Arthur's series, "Add range..." was before "Add YUV support"), but for me it makes no sens to have the color property without the support in the driver. Maybe it's better just to merge "Add range..." with "Add YUV support"? > How is this a noop? Is it not exposing new UAPI from VKMS? It's not a no-op from userspace, but from the driver side, yes. Kind regards, Louis Chauvet > Thanks, > pq > > > > > Signed-off-by: Arthur Grillo > > [Louis Chauvet: retained only relevant parts] > > Signed-off-by: Louis Chauvet > > --- > > drivers/gpu/drm/vkms/vkms_plane.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c > > b/drivers/gpu/drm/vkms/vkms_plane.c > > index 427ca67c60ce..95dfde297377 100644 > > --- a/drivers/gpu/drm/vkms/vkms_plane.c > > +++ b/drivers/gpu/drm/vkms/vkms_plane.c > > @@ -228,5 +228,14 @@ struct vkms_plane *vkms_plane_init(struct vkms_device > > *vkmsdev, > > drm_plane_create_rotation_property(&plane->base, DRM_MODE_ROTATE_0, > >DRM_MODE_ROTATE_MASK | > > DRM_MODE_REFLECT_MASK); > > > > + drm_plane_create_color_properties(&plane->base, > > + BIT(DRM_COLOR_YCBCR_BT601) | > > + BIT(DRM_COLOR_YCBCR_BT709) | > > + BIT(DRM_COLOR_YCBCR_BT2020), > > + BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | > > + BIT(DRM_COLOR_YCBCR_FULL_RANGE), > > + DRM_COLOR_YCBCR_BT601, > > + DRM_COLOR_YCBCR_FULL_RANGE); > > + > > return plane; > > } > > > -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 5/9] drm/vkms: Re-introduce line-per-line composition algorithm
[...]
> > -static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info,
> > - struct line_buffer *stage_buffer,
> > - struct line_buffer *output_buffer)
> > +static void pre_mul_alpha_blend(
> > + struct line_buffer *stage_buffer,
> > + struct line_buffer *output_buffer,
> > + int x_start,
> > + int pixel_count)
> > {
> > - int x_dst = frame_info->dst.x1;
> > - struct pixel_argb_u16 *out = output_buffer->pixels + x_dst;
> > - struct pixel_argb_u16 *in = stage_buffer->pixels;
> > - int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> > - stage_buffer->n_pixels);
> > -
> > - for (int x = 0; x < x_limit; x++) {
> > - out[x].a = (u16)0x;
> > - out[x].r = pre_mul_blend_channel(in[x].r, out[x].r, in[x].a);
> > - out[x].g = pre_mul_blend_channel(in[x].g, out[x].g, in[x].a);
> > - out[x].b = pre_mul_blend_channel(in[x].b, out[x].b, in[x].a);
> > + struct pixel_argb_u16 *out = &output_buffer->pixels[x_start];
> > + struct pixel_argb_u16 *in = &stage_buffer->pixels[x_start];
>
> Input buffers and pointers should be const.
They will be const in v4.
> > +
> > + for (int i = 0; i < pixel_count; i++) {
> > + out[i].a = (u16)0x;
> > + out[i].r = pre_mul_blend_channel(in[i].r, out[i].r, in[i].a);
> > + out[i].g = pre_mul_blend_channel(in[i].g, out[i].g, in[i].a);
> > + out[i].b = pre_mul_blend_channel(in[i].b, out[i].b, in[i].a);
> > }
> > }
>
> Somehow the hunk above does not feel like it is part of "re-introduce
> line-per-line composition algorithm". This function was already running
> line-by-line. Would it be easy enough to collect this and directly
> related changes into a separate patch?
It is not directly related to the reintroduction of line-by-line
algorithm, but in the simplification and maintenability effort, I
changed a bit the function to avoid having multiple place computing the
x_start/pixel_count values. I don't see an interrest to extract it, it
will be just a translation of the few lines into the calling place.
[...]
> > +/**
> > + * direction_for_rotation() - Helper to get the correct reading direction
> > for a specific rotation
> > + *
> > + * @rotation: rotation to analyze
>
> This is KMS plane rotation property, right?
>
> So the KMS plane has been rotated by this, and what we want to find is
> the read direction on the attached FB so that reading returns pixels in
> the CRTC line/scanout order, right?
>
> Maybe extend the doc to explain that.
Is it better?
* direction_for_rotation() - Get the correct reading direction for a given
rotation
*
* This function will use the @rotation parameter to compute the correct
reading direction to read
* a line from the source buffer.
* For example, if the buffer is reflected on X axis, the pixel must be read
from right to left.
* @rotation: Rotation to analyze. It correspond the the field
@frame_info.rotation.
> > + */
> > +enum pixel_read_direction direction_for_rotation(unsigned int rotation)
> > +{
> > + if (rotation & DRM_MODE_ROTATE_0) {
> > + if (rotation & DRM_MODE_REFLECT_X)
> > + return READ_LEFT;
> > + else
> > + return READ_RIGHT;
> > + } else if (rotation & DRM_MODE_ROTATE_90) {
> > + if (rotation & DRM_MODE_REFLECT_Y)
> > + return READ_UP;
> > + else
> > + return READ_DOWN;
> > + } else if (rotation & DRM_MODE_ROTATE_180) {
> > + if (rotation & DRM_MODE_REFLECT_X)
> > + return READ_RIGHT;
> > + else
> > + return READ_LEFT;
> > + } else if (rotation & DRM_MODE_ROTATE_270) {
> > + if (rotation & DRM_MODE_REFLECT_Y)
> > + return READ_DOWN;
> > + else
> > + return READ_UP;
> > + }
> > + return READ_RIGHT;
> > +}
> > +
> > /**
> > * blend - blend the pixels from all planes and compute crc
> > * @wb: The writeback frame buffer metadata
> > @@ -183,11 +187,11 @@ static void blend(struct vkms_writeback_job *wb,
> > {
> > struct vkms_plane_state **plane = crtc_state->active_planes;
> > u32 n_active_planes = crtc_state->num_active_planes;
> > - int y_pos;
> >
> > const struct pixel_argb_u16 background_color = { .a = 0x };
> >
> > size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
> > + size_t crtc_x_limit = crtc_state->base.crtc->mode.hdisplay;
>
> Wonder why these were size_t, causing needs to cast below...
For crtc_x_limit I just copied the crtc_y_limit. I will change both to u16
(the type of h/vdisplay).
> >
> > /*
> > * The planes are composed line-by-line. It is a necessary complexity
> > to avoid poor
> > @@ -198,22 +202,133 @@ static void blend(struct vkms_writeback_job *wb,
> >
> > /* The active planes are compos
Re: [PATCH RFC 01/12] kbuild: create destination directory for _shipped handling
On Mon, Feb 26, 2024 at 8:01 PM Dmitry Baryshkov wrote: > > On Mon, 26 Feb 2024 at 08:33, Masahiro Yamada wrote: > > > > On Mon, Feb 26, 2024 at 11:11 AM Dmitry Baryshkov > > wrote: > > > > > > The driver might decide to put the _shipped files to the subdir. > > > > > > > > Please stop this sentence. > > > > This sounds like we are not learning. > > > > https://lore.kernel.org/all/CAHk-=wgSEi_ZrHdqr=20xv+d6dr5G895CbOAi8ok+7-CQUN=f...@mail.gmail.com/ > > > > > > > > > > > In such > > > case the cmd_copy might fail because the destination directory is not > > > present. Call mkdir -p to make sure that the destination directory is > > > present. > > > > > > There is no justification for this. > > > > If you need a single generated directory > > (drivers/gpu/drm/msm/registers/, divers/gpu/drm/msm/generated/ or whatever) > > that should be super simple. > > > > Why does scripts/Makefile.lib need the modification? > > Could you please tell me how I should handle this? > I was looking for a way to generate > drivers/gpu/drm/msm/registers/foo.xml.h and then use it during > compilation. > In drivers/gpu/drm/msm/Makefile I added $(obj)/registers/foo.xml.h as > a dependency to the corresponding object files and then added > drivers/gpu/drm/msm/registers/foo.xml.h_shipped file. > This way Kbuild/make will attempt to call cmd_copy to generate target > file, which thanks to VPATH expansion boils down to `cat > $(srctree)/$(src)/registers/foo.xml.h_shopped > > $(obj)/registers/foo.xml.h`. However this breaks as there is no > $(obj)/registers. > One simple solution is to use $(shell mkdir -p ...) to create the output directory. scripts/Makefile.build does a similar thing. You can add the following to drivers/gpu/drm/msm/Makefile. # Create output directory when CONFIG_DRM_MSM is defined. # This avoids creating the output directory during 'make clean' ifdef CONFIG_DRM_MSM $(shell mkdir -p $(obj)/registers) endif -- Best Regards Masahiro Yamada
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > wrote: > > > > On 21/02/2024 17:02, Paweł Anikiel wrote: > > > The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > capture and Multi-Stream Transport. The user guide can be found here: > > > > > > https://www.intel.com/programmable/technical-pdfs/683273.pdf > > > > > > Signed-off-by: Paweł Anikiel > > > --- > > > .../devicetree/bindings/media/intel,dprx.yaml | 160 ++ > > > 1 file changed, 160 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > new file mode 100644 > > > index ..31025f2d5dcd > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > @@ -0,0 +1,160 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Intel DisplayPort RX IP > > > + > > > +maintainers: > > > + - Paweł Anikiel > > > + > > > +description: | > > > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > + capture and Multi-Stream Transport. > > > + > > > + The IP features a large number of configuration parameters, found at: > > > + > > > https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > > + > > > + The following parameters have to be enabled: > > > +- Support DisplayPort sink > > > +- Enable GPU control > > > + The following parameters' values have to be set in the devicetree: > > > +- RX maximum link rate > > > +- Maximum lane count > > > +- Support MST > > > +- Max stream count (only if Support MST is enabled) > > > + > > > +properties: > > > + compatible: > > > +const: intel,dprx-20.0.1 > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + interrupts: > > > +maxItems: 1 > > > + > > > + intel,max-link-rate: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: Max link rate configuration parameter > > > > Please do not duplicate property name in description. It's useless. > > Instead explain what is this responsible for. > > > > Why max-link-rate would differ for the same dprx-20.0.1? And why > > standard properties cannot be used? > > > > Same for all questions below. > > These four properties are the IP configuration parameters mentioned in > the device description. When generating the IP core you can set these > parameters, which could make them differ for the same dprx-20.0.1. > They are documented in the user guide, for which I also put a link in > the description. Is that enough? Or should I also document these > parameters here? Use the standard properties: link-frequencies and data-lanes. Those go under the port(s) because they are inheritly per logical link. Rob
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Tue, Feb 27, 2024 at 02:11:27PM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 6:29 PM Krzysztof Kozlowski > wrote: > > > > On 26/02/2024 13:43, Paweł Anikiel wrote: > > > + intel,max-stream-count: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: Max stream count configuration parameter > > > + > > > + port: > > > +$ref: /schemas/graph.yaml#/properties/port > > > +description: SST main link > > > > I don't understand why you have both port and ports. Shouldn't this be > > under ports? > > >>> > > >>> I put both so that you can use the shorter port property when the > > >>> device only has one port (i.e. no MST support). It would work fine > > >>> without it. If you think that's unnecessary, I can remove it (and use > > >>> the ports property even if there is only one). > > >> > > >> No, it is fine, but then you need allOf: which will restrict to only one > > >> of them: either port or ports. > > > > > > There already is an allOf below that says that ports is required for > > > MST support and port is required otherwise. Isn't this enough? > > > > Add both port and ports and see if it is enough. > > Ok, I see. I tried and this seems to work: > > oneOf: > - required: > - port > - required: > - ports > > And that would make the if/else with port and ports below not needed. > What do you think? Just always use 'ports' rather than complicate things. Rob
[PATCH 6.1 085/195] drm/ttm: Fix an invalid freeing on already freed page in error path
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -383,7 +383,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = &tt->pages[start_page];
unsigned int order;
pgoff_t i, nr;
Re: [RFC PATCH v4 06/42] drm/vkms: Add kunit tests for VKMS LUT handling
On 2024-02-27 07:14, Arthur Grillo wrote:
>
>
> On 26/02/24 18:10, Harry Wentland wrote:
>> Debugging LUT math is much easier when we can unit test
>> it. Add kunit functionality to VKMS and add tests for
>> - get_lut_index
>> - lerp_u16
>>
>> v4:
>> - Test the critical points of the lerp function (Pekka)
>>
>> v3:
>> - Use include way of testing static functions (Arthur)
>>
>> Signed-off-by: Harry Wentland
>> Cc: Arthur Grillo
>> ---
>> drivers/gpu/drm/vkms/Kconfig | 5 +
>> drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
>> drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 163 ++
>> drivers/gpu/drm/vkms/vkms_composer.c | 8 +-
>> 4 files changed, 178 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
>> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>>
>> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
>> index b9ecdebecb0b..c1f8b343ff0e 100644
>> --- a/drivers/gpu/drm/vkms/Kconfig
>> +++ b/drivers/gpu/drm/vkms/Kconfig
>> @@ -13,3 +13,8 @@ config DRM_VKMS
>>a VKMS.
>>
>>If M is selected the module will be called vkms.
>> +
>> +config DRM_VKMS_KUNIT_TESTS
>> +tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
>> +depends on DRM_VKMS && KUNIT
>> +default KUNIT_ALL_TESTS
>> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig
>> b/drivers/gpu/drm/vkms/tests/.kunitconfig
>> new file mode 100644
>> index ..70e378228cbd
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
>> @@ -0,0 +1,4 @@
>> +CONFIG_KUNIT=y
>> +CONFIG_DRM=y
>> +CONFIG_DRM_VKMS=y
>> +CONFIG_DRM_VKMS_KUNIT_TESTS=y
>> diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> new file mode 100644
>> index ..fc73e48aa57c
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> @@ -0,0 +1,163 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +
>> +#include
>> +
>> +#include
>> +
>> +#define TEST_LUT_SIZE 16
>> +
>> +static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
>> +{ 0x0, 0x0, 0x0, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +};
>> +
>> +const struct vkms_color_lut test_linear_lut = {
>> +.base = test_linear_array,
>> +.lut_length = TEST_LUT_SIZE,
>> +.channel_value2index_ratio = 0xf000fll
>> +};
>> +
>> +
>> +static void vkms_color_test_get_lut_index(struct kunit *test)
>> +{
>> +int i;
>> +
>> +KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(&test_linear_lut,
>> test_linear_array[0].red)), 0);
>> +
>> +for (i = 0; i < TEST_LUT_SIZE; i++)
>> +KUNIT_EXPECT_EQ(test,
>> drm_fixp2int_ceil(get_lut_index(&test_linear_lut,
>> test_linear_array[i].red)), i);
>> +}
>> +
>> +static void vkms_color_test_lerp(struct kunit *test)
>> +{
>> +/*** half-way round down ***/
>> +s64 t = 0x8000 - 1;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
>> +
>> +/* odd a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x8);
>> +
>> +/* odd b */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
>> +
>> +/* b = a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
>> +
>> +/* b = a + 1 */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x10);
>> +
>> +
>> +/*** half-way round up ***/
>> +t = 0x8000;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
>> +
>> +/* odd a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x9);
>> +
>> +/* odd b */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
>> +
>> +/* b = a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
>> +
>> +/* b = a + 1 */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x11);
>> +
>> +/*** t = 0.0 ***/
>> +t = 0x0;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x0);
>> +
>> +/* odd a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x1);
>> +
>> +/* odd b */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x1);
>> +
>> +/* b = a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
>> +
>> +/* b = a + 1 */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x10);
>> +
>> +/*** t = 1.0 ***/
>> +t = 0x1;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x10);
>> +
>> +/* odd a */
>> +KUNIT_EXPEC
[PATCH 5.15 078/245] drm/ttm: Fix an invalid freeing on already freed page in error path
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -384,7 +384,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = &tt->pages[start_page];
unsigned int order;
pgoff_t i, nr;
Re: [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM's console emulation. Similar changes
for vmap and mmap have been posted at [1][2]
Most DRM drivers and memory managers acquire the buffer object's
reservation lock within their GEM pin and unpin callbacks. This
violates dma-buf locking semantics. We get away with it because PRIME
does not provide pin/unpin, but attach/detach, for which the locking
semantics is correct.
Patches 1 to 8 rework DRM GEM code in various implementations to
acquire the reservation lock when entering the pin and unpin callbacks.
This prepares them for the next patch. Drivers that are not affected
by these patches either don't acquire the reservation lock (amdgpu)
or don't need preparation (loongson).
Patch 9 moves reservation locking from the GEM pin/unpin callbacks
into drm_gem_pin() and drm_gem_unpin(). As PRIME uses these functions
internally it still gets the reservation lock.
With the updated GEM callbacks, the rest of the patchset fixes the
fbdev emulation's buffer locking. Fbdev emulation needs to keep its
GEM buffer object inplace while updating its content. This required
a implicit pinning and apparently amdgpu didn't do this at all.
Patch 10 introduces drm_client_buffer_vmap_local() and _vunmap_local().
The former function map a GEM buffer into the kernel's address space
with regular vmap operations, but keeps holding the reservation lock.
The _vunmap_local() helper undoes the vmap and releases the lock. The
updated GEM callbacks make this possible. Between the two calls, the
fbdev emulation can update the buffer content without have the buffer
moved or evicted. Update fbdev-generic to use vmap_local helpers,
which fix amdgpu. The idea of adding a "local vmap" has previously been
attempted at [3] in a different form.
Patch 11 adds implicit pinning to the DRM client's regular vmap
helper so that long-term vmap'ed buffers won't be evicted. This only
affects fbdev-dma, but GEM DMA helpers don't require pinning. So
there are no practical changes.
Patches 12 and 13 remove implicit pinning from the vmap and vunmap
operations in gem-vram and qxl. These pin operations are not supposed
to be part of vmap code, but were required to keep the buffers in place
for fbdev emulation. With the conversion o ffbdev-generic to to
vmap_local helpers, that code can finally be removed.
Tested with amdgpu, nouveau, radeon, simpledrm and vc4.
[1] https://patchwork.freedesktop.org/series/106371/
[2] https://patchwork.freedesktop.org/series/116001/
[3] https://patchwork.freedesktop.org/series/84732/
Thomas Zimmermann (13):
drm/gem-shmem: Acquire reservation lock in GEM pin/unpin callbacks
drm/gem-vram: Acquire reservation lock in GEM pin/unpin callbacks
drm/msm: Provide msm_gem_get_pages_locked()
drm/msm: Acquire reservation lock in GEM pin/unpin callback
drm/nouveau: Provide nouveau_bo_{pin,unpin}_locked()
drm/nouveau: Acquire reservation lock in GEM pin/unpin callbacks
drm/qxl: Provide qxl_bo_{pin,unpin}_locked()
drm/qxl: Acquire reservation lock in GEM pin/unpin callbacks
drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()
drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
drm/client: Pin vmap'ed GEM buffers
drm/gem-vram: Do not pin buffer objects for vmap
drm/qxl: Do not pin buffer objects for vmap
drivers/gpu/drm/drm_client.c| 92 ++---
drivers/gpu/drm/drm_fbdev_generic.c | 4 +-
drivers/gpu/drm/drm_gem.c | 34 +++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 101 ++--
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/loongson/lsdc_gem.c | 13 +--
drivers/gpu/drm/msm/msm_gem.c | 20 ++---
drivers/gpu/drm/msm/msm_gem.h | 4 +-
drivers/gpu/drm/msm/msm_gem_prime.c | 20 +++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 43 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +-
drivers/gpu/drm/qxl/qxl_object.c| 26 +++---
drivers/gpu/drm/qxl/qxl_object.h| 2 +
drivers/gpu/drm/qxl/qxl_prime.c | 4 +-
drivers/gpu/drm/radeon/radeon_prime.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 25 ++
include/drm/drm_client.h| 10 +++
include/drm/drm_gem.h | 3 +
include/drm/drm_gem_shmem_helper.h | 7 +-
21 files changed, 265 insertions(+), 172 deletions(-)
base-commit: 7291e2e67dff0ff573900266382c9c9248a7dea5
prerequisite-patch-id: bdfa0e6341b30cc9d7647172760
Re: [PATCH v7 19/36] drm/connector: hdmi: Compute bpc and format automatically
Hi Alex,
On Sun, Feb 25, 2024 at 02:56:02PM +0100, Alex Bee wrote:
> Am 22.02.24 um 19:14 schrieb Maxime Ripard:
> > Now that we have all the infrastructure needed, we can add some code
> > that will, for a given connector state and mode, compute the best output
> > format and bpc.
> >
> > The algorithm is equivalent to the one already found in i915 and vc4.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 184
> > -
> > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 25 ++-
> > 2 files changed, 197 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 448b4a73d1c8..9f517599f117 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -662,6 +663,96 @@ connector_state_get_mode(const struct
> > drm_connector_state *conn_state)
> > return &crtc_state->mode;
> > }
> > +static bool
> > +sink_supports_format_bpc(const struct drm_connector *connector,
> > +const struct drm_display_info *info,
> > +const struct drm_display_mode *mode,
> > +unsigned int format, unsigned int bpc)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + u8 vic = drm_match_cea_mode(mode);
> > +
> > + if (vic == 1 && bpc != 8) {
> > + drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
> > + return false;
> > + }
> > +
> > + if (!info->is_hdmi &&
> > + (format != HDMI_COLORSPACE_RGB || bpc != 8)) {
> > + drm_dbg(dev, "DVI Monitors require an RGB output at 8 bpc\n");
> > + return false;
> > + }
> > +
> > + if (!(connector->hdmi.supported_formats & BIT(format))) {
> > + drm_dbg(dev, "%s format unsupported by the connector.\n",
> > + drm_hdmi_connector_get_output_format_name(format));
> > + return false;
> > + }
> > +
> > + switch (format) {
> > + case HDMI_COLORSPACE_RGB:
> > + drm_dbg(dev, "RGB Format, checking the constraints.\n");
> > +
> > + if (!(info->color_formats & DRM_COLOR_FORMAT_RGB444))
> > + return false;
> > +
> > + if (bpc == 10 && !(info->edid_hdmi_rgb444_dc_modes &
> > DRM_EDID_HDMI_DC_30)) {
> > + drm_dbg(dev, "10 BPC but sink doesn't support Deep
> > Color 30.\n");
> > + return false;
> > + }
> > +
> > + if (bpc == 12 && !(info->edid_hdmi_rgb444_dc_modes &
> > DRM_EDID_HDMI_DC_36)) {
> > + drm_dbg(dev, "12 BPC but sink doesn't support Deep
> > Color 36.\n");
> > + return false;
> > + }
> > +
> > + drm_dbg(dev, "RGB format supported in that configuration.\n");
> > +
> > + return true;
> > +
> > + case HDMI_COLORSPACE_YUV422:
> > + drm_dbg(dev, "YUV422 format, checking the constraints.\n");
> > +
> > + if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
> > + drm_dbg(dev, "Sink doesn't support YUV422.\n");
> > + return false;
> > + }
> > +
> > + if (bpc != 12) {
> > + drm_dbg(dev, "YUV422 only supports 12 bpc.\n");
> > + return false;
> > + }
> > +
> I'm not sure this check is really necessary/helpful.
> In [0] you are quoting HDMI specs which are saying that YUV422 is just
> always 12 bpc - which I guess is correct. The problem I'm seeing here:
> There are HDMI 1.4 controllers, like Rockchip Inno HDMI, that support
> YUV422 but do not support any other color depth than 8 bpc for RGB or
> YUV444. In drmm_connector_hdmi_init you are expecting to give the max bpc
> as parameter and (if I'm getting it correctly) I'd had to set it to 12 to
> also get YUV422 modes, but I'd also get RGB/YUV444 with bpc > 8 modes which
> are not supported by this controller. I guess the same applies to other
> HDMI 1.4 controllers that support YUV422. Or would I have to filter it out
> myself?
> So I guess the easiest way around is to drop the above check since it is
> just always 12 bpc for YUV422 and there is no need to filter out anything.
> (Same applies to the similar check in [0]).
So, let's tackle drm_connector_hdmi_compute_mode_clock() first, and then
I'll try to answer most of your question there.
If drm_connector_hdmi_compute_mode_clock() is called with the YCbCr422
format and a bpc != 12, what should we return if not an error?
It's the only bpc count allowed by the spec and for which we have a
formula for. I just can't return the character rate of YCbCr422 with 8
bpc, I have no idea what it should be.
And now pivoting to the block of code you commented on, there's two
things to c
Re: [RFC PATCH v4 00/42] Color Pipeline API w/ VKMS
On 2024-02-27 05:26, Joshua Ashton wrote: > > > On 2/26/24 21:10, Harry Wentland wrote: >> This is an RFC set for a color pipeline API, along with a sample >> implementation in VKMS. All the key API bits are here. VKMS now >> supports two named transfer function colorops and two matrix >> colorops. We have IGT tests that check all four of these colorops >> with a pixel-by-pixel comparison that checks that these colorops >> do what we expect them to do with a +/- 1 8 bpc code point margin. >> >> The big new change with v4 is the addition of an amdgpu color >> pipeline, for all AMD GPUs with DCN 3 and newer. Amdgpu now support >> the following: >> >> 1. 1D Curve EOTF >> 2. 3x4 CTM >> 3. Multiplier >> 4. 1D Curve Inverse EOTF >> 5. 1D LUT >> 6. 1D Curve EOTF >> 7. 1D LUT >> >> The supported curves for the 1D Curve type are: >> - sRGB EOTF and its inverse >> - PQ EOTF, scaled to [0.0, 125.0] and its inverse >> - BT.2020/BT.709 OETF and its inverse >> >> Note that the 1st and 5th colorops take the EOTF or Inverse >> OETF while the 3rd colorop takes the Inverse EOTF or OETF. >> >> We are working on two more ops for amdgpu, the HDR multiplier >> and the 3DLUT, which will give us this: >> >> 1. 1D Curve EOTF >> 2. 3x4 CTM >> 3. HDR Multiplier >> 4. 1D Curve Inverse EOTF >> 5. 1D LUT >> 6. 3D LUT >> 7. 1D Curve EOTF >> 8. 1D LUT >> >> This, essentially mirrors the color pipeline used by gamescope >> and presented by Melissa Wen, with the exception of the DEGAM >> LUT, which is not currently used. See >> [1] >> https://indico.freedesktop.org/event/4/contributions/186/attachments/138/218/xdc2023-TheRainbowTreasureMap-MelissaWen.pdf >> >> After this we'd like to also add the following ops: >> - Scaler (Informational only) > > Why informational only? Having NEAREST and in general custom taps should be > possible on AMDGPU right? > > We don't have to solve this now, but I just want to make sure that we aren't > locking this to info only. > No, this isn't locking it to information only. We could allow for NEAREST or even custom taps in the future. Just don't want to open that debate now if we don't have a good reason to. Harry > Thanks > > - Joshie 🐸✨ > >> - Color Encoding, to replace drm_plane's COLOR_ENCODING >> - Color Range, to replace drm_plane's COLOR_RANGE >> >> This patchset is grouped as follows: >> - Patches 1-3: couple general patches/fixes >> - Patches 4-7: introduce kunit to VKMS >> - Patch 7: description of motivation and details behind the >> Color Pipeline API. If you're reading nothing else >> but are interested in the topic I highly recommend >> you take a look at this. >> - Patches 7-27: DRM core and VKMS changes for color pipeline API >> - Patches 28-40: DRM core and amdgpu changes for color pipeline API >> >> VKMS patches could still be improved in a few ways, though the >> payoff might be limited and I would rather focus on other work >> at the moment. The most obvious thing to improve would be to >> eliminate the hard-coded LUTs for identity, and sRGB, and replace >> them with fixed-point math instead. >> >> There are plenty of things that I would like to see here but >> haven't had a chance to look at. These will (hopefully) be >> addressed in future iterations, either in VKMS or amdgpu: >> - Clear documentation for each drm_colorop_type >> - Add custom LUT colorops to VKMS >> - Add pre-blending 3DLUT >> - How to support HW which can't bypass entire pipeline? >> - Add ability to create colorops that don't have BYPASS >> - Can we do a LOAD / COMMIT model for LUTs (and other properties)? >> - read-only scaling colorop which defines scaling taps and position >> - read-only color format colorop to define supported color formats >> for a pipeline >> - named matrices, for things like converting YUV to RGB >> >> IGT tests can be found at >> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 >> >> IGT patches are also being sent to the igt-dev mailing list. >> >> If you prefer a gitlab MR for review you can find it at >> https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 >> >> v4: >> - Add amdgpu color pipeline (WIP) >> - Don't block setting of deprecated properties, instead pass client cap >> to atomic check so drivers can ignore these props >> - Drop IOCTL definitions (Pekka) >> - Use enum property for colorop TYPE (Pekka) >> - A few cleanups to the docs (Pekka) >> - Rework the TYPE enum to name relation to avoid code duplication (Pekka) >> - Add missing function declarations (Chaitanya Kumar Borah) >> - Allow setting of NEXT property to NULL in _set_ function (Chaitanya >> Kumar Borah) >> - Add helper for creation of pipeline drm_plane property (Pekka) >> - Always create Bypass pipeline (Pekka) >> - A bunch of changes to VKMS kunit tests (Pekka) >> - Fix index in CTM doc (Pekka) >> >> v3: >> - Abandon IOCTLs and discover colorops as clients iterate
[PATCH 6.6 140/299] drm/ttm: Fix an invalid freeing on already freed page in error path
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -384,7 +384,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = &tt->pages[start_page];
unsigned int order;
pgoff_t i, nr;
Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch
Hi, On 2/27/24 02:06, Daniel van Vugt wrote: > On 27/2/24 02:23, Hans de Goede wrote: >> Hi All, >> >> On 2/2/24 09:53, Daniel van Vugt wrote: >>> Until now, deferred console takeover only meant defer until there is >>> output. But that risks stepping on the toes of userspace splash screens, >>> as console messages may appear before the splash screen. So check for the >>> "splash" parameter (as used by Plymouth) and if present then extend the >>> deferral until the first switch. >> >> Daniel, thank you for your patch but I do not believe that this >> is the right solution. Deferring fbcon takeover further then >> after the first text is output means that any errors about e.g. >> a corrupt initrd or the kernel erroring out / crashing will not >> be visible. > > That's not really correct. If a boot failure has occurred after the splash > then > pressing escape shows the log. Hmm, I guess this is with the latest plymouth which has a builtin terminal emulator for kernels without VT support ? Pressing ESC does not to a VC switch and AFAICT that is what you are triggering on to allow fbcon takeover after this patches. > If a boot failure has occurred before the splash > then it can be debugged visually by rebooting without the "splash" parameter. Which requires the user to know this and requires the user to know how to edit kernel cmdline parameters in e.g. grub. This is not a good user experience. We want inexperienced users to just be able to point a phone camera at the screen and take a picture of the errors. >> When the kernel e.g. oopses or panics because of not finding >> its rootfs (I tested the latter option when writing the original >> deferred fbcon takeover code) then fbcon must takeover and >> print the messages from the dying kernel so that the user has >> some notion of what is going wrong. > > Indeed, just reboot without the "splash" parameter to do that. Again not something beginning Linux users will be able to do, what happened to "Ubuntu: Linux for Human Beings" ? >> And since your patch seems to delay switching till the first >> vc-switch this means that e.g. even after say gdm refusing >> to start because of issues there still will be no text >> output. This makes debugging various issues much harder. > > I've debugged many gdm failures and it is never useful to use the console for > those. Reboot and get the system journal instead. But users will not see any errors now, meaning they don't even know where to begin with troubleshooting ... >> Moreover Fedora has been doing flickerfree boot for many >> years without needing this. > > I believe Fedora has a mostly working solution, but not totally reliable, as > mentioned in the commit message: > > "even systems whose splash exists in initrd may not be not immune because they > still rely on racing against all possible kernel messages that might > trigger the fbcon takeover" Only very serious kernel errors like oopses or panics will trigger the takeover and that is *exactly* what we want. There is a race where plymouth may hide such vary serious messages, if plymouth does manage to start before the errors, but that is actually an existing issue which we don't want to make bigger by *always* hiding such errors. >> The kernel itself will be quiet as long as you set >> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this >> to 4 which means any kernel pr_err() or dev_err() >> messages will get through and since there are quite >> a few false positives of those Ubuntu really needs >> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of: >> https://bugs.launchpad.net/bugs/1970069 > > Incorrect. In my testing some laptops needed log level as low as 2 to go > quiet. > And the Ubuntu kernel team is never going to fix all those for non-sponsored > devices. Notice that atm Ubuntu's kernel is using the too high CONFIG_CONSOLE_LOGLEVEL_QUIET=4 with CONFIG_CONSOLE_LOGLEVEL_QUIET=3 getting any errors logged to the console should be very very rare. The only thing I can think of is if the kernel oopses / WARN()s early on but the cause is innocent enough that the boot happily continues. In that case actually showing the oops/WARN() is a good thing. For all the years Fedora has had flickerfree boot I have seen zero bug reports about this. If you have examples of this actually being a problem please file bugs for them (launchpad or bugzilla.kernel.org is fine) and then lets take a look at those bugs and fix them. These should be so rare that I'm not worried about this becoming a never ending list of bugs (unlike pr_err() / dev_err() messages of which there are simply too many). >> After that it is "just" a matter of not making userspace >> output anything unless it has errors to report. >> >> systemd already is quiet by default (only logging >> errors) when quiet is on the kernel commandline. > > Unfortunately not true for Ubuntu. We carry a noisy systemd patch which I'm > told we can't remove in the short term: > > https://bugs.
[PATCH 6.7 148/334] drm/ttm: Fix an invalid freeing on already freed page in error path
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = &tt->pages[start_page];
unsigned int order;
pgoff_t i, nr;
drm/msm: DisplayPort hard-reset on hotplug regression in 6.8-rc1
Hi,
Since 6.8-rc1 I have seen (and received reports) of hard resets of the
Lenovo ThinkPad X13s after connecting and disconnecting an external
display.
I have triggered this on a simple disconnect while in a VT console, but
also when stopping Xorg after having repeatedly connected and
disconnected an external display and tried to enable it using xrandr.
In the former case, the last (custom debug) messages printed over an SSH
session were once:
[ 948.416358] usb 5-1: USB disconnect, device number 3
[ 948.443496] msm_dpu ae01000.display-controller: msm_fbdev_client_hotplug
[ 948.443723] msm-dp-display ae98000.displayport-controller:
dp_power_clk_enable - type = 1, enable = 0
[ 948.443872] msm-dp-display ae98000.displayport-controller:
dp_ctrl_phy_exit
[ 948.445117] msm-dp-display ae98000.displayport-controller:
dp_ctrl_phy_exit - done
and then the hypervisor resets the machine.
Hotplug in Xorg seems to work worse than it did with 6.7, which also had
some issues. Connecting a display once seems to work fine, but trying to
re-enable a reconnected display using xrandr sometimes does not work at
all, while with 6.7 it usually worked on the second xrandr execution.
xrandr reports the reconnected display as disconnected:
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 5120 x 4096
eDP-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y
axis) 286mm x 178mm
1920x1200 60.03*+
1600x1200 60.00
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected 1920x1200+0+0 (normal left inverted right x axis y axis)
0mm x 0mm
1920x1200 (0x40c) 154.000MHz +HSync -VSync
h: width 1920 start 1968 end 2000 total 2080 skew0 clock
74.04KHz
v: height 1200 start 1203 end 1209 total 1235 clock
59.95Hz
Running 'xrandr --output DP-2 --auto' 2-3 times makes xrandr report the
display as connected, but the display is still blank (unlike with 6.7).
A few times after having exercised hotplug this way, the machine hard
resets when Xorg is later stopped. Once I saw the following log messages
on an SSH session but they may not have been printed directly before
the hard reset:
[ 214.555781] [drm:dpu_encoder_phys_vid_wait_for_commit_done:492] [dpu
error]vblank timeout
[ 214.555843] [drm:dpu_kms_wait_for_commit_done:483] [dpu error]wait for
commit done returned -110
Note that this appears to be unrelated to the recently fixed Qualcomm
power domain driver bug which can trigger similar resets when
initialising the display subsystem on boot. Specifically, I have
triggered the hotplug resets described above also with the fix applied.
[1]
Reverting commit e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify()
to report HPD status changes") which fixes the related VT console
regression does not seem to make any difference. [2]
Daniel Thompson reports that reverting the whole runtime PM series
appears to make the hard resets he has seen with DisplayPort hotplug go
away however:
https://lore.kernel.org/lkml/1701472789-25951-1-git-send-email-quic_khs...@quicinc.com/
So for now, let's assume that these regressions were also introduced (or
triggered) by commit 5814b8bf086a ("drm/msm/dp: incorporate pm_runtime
framework into DP driver").
Johan
[1]
https://lore.kernel.org/lkml/20240226-rpmhpd-enable-corner-fix-v1-1-68c004cec...@quicinc.com/
[2] https://lore.kernel.org/lkml/zd3ypgmrprxv-...@hovoldconsulting.com/
#regzbot introduced: 5814b8bf086a
