Re: [PATCH 1/4] dt-bindings: display: ti,am65x-dss: Minor Cleanup
On 14/05/24 00:49, Rob Herring wrote: > On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote: >> Reduce tab size from 8 spaces to 4 spaces to make the bindings >> consistent, and easy to expand. > > "Re-indent the example" would be more specific than "minor cleanups" in > the subject. That would be better. Will reword this in v2. Thank you! Regards Aradhya > > Otherwise, > > Acked-by: Rob Herring (Arm) > >> >> Signed-off-by: Aradhya Bhatia >> --- >> .../bindings/display/ti/ti,am65x-dss.yaml | 54 +-- >> 1 file changed, 27 insertions(+), 27 deletions(-) >
Re: [PATCH 3/4] dt-bindings: display: ti,am65x-dss: Add OLDI properties for AM625 DSS
On 14/05/24 01:05, Rob Herring wrote: > On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote: >> The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the >> properties. >> >> Signed-off-by: Aradhya Bhatia >> --- >> .../bindings/display/ti/ti,am65x-dss.yaml | 136 +- >> 1 file changed, 135 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> index 399d68986326..4aa2de59b32b 100644 >> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> @@ -85,12 +85,30 @@ properties: >> >> properties: >>port@0: >> -$ref: /schemas/graph.yaml#/properties/port >> +$ref: /schemas/graph.yaml#/$defs/port-base > > You don't need this change. You aren't adding any extra properties. Alright. I will make the change. > >> description: >>For AM65x DSS, the OLDI output port node from video port 1. >>For AM625 DSS, the internal DPI output port node from video >>port 1. >>For AM62A7 DSS, the port is tied off inside the SoC. >> +properties: >> + endpoint@0: >> +$ref: /schemas/graph.yaml#/properties/endpoint >> +description: >> + For AM625 DSS, VP Connection to OLDI0. >> + For AM65X DSS, OLDI output from the SoC. >> + >> + endpoint@1: >> +$ref: /schemas/graph.yaml#/properties/endpoint >> +description: >> + For AM625 DSS, VP Connection to OLDI1. >> + >> +anyOf: >> + - required: >> + - endpoint >> + - required: >> + - endpoint@0 >> + - endpoint@1 >> >>port@1: >> $ref: /schemas/graph.yaml#/properties/port >> @@ -112,6 +130,22 @@ properties: >>Input memory (from main memory to dispc) bandwidth limit in >>bytes per second >> >> + oldi-txes: >> +type: object >> +properties: >> + "#address-cells": >> +const: 1 >> + >> + "#size-cells": >> +const: 0 >> + >> +patternProperties: >> + '^oldi_tx@[0-1]$': >> +type: object >> +$ref: ti,am625-oldi.yaml# >> +unevaluatedProperties: false >> +description: OLDI transmitters connected to the DSS VPs > > Connected to is not part of the DSS. I don't think these nodes belong > here as mentioned in the other patch. > Replied to this in patch 2/4 to keep the discussion in one thread. Regards Aradhya
Re: [PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
Hi Rob,
Thank you for reviewing the patches!
On 14/05/24 01:00, Rob Herring wrote:
> On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote:
>> Hi Laurent,
>>
>> Thank you for reviewing the patches!
>>
>> On 13-May-24 01:04, Laurent Pinchart wrote:
>>> Hi Aradhya,
>>>
>>> Thank you for the patch.
>>>
>>> On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
Add devicetree binding schema for AM625 OLDI Transmitters.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
MAINTAINERS | 1 +
2 files changed, 154 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
diff --git
a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
new file mode 100644
index ..0a96e600bc0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM625 OLDI Transmitter
+
+maintainers:
+ - Tomi Valkeinen
+ - Aradhya Bhatia
+
+description: |
+ The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized
RGB
+ pixel data transmission between host and flat panel display over LVDS
(Low
+ Voltage Differential Sampling) interface. The OLDI TX consists of
7-to-1 data
+ serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS
output
+ formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB
or
+ padded and un-padded 18-bit RGB bus formats as input.
+
+properties:
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: serial clock input for the OLDI transmitters
+
+ clock-names:
+const: s_clk
+
+ ti,companion-oldi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to companion OLDI transmitter. This property is mandatory
for the
+ primarty OLDI TX if the OLDI TXes are expected to work either in
dual-lvds
+ mode or in clone mode. This property should point to the secondary
OLDI
+ TX.
+
+ ti,secondary-oldi:
+type: boolean
+description: Boolean property to mark an OLDI TX as secondary node.
+
+ ti,oldi-io-ctrl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to syscon device node mapping OLDI IO_CTRL registers found
in the
+ control MMR region. This property is needed for OLDI interface to
work.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel RGB input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: LVDS output port
+
+required:
+ - port@0
+ - port@1
+
+allOf:
+ - if:
+ properties:
+ti,secondary-oldi: true
+then:
+ properties:
+ti,companion-oldi: false
+ti,oldi-io-ctrl: false
+clocks: false
+clock-names: false
+
+else:
+ required:
+- ti,oldi-io-ctrl
+- clocks
+- clock-names
+
+required:
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+oldi_txes {
+#address-cells = <1>;
+#size-cells = <0>;
+oldi: oldi@0 {
+reg = <0>;
+clocks = <_clks 186 0>;
+clock-names = "s_clk";
+ti,oldi-io-ctrl = <_oldi_io_ctrl>;
>>>
>>> What bus does this device live on ? Couldn't the I/O register space be
>>> referenced by the reg property ?.
>>>
>>
>> These registers are a part of the system-controller register space
>> (ctrl_mmr0). The whole register set is owned by the main_conf[0]
>> devicetree node, with sub-nodes pointing to specific regions. That's why
>> I cannot reference these registers directly.
>
> Then what does 'reg' represent? Looks like you just made up an index. If
> so, then this should probably be a child of _oldi_io_ctrl instead.
> Or it should just be merged into that node.
>
I did make up an index when I used the 'reg' property. Similar to
Re: [PATCH v2 2/2] Add dp PHY dt-bindings
Re: dma-buf sg mangling
On Mon, May 13, 2024 at 1:09 PM Christian König
wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > Hey,
> >
> > so this is a bit of a silly problem but I'd still like to solve it
> > properly. The tldr is that virtualized drivers abuse
> > drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
> > virtgpu and xen punt on it) because there doesn't seem to be a
> > universally supported way of converting the sg_table back to a list of
> > pages without some form of gart to do it.
>
> Well the whole point is that you should never touch the pages in the
> sg_table in the first place.
>
> The long term plan is actually to completely remove the pages from that
> interface.
First let me clarify that I'm not arguing for access to those pages.
What I'd like to figure out are precise semantics for all of this
prime import/map business on drivers that don't have some dedicated
hardware to turn dma_addr_t array into something readable. If the
general consensus is that those devices are broken, so be it.
> > drm_prime_sg_to_page_array is deprecated (for all the right reasons on
> > actual hardware) but in our cooky virtualized world we don't have
> > gart's so what are we supposed to do with the dma_addr_t from the
> > imported sg_table? What makes it worse (and definitely breaks xen) is
> > that with CONFIG_DMABUF_DEBUG the sg page_link is mangled via
> > mangle_sg_table so drm_prime_sg_to_page_array won't even work.
>
> XEN and KVM were actually adjusted to not touch the struct pages any more.
>
> I'm not sure if that work is already upstream or not but I had to
> explain it over and over again why their approach doesn't work.
I'd love to see those patches. Upstream xen definitely still uses it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen/xen_drm_front_gem.c#n263
which looks pretty broken to me, especially with CONFIG_DMABUF_DEBUG
because drm_gem_prime_import
will call dma_buf_map_attachment_unlocked:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_prime.c#n940
which will call __map_dma_buf
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/dma-buf.c#n1131
which will mangle the sg's page_list before calling xen's
gem_prime_import_sg_table. Which means the drm_prime_sg_to_page_array
that's used in xen's gem_prime_import_sg_table is silently generating
broken pages and the entire thing should just be a kernel oops (btw,
it'd probably be a good idea to not have drm_prime_sg_to_page_array
generate garbage with CONFIG_DMABUF_DEBUG and print some kind of a
warning).
> > The reason why I'm saying it's a bit of a silly problem is that afaik
> > currently it only affects IGT testing with vgem (because the rest of
> > external gem objects will be from the virtualized gpu itself which is
> > different). But do you have any ideas on what we'd like to do with
> > this long term? i.e. we have a virtualized gpus without iommu, we have
> > sg_table with some memory and we'd like to import it. Do we just
> > assume that the sg_table on those configs will always reference cpu
> > accessible memory (i.e. if it's external it only comes through
> > drm_gem_shmem_object) and just do some horrific abomination like:
> > for (i = 0; i < bo->ttm->num_pages; ++i) {
> > phys_addr_t pa = dma_to_phys(vmw->drm.dev, bo->ttm->dma_address[i]);
> > pages[i] = pfn_to_page(PHYS_PFN(pa));
> > }
> > or add a "i know this is cpu accessible, please demangle" flag to
> > drm_prime_sg_to_page_array or try to have some kind of more permanent
> > solution?
>
> Well there is no solution for that. Accessing the underlying struct page
> through the sg_table is illegal in the first place.
>
> So the question is not how to access the struct page, but rather why do
> you want to do this?
Rob mentioned one usecase, but to be honest, as I mentioned in the
beginning I'd like to have a semantic clarity to the general problem
of going from dma_addr_t to something readable on non iomem resources,
e.g. get the IGT vgem<->vmwgfx tests running, i.e.:
vgem_handle = dumb_buffer_create(vgem_fd, );
dma_buf_fd = prime_handle_to_fd(vgem_fd, vgem_handle);
vmw_handle = prime_fd_to_handle(vmw_fd, dma_buf_fd);
void *ptr = vmw_map_bo(vmw_fd, vmw_handle, ...); <- crash
trying to map that bo will crash because we'll endup in
ttm_bo_vm_fault_reserved which will check whether
bo->resource->bus.is_iomem, which it won't be because every vmwgfx
buffer is just system memory and it will try to access the ttm pages
which don't exist and crash:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ttm/ttm_bo_vm.c#n249
On our hypervisors that are less than 8 years old all of vmwgfx
buffers are always system memory, and when we get an external buffer
from vgem, which is also system memory we have no currently supported
way of populating the ttm::pages to be able to map/read it.
It's fine if the
linux-next: manual merge of the devicetree tree with the drm tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
between commit:
90ed42ceda76 ("dt-bindings: display: novatek, nt36523: define ports")
from the drm tree and commit:
9fa6bcf23e44 ("dt-bindings: display: panel: constrain 'reg' in DSI panels")
from the devicetree tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
index bbeea8cfa5fb,0447ee724947..
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
@@@ -34,7 -40,7 +37,6 @@@ properties
vddio-supply:
description: regulator that supplies the I/O voltage
- reg: true
- ports: true
rotation: true
backlight: true
pgpxI5EsETxrV.pgp
Description: OpenPGP digital signature
RE: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no display issue
-Original Message-
From: Robert Foss
Sent: Tuesday, May 14, 2024 1:45 AM
To: Kuro Chung (鐘仕廷)
Cc: Allen Chen ; Pin-yen Lin ;
Kenneth Hung (洪家倫) ; Kuro Chung
; Andrzej Hajda
; Neil Armstrong ; Laurent
Pinchart ; Jonas Karlman ;
Jernej Skrabec ; Maarten Lankhorst
; Maxime Ripard ; Thomas
Zimmermann ; David Airlie ; Daniel
Vetter ; open list:DRM DRIVERS
; open list
Subject: Re: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no
display issue
On Mon, May 13, 2024 at 7:42 PM Robert Foss wrote:
>
> On Mon, May 6, 2024 at 11:36 AM kuro wrote:
> >
> > From: Kuro
> >
> > ITE added a FIFO reset bit for input video. When system power
> > resume, the TTL input of it6505 may get some noise before video
> > signal stable and the hardware function reset is required.
> > But the input FIFO reset will also trigger error interrupts of output
> > module rising.
> > Thus, it6505 have to wait a period can clear those expected error
> > interrupts caused by manual hardware reset in one interrupt handler calling
> > to avoid interrupt looping.
> >
> > Signed-off-by: Kuro Chung
> >
> > ---
> > drivers/gpu/drm/bridge/ite-it6505.c | 73
> > +++--
> > 1 file changed, 49 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> > b/drivers/gpu/drm/bridge/ite-it6505.c
> > index b53da9bb65a16..64e2706e3d0c3 100644
> > --- a/drivers/gpu/drm/bridge/ite-it6505.c
> > +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> > @@ -1317,9 +1317,15 @@ static void it6505_video_reset(struct it6505 *it6505)
> > it6505_link_reset_step_train(it6505);
> > it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE,
> > EN_VID_MUTE);
> > it6505_set_bits(it6505, REG_INFOFRAME_CTRL, EN_VID_CTRL_PKT, 0x00);
> > - it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > +
> > + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
> > TX_FIFO_RESET);
> > + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
> > + 0x00);
> > +
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO,
> > RST_501_FIFO);
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO,
> > 0x00);
> > +
> > + it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > + usleep_range(1000, 2000);
> > it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, 0x00);
> > }
> >
> > @@ -2249,12 +2255,11 @@ static void it6505_link_training_work(struct
> > work_struct *work)
> > if (ret) {
> > it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > it6505_link_train_ok(it6505);
> > - return;
> > } else {
> > it6505->auto_train_retry--;
> > + it6505_dump(it6505);
> > }
> >
> > - it6505_dump(it6505);
> > }
> >
> > static void it6505_plugged_status_to_codec(struct it6505 *it6505)
> > @@ -2475,31 +2480,53 @@ static void it6505_irq_link_train_fail(struct
> > it6505 *it6505)
> > schedule_work(>link_works);
> > }
> >
> > -static void it6505_irq_video_fifo_error(struct it6505 *it6505)
> > +static bool it6505_test_bit(unsigned int bit, const unsigned int
> > +*addr)
> > {
> > - struct device *dev = >client->dev;
> > -
> > - DRM_DEV_DEBUG_DRIVER(dev, "video fifo overflow interrupt");
> > - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > - flush_work(>link_works);
> > - it6505_stop_hdcp(it6505);
> > - it6505_video_reset(it6505);
> > + return 1 & (addr[bit / BITS_PER_BYTE] >> (bit %
> > + BITS_PER_BYTE));
> > }
> >
> > -static void it6505_irq_io_latch_fifo_overflow(struct it6505
> > *it6505)
> > +static void it6505_irq_video_handler(struct it6505 *it6505, const
> > +int *int_status)
> > {
> > struct device *dev = >client->dev;
> > + int reg_0d, reg_int03;
> >
> > - DRM_DEV_DEBUG_DRIVER(dev, "IO latch fifo overflow interrupt");
> > - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > - flush_work(>link_works);
> > - it6505_stop_hdcp(it6505);
> > - it6505_video_reset(it6505);
> > -}
> > + /*
> > +* When video SCDT change with video not stable,
> > +* Or video FIFO error, need video reset
> > +*/
> >
> > -static bool it6505_test_bit(unsigned int bit, const unsigned int
> > *addr) -{
> > - return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> > + if ((!it6505_get_video_status(it6505) &&
> > + (it6505_test_bit(INT_SCDT_CHANGE, (unsigned int *)
> > int_status))) ||
> > + (it6505_test_bit(BIT_INT_IO_FIFO_OVERFLOW, (unsigned int *)
> > int_status)) ||
> > + (it6505_test_bit(BIT_INT_VID_FIFO_ERROR, (unsigned
> > + int *) int_status))) {
> > +
> > + it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > + flush_work(>link_works);
> > + it6505_stop_hdcp(it6505);
> > +
[PATCH v2] drm/bridge: tc358767: Enable FRMSYNC timing generator
TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC description
says "This bit should be disabled only in video mode transmission where Host
transmits video timing together with video data and where pixel clock source
is from DSI clock." . This driver always sources pixel clock from external xtal,
therefore the FRMSYNC bit must always be enabled, enable it.
This fixes an actual issue with DSI-to-DPI mode, where the display would
randomly show subtle pixel flickering, or wobble, or shimmering. This is
visible on solid gray color, but the degree of the shimmering differs
between boots, which makes it hard to debug.
There is a caveat to the FRMSYNC and this bridge pixel PLL, which can only
generate pixel clock with limited accuracy, it may therefore be necessary
to reduce the HFP to fit into line length of input pixel data, to avoid any
possible overflows, which make the output video look striped horizontally.
Reviewed-by: Robert Foss
Signed-off-by: Marek Vasut
---
Cc: Adam Ford
Cc: Alexander Stein
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Frieder Schrempf
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Michael Walle
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
V2: - Use plain DIV_ROUND_UP() instead of custom local one
- Add RB from Robert
---
drivers/gpu/drm/bridge/tc358767.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 166f9a3e9622d..a4d4deff7085d 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -382,6 +382,9 @@ struct tc_data {
/* HPD pin number (0 or 1) or -ENODEV */
int hpd_pin;
+
+ /* Number of pixels to subtract from a line due to pixel clock delta */
+ u32 line_pixel_subtract;
};
static inline struct tc_data *aux_to_tc(struct drm_dp_aux *a)
@@ -658,8 +661,11 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk,
u32 pixelclock)
return -EINVAL;
}
- dev_dbg(tc->dev, "PLL: got %d, delta %d\n", best_pixelclock,
- best_delta);
+ tc->line_pixel_subtract = tc->mode.htotal -
+ DIV_ROUND_UP(tc->mode.htotal * (u64)best_pixelclock,
(u64)pixelclock);
+
+ dev_dbg(tc->dev, "PLL: got %d, delta %d (subtract %d px)\n",
best_pixelclock,
+ best_delta, tc->line_pixel_subtract);
dev_dbg(tc->dev, "PLL: %d / %d / %d * %d / %d\n", refclk,
ext_div[best_pre], best_div, best_mul, ext_div[best_post]);
@@ -885,6 +891,12 @@ static int tc_set_common_video_mode(struct tc_data *tc,
upper_margin, lower_margin, vsync_len);
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
+ if (right_margin > tc->line_pixel_subtract) {
+ right_margin -= tc->line_pixel_subtract;
+ } else {
+ dev_err(tc->dev, "Bridge pixel clock too slow for mode\n");
+ right_margin = 0;
+ }
/*
* LCD Ctl Frame Size
@@ -894,7 +906,7 @@ static int tc_set_common_video_mode(struct tc_data *tc,
*/
ret = regmap_write(tc->regmap, VPCTRL0,
FIELD_PREP(VSDELAY, right_margin + 10) |
- OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
+ OPXLFMT_RGB888 | FRMSYNC_ENABLED | MSF_DISABLED);
if (ret)
return ret;
--
2.43.0
Re: [PATCH net-next v9 00/14] Device Memory TCP
On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote: > Device Memory TCP Sorry Mina, this is too big to apply during the merge window :( -- pw-bot: defer
Re: dma-buf sg mangling
On Mon, May 13, 2024 at 11:27 AM Christian König
wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > Hey,
> >
> > so this is a bit of a silly problem but I'd still like to solve it
> > properly. The tldr is that virtualized drivers abuse
> > drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
> > virtgpu and xen punt on it) because there doesn't seem to be a
> > universally supported way of converting the sg_table back to a list of
> > pages without some form of gart to do it.
>
> Well the whole point is that you should never touch the pages in the
> sg_table in the first place.
>
> The long term plan is actually to completely remove the pages from that
> interface.
>
> > drm_prime_sg_to_page_array is deprecated (for all the right reasons on
> > actual hardware) but in our cooky virtualized world we don't have
> > gart's so what are we supposed to do with the dma_addr_t from the
> > imported sg_table? What makes it worse (and definitely breaks xen) is
> > that with CONFIG_DMABUF_DEBUG the sg page_link is mangled via
> > mangle_sg_table so drm_prime_sg_to_page_array won't even work.
>
> XEN and KVM were actually adjusted to not touch the struct pages any more.
>
> I'm not sure if that work is already upstream or not but I had to
> explain it over and over again why their approach doesn't work.
>
> > The reason why I'm saying it's a bit of a silly problem is that afaik
> > currently it only affects IGT testing with vgem (because the rest of
> > external gem objects will be from the virtualized gpu itself which is
> > different). But do you have any ideas on what we'd like to do with
> > this long term? i.e. we have a virtualized gpus without iommu, we have
> > sg_table with some memory and we'd like to import it. Do we just
> > assume that the sg_table on those configs will always reference cpu
> > accessible memory (i.e. if it's external it only comes through
> > drm_gem_shmem_object) and just do some horrific abomination like:
> > for (i = 0; i < bo->ttm->num_pages; ++i) {
> > phys_addr_t pa = dma_to_phys(vmw->drm.dev, bo->ttm->dma_address[i]);
> > pages[i] = pfn_to_page(PHYS_PFN(pa));
> > }
> > or add a "i know this is cpu accessible, please demangle" flag to
> > drm_prime_sg_to_page_array or try to have some kind of more permanent
> > solution?
>
> Well there is no solution for that. Accessing the underlying struct page
> through the sg_table is illegal in the first place.
>
> So the question is not how to access the struct page, but rather why do
> you want to do this?
It _think_ Zack is trying to map guest paged back buffers to the host
GPU? Which would require sending the pfn's in some form to the host
vmm..
virtgpu goes the other direction with mapping host page backed GEM
buffers to guest as "vram" (although for various reasons I kinda want
to go in the other direction)
BR,
-R
> Regards,
> Christian.
>
> >
> > z
>
[PATCH] drm: Combine identical if/elif code blocks
Merge the identical if/elif code blocks and remove the following two warnings reported by make includecheck: asm/ioctl.h is included more than once linux/types.h is included more than once Signed-off-by: Thorsten Blum --- include/uapi/drm/drm.h | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 16122819edfe..315af7b19c97 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -35,13 +35,7 @@ #ifndef _DRM_H_ #define _DRM_H_ -#if defined(__KERNEL__) - -#include -#include -typedef unsigned int drm_handle_t; - -#elif defined(__linux__) +#if defined(__KERNEL__) || defined(__linux__) #include #include -- 2.45.0
Re: [PATCH v4] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Hey,
Understood. Thanks a lot and sorry for any inconvenience.
Mohamed
On Mon, May 13, 2024 at 11:28 PM Danilo Krummrich wrote:
> Hi Mohamed,
>
> Thank you for fixing this up!
>
> On 5/9/24 22:43, Mohamed Ahmed wrote:
> > Allows PTE kind and tile mode on BO create with VM_BIND,
> > and adds a GETPARAM to indicate this change. This is needed to support
>
> It's usually better to use imperative verb form for commit messages. No
> need to send a new version though.
>
> > modifiers in NVK and ensure correctness when dealing with the nouveau
> > GL driver.
> >
> > The userspace modifiers implementation this is for can be found here:
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
> >
> > Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
> > Signed-off-by: Mohamed Ahmed
>
> Applied to drm-misc-next-fixes.
>
> Generally, please make sure to use scripts/get_maintainer.pl before
> sending
> patches.
>
> - Danilo
>
> > ---
> > drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++
> > drivers/gpu/drm/nouveau/nouveau_bo.c| 44 +++--
> > include/uapi/drm/nouveau_drm.h | 7
> > 3 files changed, 29 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> > index 80f74ee0f..47e53e17b 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> > @@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
> > getparam->value =
> (u64)ttm_resource_manager_usage(vram_mgr);
> > break;
> > }
> > + case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
> > + getparam->value = 1;
> > + break;
> > default:
> > NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
> getparam->param);
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index db8cbf615..186add400 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -241,28 +241,28 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64
> *size, int *align, u32 domain,
> > }
> >
> > nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
> > - if (!nouveau_cli_uvmm(cli) || internal) {
> > - /* for BO noVM allocs, don't assign kinds */
> > - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> > - nvbo->kind = (tile_flags & 0xff00) >> 8;
> > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> > - kfree(nvbo);
> > - return ERR_PTR(-EINVAL);
> > - }
> >
> > - nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> > - } else if (cli->device.info.family >=
> NV_DEVICE_INFO_V0_TESLA) {
> > - nvbo->kind = (tile_flags & 0x7f00) >> 8;
> > - nvbo->comp = (tile_flags & 0x0003) >> 16;
> > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> > - kfree(nvbo);
> > - return ERR_PTR(-EINVAL);
> > - }
> > - } else {
> > - nvbo->zeta = (tile_flags & 0x0007);
> > + if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> > + nvbo->kind = (tile_flags & 0xff00) >> 8;
> > + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> > + kfree(nvbo);
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> > + } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> > + nvbo->kind = (tile_flags & 0x7f00) >> 8;
> > + nvbo->comp = (tile_flags & 0x0003) >> 16;
> > + if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> > + kfree(nvbo);
> > + return ERR_PTR(-EINVAL);
> > }
> > - nvbo->mode = tile_mode;
> > + } else {
> > + nvbo->zeta = (tile_flags & 0x0007);
> > + }
> > + nvbo->mode = tile_mode;
> >
> > + if (!nouveau_cli_uvmm(cli) || internal) {
> > /* Determine the desirable target GPU page size for the
> buffer. */
> > for (i = 0; i < vmm->page_nr; i++) {
> > /* Because we cannot currently allow VMM maps to
> fail
> > @@ -304,12 +304,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64
> *size, int *align, u32 domain,
> > }
> > nvbo->page = vmm->page[pi].shift;
> > } else {
> > - /* reject other tile flags when in VM mode. */
> > - if (tile_mode)
> > - return ERR_PTR(-EINVAL);
> > - if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
> > -
Re: [PATCH 2/3] dt-bindings: display: panel: constrain 'reg' in SPI panels
On Thu, May 9, 2024 at 11:43 AM Krzysztof Kozlowski wrote: > SPI-attached devices could have more than one chip-select, thus their > bindings are supposed to constrain the 'reg' property to match hardware. > Add missing 'reg' constrain for SPI-attached display panels. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v6 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel
On Sat, May 11, 2024 at 4:14 AM Cong Yang wrote: > The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller > which fits in nicely with the existing panel-himax-hx83102 driver. Hence, > we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v6 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
On Sat, May 11, 2024 at 4:13 AM Cong Yang wrote: > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller > which fits in nicely with the existing panel-himax-hx83102 driver. Hence, > we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Hi Mohamed,
Thank you for fixing this up!
On 5/9/24 22:43, Mohamed Ahmed wrote:
Allows PTE kind and tile mode on BO create with VM_BIND,
and adds a GETPARAM to indicate this change. This is needed to support
It's usually better to use imperative verb form for commit messages. No
need to send a new version though.
modifiers in NVK and ensure correctness when dealing with the nouveau
GL driver.
The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Signed-off-by: Mohamed Ahmed
Applied to drm-misc-next-fixes.
Generally, please make sure to use scripts/get_maintainer.pl before sending
patches.
- Danilo
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++
drivers/gpu/drm/nouveau/nouveau_bo.c| 44 +++--
include/uapi/drm/nouveau_drm.h | 7
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 80f74ee0f..47e53e17b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
break;
}
+ case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
+ getparam->value = 1;
+ break;
default:
NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
getparam->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db8cbf615..186add400 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -241,28 +241,28 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
- if (!nouveau_cli_uvmm(cli) || internal) {
- /* for BO noVM allocs, don't assign kinds */
- if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
- nvbo->kind = (tile_flags & 0xff00) >> 8;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
- } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
- nvbo->kind = (tile_flags & 0x7f00) >> 8;
- nvbo->comp = (tile_flags & 0x0003) >> 16;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- } else {
- nvbo->zeta = (tile_flags & 0x0007);
+ if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
+ nvbo->kind = (tile_flags & 0xff00) >> 8;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
+ } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+ nvbo->kind = (tile_flags & 0x7f00) >> 8;
+ nvbo->comp = (tile_flags & 0x0003) >> 16;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
}
- nvbo->mode = tile_mode;
+ } else {
+ nvbo->zeta = (tile_flags & 0x0007);
+ }
+ nvbo->mode = tile_mode;
+ if (!nouveau_cli_uvmm(cli) || internal) {
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
@@ -304,12 +304,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->page = vmm->page[pi].shift;
} else {
- /* reject other tile flags when in VM mode. */
- if (tile_mode)
- return ERR_PTR(-EINVAL);
- if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
- return ERR_PTR(-EINVAL);
-
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index cd84227f1..5402f77ee 100644
--- a/include/uapi/drm/nouveau_drm.h
+++
[PATCH] drm/edid: remove drm_do_get_edid()
All users of drm_do_get_edid() have been converted to
drm_edid_read_custom(). Remove the unused function to prevent new users
from creeping in.
Signed-off-by: Jani Nikula
---
Cc: Robert Foss
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid.c | 28
include/drm/drm_edid.h | 4
2 files changed, 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f54c91b31b2..0f7c4c5b14b9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2464,34 +2464,6 @@ static struct edid *_drm_do_get_edid(struct
drm_connector *connector,
return NULL;
}
-/**
- * drm_do_get_edid - get EDID data using a custom EDID block read function
- * @connector: connector we're probing
- * @read_block: EDID block read function
- * @context: private data passed to the block read function
- *
- * When the I2C adapter connected to the DDC bus is hidden behind a device that
- * exposes a different interface to read EDID blocks this function can be used
- * to get EDID data using a custom block read function.
- *
- * As in the general case the DDC bus is accessible by the kernel at the I2C
- * level, drivers must make all reasonable efforts to expose it as an I2C
- * adapter and use drm_get_edid() instead of abusing this function.
- *
- * The EDID may be overridden using debugfs override_edid or firmware EDID
- * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this priority
- * order. Having either of them bypasses actual EDID reads.
- *
- * Return: Pointer to valid EDID or NULL if we couldn't find any.
- */
-struct edid *drm_do_get_edid(struct drm_connector *connector,
-read_block_fn read_block,
-void *context)
-{
- return _drm_do_get_edid(connector, read_block, context, NULL);
-}
-EXPORT_SYMBOL_GPL(drm_do_get_edid);
-
/**
* drm_edid_raw - Get a pointer to the raw EDID data.
* @drm_edid: drm_edid container
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b085525e53e2..6bdfa254a1c1 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -423,10 +423,6 @@ static inline void drm_edid_decode_panel_id(u32 panel_id,
char vend[4], u16 *pro
}
bool drm_probe_ddc(struct i2c_adapter *adapter);
-struct edid *drm_do_get_edid(struct drm_connector *connector,
- int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
- size_t len),
- void *data);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
--
2.39.2
Re: [PATCH v6 2/7] drm/panel: himax-hx83102: Break out as separate driver
On Sat, May 11, 2024 at 4:13 AM Cong Yang wrote: > The Starry HX83102 based mipi panel should never have been part of the boe > tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a > separate driver to enable the hx83102 controller. > > In hx83102 driver, add DSI commands as macros. So it can add some panels > with same control model in the future. > > In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of > prepare() function , and call 0x11 and 0x29 at end of inital. For > himax-hx83102 driver, we move 0x11 and 0x29 cmds invoked at prepare() > function. > > Note:0x11 is mipi_dsi_dcs_exit_sleep_mode > 0x29 is mipi_dsi_dcs_set_display_on > > [1]: > https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com > > Signed-off-by: Cong Yang With Doug's comments addressed: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 3/3] dt-bindings: display: panel: constrain 'reg' in DSI panels
On Thu, May 9, 2024 at 11:43 AM Krzysztof Kozlowski wrote: > DSI-attached devices could respond to more than one virtual channel > number, thus their bindings are supposed to constrain the 'reg' property > to match hardware. Add missing 'reg' constrain for DSI-attached display > panels, based on DTS sources in Linux kernel (assume all devices take > only one channel number). > > Signed-off-by: Krzysztof Kozlowski Looks right to me. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
On Wed, May 8, 2024 at 10:53 PM Douglas Anderson wrote: > This is a mechanical conversion of the novatek-nt36672e driver to use > the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for > clients to understand and using it also causes smaller code to be > generated. Specifically: > > $ scripts/bloat-o-meter \ > ...after/panel-novatek-nt36672e.ko \ > ...ctx/panel-novatek-nt36672e.ko > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988) > Function old new delta > nt36672e_1080x2408_60hz_init62365248-988 > Total: Before=10651, After=9663, chg -9.28% > > Cc: Ritesh Kumar > Signed-off-by: Douglas Anderson Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 2/9] drm: Export drm_plane_has_format()
On Mon, 13 May 2024, Ville Syrjala wrote: > From: Ville Syrjälä > > Export drm_plane_has_format() so that drivers can use it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_crtc_internal.h | 2 -- > drivers/gpu/drm/drm_plane.c | 1 + > include/drm/drm_plane.h | 2 ++ > 3 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h > b/drivers/gpu/drm/drm_crtc_internal.h > index 898e0e8b51be..e207759ca045 100644 > --- a/drivers/gpu/drm/drm_crtc_internal.h > +++ b/drivers/gpu/drm/drm_crtc_internal.h > @@ -272,8 +272,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev, > /* drm_plane.c */ > int drm_plane_register_all(struct drm_device *dev); > void drm_plane_unregister_all(struct drm_device *dev); > -bool drm_plane_has_format(struct drm_plane *plane, > - u32 format, u64 modifier); > struct drm_mode_rect * > __drm_plane_get_damage_clips(const struct drm_plane_state *state); > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 268aa2299df5..a51d4dd3f7de 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -906,6 +906,7 @@ bool drm_plane_has_format(struct drm_plane *plane, > > return true; > } > +EXPORT_SYMBOL(drm_plane_has_format); > > static int __setplane_check(struct drm_plane *plane, > struct drm_crtc *crtc, > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > index 9507542121fa..dd718c62ac31 100644 > --- a/include/drm/drm_plane.h > +++ b/include/drm/drm_plane.h > @@ -972,6 +972,8 @@ static inline struct drm_plane *drm_plane_find(struct > drm_device *dev, > #define drm_for_each_plane(plane, dev) \ > list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) > > +bool drm_plane_has_format(struct drm_plane *plane, > + u32 format, u64 modifier); > bool drm_any_plane_has_format(struct drm_device *dev, > u32 format, u64 modifier); -- Jani Nikula, Intel
Re: [PATCH 1/9] drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()
On Mon, 13 May 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename drm_plane_check_pixel_format() to drm_plane_has_format()
> and change the return type accordingly. Allows one to write
> more natural code.
>
> Also matches drm_any_plane_has_format() better.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_atomic.c| 7 ++-
> drivers/gpu/drm/drm_crtc.c | 6 ++
> drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
> drivers/gpu/drm/drm_plane.c | 22 ++
> 4 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a91737adf8e7..e22560213b8e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -608,7 +608,6 @@ static int drm_atomic_plane_check(const struct
> drm_plane_state *old_plane_state,
> unsigned int fb_width, fb_height;
> struct drm_mode_rect *clips;
> uint32_t num_clips;
> - int ret;
>
> /* either *both* CRTC and FB must be set, or neither */
> if (crtc && !fb) {
> @@ -635,14 +634,12 @@ static int drm_atomic_plane_check(const struct
> drm_plane_state *old_plane_state,
> }
>
> /* Check whether this plane supports the fb pixel format. */
> - ret = drm_plane_check_pixel_format(plane, fb->format->format,
> -fb->modifier);
> - if (ret) {
> + if (!drm_plane_has_format(plane, fb->format->format, fb->modifier)) {
> drm_dbg_atomic(plane->dev,
> "[PLANE:%d:%s] invalid pixel format %p4cc,
> modifier 0x%llx\n",
> plane->base.id, plane->name,
> >format->format, fb->modifier);
> - return ret;
> + return -EINVAL;
> }
>
> /* Give drivers some help against integer overflows */
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 483969b84a30..3488ff067c69 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -789,12 +789,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>* case.
>*/
> if (!plane->format_default) {
> - ret = drm_plane_check_pixel_format(plane,
> -fb->format->format,
> -fb->modifier);
> - if (ret) {
> + if (!drm_plane_has_format(plane, fb->format->format,
> fb->modifier)) {
> drm_dbg_kms(dev, "Invalid pixel format %p4cc,
> modifier 0x%llx\n",
> >format->format, fb->modifier);
> + ret = -EINVAL;
> goto out;
> }
> }
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 25aaae937ceb..898e0e8b51be 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -272,8 +272,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> /* drm_plane.c */
> int drm_plane_register_all(struct drm_device *dev);
> void drm_plane_unregister_all(struct drm_device *dev);
> -int drm_plane_check_pixel_format(struct drm_plane *plane,
> - u32 format, u64 modifier);
> +bool drm_plane_has_format(struct drm_plane *plane,
> + u32 format, u64 modifier);
> struct drm_mode_rect *
> __drm_plane_get_damage_clips(const struct drm_plane_state *state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 57662a1fd345..268aa2299df5 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -877,8 +877,8 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
> return 0;
> }
>
> -int drm_plane_check_pixel_format(struct drm_plane *plane,
> - u32 format, u64 modifier)
> +bool drm_plane_has_format(struct drm_plane *plane,
> + u32 format, u64 modifier)
> {
> unsigned int i;
>
> @@ -887,24 +887,24 @@ int drm_plane_check_pixel_format(struct drm_plane
> *plane,
> break;
> }
> if (i == plane->format_count)
> - return -EINVAL;
> + return false;
>
> if (plane->funcs->format_mod_supported) {
> if (!plane->funcs->format_mod_supported(plane, format,
> modifier))
> - return -EINVAL;
> + return false;
> } else {
> if (!plane->modifier_count)
> - return 0;
> + return true;
>
> for (i = 0; i < plane->modifier_count; i++) {
> if (modifier == plane->modifiers[i])
>
Re: [PATCH 3/4] dt-bindings: display: ti,am65x-dss: Add OLDI properties for AM625 DSS
On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote: > The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the > properties. > > Signed-off-by: Aradhya Bhatia > --- > .../bindings/display/ti/ti,am65x-dss.yaml | 136 +- > 1 file changed, 135 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > index 399d68986326..4aa2de59b32b 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > @@ -85,12 +85,30 @@ properties: > > properties: >port@0: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base You don't need this change. You aren't adding any extra properties. > description: >For AM65x DSS, the OLDI output port node from video port 1. >For AM625 DSS, the internal DPI output port node from video >port 1. >For AM62A7 DSS, the port is tied off inside the SoC. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: > + For AM625 DSS, VP Connection to OLDI0. > + For AM65X DSS, OLDI output from the SoC. > + > + endpoint@1: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: > + For AM625 DSS, VP Connection to OLDI1. > + > +anyOf: > + - required: > + - endpoint > + - required: > + - endpoint@0 > + - endpoint@1 > >port@1: > $ref: /schemas/graph.yaml#/properties/port > @@ -112,6 +130,22 @@ properties: >Input memory (from main memory to dispc) bandwidth limit in >bytes per second > > + oldi-txes: > +type: object > +properties: > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 0 > + > +patternProperties: > + '^oldi_tx@[0-1]$': > +type: object > +$ref: ti,am625-oldi.yaml# > +unevaluatedProperties: false > +description: OLDI transmitters connected to the DSS VPs Connected to is not part of the DSS. I don't think these nodes belong here as mentioned in the other patch. Rob
Re: [PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote:
> Hi Laurent,
>
> Thank you for reviewing the patches!
>
> On 13-May-24 01:04, Laurent Pinchart wrote:
> > Hi Aradhya,
> >
> > Thank you for the patch.
> >
> > On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
> >> Add devicetree binding schema for AM625 OLDI Transmitters.
> >>
> >> Signed-off-by: Aradhya Bhatia
> >> ---
> >> .../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
> >> MAINTAINERS | 1 +
> >> 2 files changed, 154 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> new file mode 100644
> >> index ..0a96e600bc0b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> @@ -0,0 +1,153 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments AM625 OLDI Transmitter
> >> +
> >> +maintainers:
> >> + - Tomi Valkeinen
> >> + - Aradhya Bhatia
> >> +
> >> +description: |
> >> + The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized
> >> RGB
> >> + pixel data transmission between host and flat panel display over LVDS
> >> (Low
> >> + Voltage Differential Sampling) interface. The OLDI TX consists of
> >> 7-to-1 data
> >> + serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS
> >> output
> >> + formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB
> >> or
> >> + padded and un-padded 18-bit RGB bus formats as input.
> >> +
> >> +properties:
> >> + reg:
> >> +maxItems: 1
> >> +
> >> + clocks:
> >> +maxItems: 1
> >> +description: serial clock input for the OLDI transmitters
> >> +
> >> + clock-names:
> >> +const: s_clk
> >> +
> >> + ti,companion-oldi:
> >> +$ref: /schemas/types.yaml#/definitions/phandle
> >> +description:
> >> + phandle to companion OLDI transmitter. This property is mandatory
> >> for the
> >> + primarty OLDI TX if the OLDI TXes are expected to work either in
> >> dual-lvds
> >> + mode or in clone mode. This property should point to the secondary
> >> OLDI
> >> + TX.
> >> +
> >> + ti,secondary-oldi:
> >> +type: boolean
> >> +description: Boolean property to mark an OLDI TX as secondary node.
> >> +
> >> + ti,oldi-io-ctrl:
> >> +$ref: /schemas/types.yaml#/definitions/phandle
> >> +description:
> >> + phandle to syscon device node mapping OLDI IO_CTRL registers found
> >> in the
> >> + control MMR region. This property is needed for OLDI interface to
> >> work.
> >> +
> >> + ports:
> >> +$ref: /schemas/graph.yaml#/properties/ports
> >> +
> >> +properties:
> >> + port@0:
> >> +$ref: /schemas/graph.yaml#/properties/port
> >> +description: Parallel RGB input port
> >> +
> >> + port@1:
> >> +$ref: /schemas/graph.yaml#/properties/port
> >> +description: LVDS output port
> >> +
> >> +required:
> >> + - port@0
> >> + - port@1
> >> +
> >> +allOf:
> >> + - if:
> >> + properties:
> >> +ti,secondary-oldi: true
> >> +then:
> >> + properties:
> >> +ti,companion-oldi: false
> >> +ti,oldi-io-ctrl: false
> >> +clocks: false
> >> +clock-names: false
> >> +
> >> +else:
> >> + required:
> >> +- ti,oldi-io-ctrl
> >> +- clocks
> >> +- clock-names
> >> +
> >> +required:
> >> + - reg
> >> + - ports
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> + - |
> >> +#include
> >> +
> >> +oldi_txes {
> >> +#address-cells = <1>;
> >> +#size-cells = <0>;
> >> +oldi: oldi@0 {
> >> +reg = <0>;
> >> +clocks = <_clks 186 0>;
> >> +clock-names = "s_clk";
> >> +ti,oldi-io-ctrl = <_oldi_io_ctrl>;
> >
> > What bus does this device live on ? Couldn't the I/O register space be
> > referenced by the reg property ?.
> >
>
> These registers are a part of the system-controller register space
> (ctrl_mmr0). The whole register set is owned by the main_conf[0]
> devicetree node, with sub-nodes pointing to specific regions. That's why
> I cannot reference these registers directly.
Then what does 'reg' represent? Looks like you just made up an index. If
so, then this should probably be a child of _oldi_io_ctrl instead.
Or it should just be merged into that node.
Rob
Re: [PATCH 1/4] dt-bindings: display: ti,am65x-dss: Minor Cleanup
On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote: > Reduce tab size from 8 spaces to 4 spaces to make the bindings > consistent, and easy to expand. "Re-indent the example" would be more specific than "minor cleanups" in the subject. Otherwise, Acked-by: Rob Herring (Arm) > > Signed-off-by: Aradhya Bhatia > --- > .../bindings/display/ti/ti,am65x-dss.yaml | 54 +-- > 1 file changed, 27 insertions(+), 27 deletions(-)
Re: [PATCH v2] drm/amd/display: fix documentation warnings for mpc.h
On Sat, May 11, 2024 at 12:22 AM Stephen Rothwell wrote:
>
> Hi Marcelo,
>
> On Sat, 11 May 2024 13:37:17 +1000 Stephen Rothwell
> wrote:
> >
> > Thanks for doing this.
> >
> > I haven't tested it, but just a couple of little things:
> >
> > On Fri, 10 May 2024 21:02:02 -0300 Marcelo Mendes Spessoto Junior
> > wrote:
> > >
> > > Fix most of the display documentation compile warnings by
> > > documenting struct mpc_funcs functions in dc/inc/hw/mpc.h file.
> > >
> > .
> > .
> > .
> > >
> > > Fixes:
> > > b8c1c3a82e75 ("Documentation/gpu: Add kernel doc entry for MPC")
> >
> > Please don't split the Fixes tag line and also don't add blank lines
> > between tags.
> >
> > I also appreciate being credited for reporting (unless you got a report
> > from somewhere else as well, then maybe credit both).
> >
> > Reported-by: Stephen Rothwell
>
> Now tested.
>
> Tested-by: Stephen Rothwell
> Closes:
> https://lore.kernel.org/linux-next/20240130134954.04fcf...@canb.auug.org.au/
Applied and added/fixed up tags.
Thanks!
Alex
>
> --
> Cheers,
> Stephen Rothwell
[PATCH 9/9] drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff
From: Ville Syrjälä
I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")
Bspec had the same exact thing to say about earlier hardware
as well, but we never cared and things work just fine.
The one thing mentioned in that commit that is definitely
true however is the fence alignment issue. But we don't
deal with that on earlier hardware either. We do have code
to deal with that issue for the first color plane, but not
the chroma planes. So I think if we did want to check this
more extensively we should do it in the same places where
we already check the first color plane (namely
convert_plane_offset_to_xy() and intel_fb_bo_framebuffer_init()).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c| 12 +---
drivers/gpu/drm/i915/display/intel_fb.h| 1 -
drivers/gpu/drm/i915/display/skl_universal_plane.c | 11 ---
3 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index c80f866f3fb6..fc18da3106fd 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -584,12 +584,6 @@ static bool is_gen12_ccs_cc_plane(const struct
drm_framebuffer *fb, int color_pl
return intel_fb_rc_ccs_cc_plane(fb) == color_plane;
}
-bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane)
-{
- return intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) &&
- color_plane == 1;
-}
-
bool is_surface_linear(const struct drm_framebuffer *fb, int color_plane)
{
return fb->modifier == DRM_FORMAT_MOD_LINEAR ||
@@ -1019,11 +1013,7 @@ static int intel_fb_offset_to_xy(int *x, int *y,
struct drm_i915_private *i915 = to_i915(fb->dev);
unsigned int height, alignment, unused;
- if (DISPLAY_VER(i915) >= 12 &&
- !intel_fb_needs_pot_stride_remap(to_intel_framebuffer(fb)) &&
- is_semiplanar_uv_plane(fb, color_plane))
- alignment = intel_tile_row_size(fb, color_plane);
- else if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
+ if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
alignment = intel_tile_size(i915);
else
alignment = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index 1b1fef2dc39a..6dee0c8b7f22 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -34,7 +34,6 @@ bool intel_fb_is_ccs_modifier(u64 modifier);
bool intel_fb_is_rc_ccs_cc_modifier(u64 modifier);
bool intel_fb_is_mc_ccs_modifier(u64 modifier);
-bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane);
bool intel_fb_is_ccs_aux_plane(const struct drm_framebuffer *fb, int
color_plane);
int intel_fb_rc_ccs_cc_plane(const struct drm_framebuffer *fb);
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index ca7fc9fae990..476f5b7d9497 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -514,17 +514,6 @@ static u32 tgl_plane_min_alignment(struct intel_plane
*plane,
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return mult * 4 * 1024;
- if (is_semiplanar_uv_plane(fb, color_plane)) {
- /*
-* TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
-* alignment for linear UV planes on all platforms.
-*/
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 256 * 1024;
-
- return intel_tile_row_size(fb, color_plane);
- }
-
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
--
2.43.2
[PATCH 8/9] drm/i915: Update plane alignment requirements for TGL+
From: Ville Syrjälä
Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/skl_universal_plane.c| 103 ++
1 file changed, 55 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 1ecd7c691317..ca7fc9fae990 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -502,75 +502,79 @@ skl_plane_max_stride(struct intel_plane *plane,
max_pixels, max_bytes);
}
-static unsigned int skl_plane_min_alignment(struct intel_plane *plane,
- const struct drm_framebuffer *fb,
- int color_plane)
+static u32 tgl_plane_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
{
- struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-
- if (intel_fb_uses_dpt(fb)) {
- /* AUX_DIST needs only 4K alignment */
- if (intel_fb_is_ccs_aux_plane(fb, color_plane))
- return 512 * 4096;
-
- /*
-* FIXME ADL sees GGTT/DMAR faults with async
-* flips unless we align to 16k at least.
-* Figure out what's going on here...
-*/
- if (IS_ALDERLAKE_P(dev_priv) &&
- !intel_fb_is_ccs_modifier(fb->modifier) &&
- HAS_ASYNC_FLIPS(dev_priv))
- return 512 * 16 * 1024;
-
- return 512 * 4096;
- }
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ /* PLANE_SURF GGTT -> DPT alignment */
+ int mult = intel_fb_uses_dpt(fb) ? 512 : 1;
/* AUX_DIST needs only 4K alignment */
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
- return 4096;
+ return mult * 4 * 1024;
if (is_semiplanar_uv_plane(fb, color_plane)) {
/*
* TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
* alignment for linear UV planes on all platforms.
*/
- if (DISPLAY_VER(dev_priv) >= 12) {
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 256 * 1024;
-
- return intel_tile_row_size(fb, color_plane);
- }
-
- return 4096;
- }
-
- drm_WARN_ON(_priv->drm, color_plane != 0);
-
- switch (fb->modifier) {
- case DRM_FORMAT_MOD_LINEAR:
- return 256 * 1024;
- case I915_FORMAT_MOD_X_TILED:
- if (HAS_ASYNC_FLIPS(dev_priv))
+ if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
return 256 * 1024;
- return 0;
+
+ return intel_tile_row_size(fb, color_plane);
+ }
+
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_4_TILED:
+ /*
+* FIXME ADL sees GGTT/DMAR faults with async
+* flips unless we align to 16k at least.
+* Figure out what's going on here...
+*/
+ if (IS_ALDERLAKE_P(i915) && HAS_ASYNC_FLIPS(i915))
+ return mult * 16 * 1024;
+ return mult * 4 * 1024;
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
- return 16 * 1024;
+ /* 4x1 main surface tiles (16K) match 64B of AUX */
+ return max(mult * 4 * 1024, 16 * 1024);
+ default:
+ MISSING_CASE(fb->modifier);
+ return 0;
+ }
+}
+
+static u32 skl_plane_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ /*
+* AUX_DIST needs only 4K alignment,
+* as does ICL UV PLANE_SURF.
+*/
+ if (color_plane != 0)
+ return 4 * 1024;
+
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case
[PATCH 7/9] drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c
From: Ville Syrjälä
Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 77 +--
drivers/gpu/drm/i915/display/intel_fb.h | 4 +-
.../drm/i915/display/skl_universal_plane.c| 77 ++-
3 files changed, 78 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index eea93d84a16e..c80f866f3fb6 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -584,7 +584,7 @@ static bool is_gen12_ccs_cc_plane(const struct
drm_framebuffer *fb, int color_pl
return intel_fb_rc_ccs_cc_plane(fb) == color_plane;
}
-static bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int
color_plane)
+bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane)
{
return intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) &&
color_plane == 1;
@@ -776,81 +776,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
}
-unsigned int intel_surf_alignment(struct intel_plane *plane,
- const struct drm_framebuffer *fb,
- int color_plane)
-{
- struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-
- if (intel_fb_uses_dpt(fb)) {
- /* AUX_DIST needs only 4K alignment */
- if (intel_fb_is_ccs_aux_plane(fb, color_plane))
- return 512 * 4096;
-
- /*
-* FIXME ADL sees GGTT/DMAR faults with async
-* flips unless we align to 16k at least.
-* Figure out what's going on here...
-*/
- if (IS_ALDERLAKE_P(dev_priv) &&
- !intel_fb_is_ccs_modifier(fb->modifier) &&
- HAS_ASYNC_FLIPS(dev_priv))
- return 512 * 16 * 1024;
-
- return 512 * 4096;
- }
-
- /* AUX_DIST needs only 4K alignment */
- if (intel_fb_is_ccs_aux_plane(fb, color_plane))
- return 4096;
-
- if (is_semiplanar_uv_plane(fb, color_plane)) {
- /*
-* TODO: cross-check wrt. the bspec stride in bytes * 64 bytes
-* alignment for linear UV planes on all platforms.
-*/
- if (DISPLAY_VER(dev_priv) >= 12) {
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 256 * 1024;
-
- return intel_tile_row_size(fb, color_plane);
- }
-
- return 4096;
- }
-
- drm_WARN_ON(_priv->drm, color_plane != 0);
-
- switch (fb->modifier) {
- case DRM_FORMAT_MOD_LINEAR:
- return 256 * 1024;
- case I915_FORMAT_MOD_X_TILED:
- if (HAS_ASYNC_FLIPS(dev_priv))
- return 256 * 1024;
- return 0;
- case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
- case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
- case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
- case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
- case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
- case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
- return 16 * 1024;
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- case I915_FORMAT_MOD_Y_TILED:
- case I915_FORMAT_MOD_4_TILED:
- case I915_FORMAT_MOD_Yf_TILED:
- return 1 * 1024 * 1024;
- case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
- case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
- case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
- return 16 * 1024;
- default:
- MISSING_CASE(fb->modifier);
- return 0;
- }
-}
-
void intel_fb_plane_get_subsampling(int *hsub, int *vsub,
const struct drm_framebuffer *fb,
int color_plane)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index 16ebb573643f..1b1fef2dc39a 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -34,6 +34,7 @@ bool intel_fb_is_ccs_modifier(u64 modifier);
bool intel_fb_is_rc_ccs_cc_modifier(u64 modifier);
bool intel_fb_is_mc_ccs_modifier(u64 modifier);
+bool is_semiplanar_uv_plane(const struct drm_framebuffer *fb, int color_plane);
bool intel_fb_is_ccs_aux_plane(const struct drm_framebuffer *fb, int
color_plane);
int intel_fb_rc_ccs_cc_plane(const struct drm_framebuffer *fb);
@@ -60,9 +61,6 @@ unsigned int intel_tile_height(const struct drm_framebuffer
[PATCH 6/9] drm/i915: Split pre-skl platforms out from intel_surf_alignment()
From: Ville Syrjälä
Extract the necessary chunks from intel_surf_alignment()
into per-platform variants for all pre-skl primary/sprite
planes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 69 -
drivers/gpu/drm/i915/display/intel_fb.c | 17 +
drivers/gpu/drm/i915/display/intel_sprite.c | 28 -
3 files changed, 96 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 85dbf5b950e2..0d64176c1e6f 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -762,6 +762,66 @@ i8xx_plane_max_stride(struct intel_plane *plane,
return 8 * 1024;
}
+static unsigned int vlv_primary_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ switch (fb->modifier) {
+ case I915_FORMAT_MOD_X_TILED:
+ if (HAS_ASYNC_FLIPS(i915))
+ return 256 * 1024;
+ return 4 * 1024;
+ case DRM_FORMAT_MOD_LINEAR:
+ return 128 * 1024;
+ default:
+ MISSING_CASE(fb->modifier);
+ return 0;
+ }
+}
+
+static unsigned int g4x_primary_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ switch (fb->modifier) {
+ case I915_FORMAT_MOD_X_TILED:
+ if (HAS_ASYNC_FLIPS(i915))
+ return 256 * 1024;
+ return 4 * 1024;
+ case DRM_FORMAT_MOD_LINEAR:
+ return 4 * 1024;
+ default:
+ MISSING_CASE(fb->modifier);
+ return 0;
+ }
+}
+
+static unsigned int i965_plane_min_alignment(struct intel_plane *plane,
+const struct drm_framebuffer *fb,
+int color_plane)
+{
+ switch (fb->modifier) {
+ case I915_FORMAT_MOD_X_TILED:
+ return 4 * 1024;
+ case DRM_FORMAT_MOD_LINEAR:
+ return 128 * 1024;
+ default:
+ MISSING_CASE(fb->modifier);
+ return 0;
+ }
+}
+
+static unsigned int i9xx_plane_min_alignment(struct intel_plane *plane,
+const struct drm_framebuffer *fb,
+int color_plane)
+{
+ return 0;
+}
+
static const struct drm_plane_funcs i965_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -867,7 +927,14 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->max_stride = ilk_primary_max_stride;
}
- plane->min_alignment = intel_surf_alignment;
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ plane->min_alignment = vlv_primary_min_alignment;
+ else if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv))
+ plane->min_alignment = g4x_primary_min_alignment;
+ else if (DISPLAY_VER(dev_priv) == 4)
+ plane->min_alignment = i965_plane_min_alignment;
+ else
+ plane->min_alignment = i9xx_plane_min_alignment;
if (IS_I830(dev_priv) || IS_I845G(dev_priv)) {
plane->update_arm = i830_plane_update_arm;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index c84ecae3a57c..eea93d84a16e 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -776,19 +776,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
}
-static unsigned int intel_linear_alignment(const struct drm_i915_private
*dev_priv)
-{
- if (DISPLAY_VER(dev_priv) >= 9)
- return 256 * 1024;
- else if (IS_I965G(dev_priv) || IS_I965GM(dev_priv) ||
-IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- return 128 * 1024;
- else if (DISPLAY_VER(dev_priv) >= 4)
- return 4 * 1024;
- else
- return 0;
-}
-
unsigned int intel_surf_alignment(struct intel_plane *plane,
const struct drm_framebuffer *fb,
int color_plane)
@@ -824,7 +811,7 @@ unsigned int intel_surf_alignment(struct intel_plane *plane,
*/
if (DISPLAY_VER(dev_priv) >= 12) {
if (fb->modifier ==
[PATCH 4/9] drm/i915: Introduce fb->min_alignment
From: Ville Syrjälä
Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment used when pinning the normal ggtt
view is satisfactory to all those planes.
When pinning per-plane views we only have to satisfy the
alignment requirements of the specific plane.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 2 ++
drivers/gpu/drm/i915/display/intel_fb.c | 23
drivers/gpu/drm/i915/display/intel_fb_pin.c | 27 +--
drivers/gpu/drm/i915/display/intel_fbdev.c| 18 +
4 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 40d6e5f4c350..58bb65832adf 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -145,6 +145,8 @@ struct intel_framebuffer {
};
struct i915_address_space *dpt_vm;
+
+ unsigned int min_alignment;
};
enum intel_hotplug_state {
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 3f3a9cd534f4..c5bae05cbbc3 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -10,6 +10,7 @@
#include
#include "i915_drv.h"
+#include "intel_atomic_plane.h"
#include "intel_display.h"
#include "intel_display_types.h"
#include "intel_dpt.h"
@@ -1616,6 +1617,26 @@ bool intel_fb_supports_90_270_rotation(const struct
intel_framebuffer *fb)
fb->base.modifier == I915_FORMAT_MOD_Yf_TILED;
}
+static unsigned int intel_fb_min_alignment(const struct drm_framebuffer *fb)
+{
+ struct drm_i915_private *i915 = to_i915(fb->dev);
+ struct intel_plane *plane;
+ unsigned int min_alignment = 0;
+
+ for_each_intel_plane(>drm, plane) {
+ if (!drm_plane_has_format(>base, fb->format->format,
fb->modifier))
+ continue;
+
+ if (intel_plane_needs_physical(plane))
+ continue;
+
+ min_alignment = max(min_alignment,
+ plane->min_alignment(plane, fb, 0));
+ }
+
+ return min_alignment;
+}
+
int intel_fill_fb_info(struct drm_i915_private *i915, struct intel_framebuffer
*fb)
{
struct drm_i915_gem_object *obj = intel_fb_obj(>base);
@@ -1698,6 +1719,8 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
struct intel_framebuffer *
return -EINVAL;
}
+ fb->min_alignment = intel_fb_min_alignment(>base);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 9b0f1ea41b70..1ae02de906f5 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -230,13 +230,36 @@ void intel_fb_unpin_vma(struct i915_vma *vma, unsigned
long flags)
i915_vma_put(vma);
}
+static bool gtt_view_is_per_plane(const struct intel_plane_state *plane_state)
+{
+ const struct intel_framebuffer *fb =
to_intel_framebuffer(plane_state->hw.fb);
+
+ if (plane_state->view.gtt.type == I915_GTT_VIEW_REMAPPED &&
+ intel_fb_needs_pot_stride_remap(fb))
+ return false;
+
+ return plane_state->view.gtt.type != I915_GTT_VIEW_NORMAL;
+}
+
static unsigned int
intel_plane_fb_min_alignment(const struct intel_plane_state *plane_state)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
- const struct drm_framebuffer *fb = plane_state->hw.fb;
+ const struct intel_framebuffer *fb =
to_intel_framebuffer(plane_state->hw.fb);
- return plane->min_alignment(plane, fb, 0);
+ /*
+* Only use plane specific alignment for binding
+* a per-plane gtt view (remapped or rotated),
+* otherwise make sure the alignment is suitable
+* for all planes.
+*/
+ if (!gtt_view_is_per_plane(plane_state))
+ return fb->min_alignment;
+
+ if (intel_plane_needs_physical(plane))
+ return 0;
+
+ return plane->min_alignment(plane, >base, 0);
}
static unsigned int
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index ff685aebbd1a..124aac172acb 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -46,7 +46,6 @@
#include "gem/i915_gem_mman.h"
#include "i915_drv.h"
-#include "intel_crtc.h"
#include "intel_display_types.h"
#include "intel_fb.h"
#include "intel_fb_pin.h"
@@ -172,21 +171,6 @@ static const struct fb_ops intelfb_ops = {
__diag_pop();
-static unsigned int intel_fbdev_min_alignment(const struct drm_framebuffer *fb)
-{
-
[PATCH 3/9] drm/i915: Introduce plane->min_alignment() vfunc
From: Ville Syrjälä
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
For fbdev we (temporarily) introduce intel_fbdev_min_alignment()
that simply queries the alignment from the primary plane of
the first crtc.
TODO: someone will need to fix xe's alignment handling
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 8 ++--
drivers/gpu/drm/i915/display/intel_cursor.c | 2 +
.../drm/i915/display/intel_display_types.h| 3 ++
drivers/gpu/drm/i915/display/intel_fb.c | 22 +-
drivers/gpu/drm/i915/display/intel_fb.h | 7 +++-
drivers/gpu/drm/i915/display/intel_fb_pin.c | 40 ++-
drivers/gpu/drm/i915/display/intel_fb_pin.h | 3 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 21 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 2 +
.../drm/i915/display/skl_universal_plane.c| 11 +++--
drivers/gpu/drm/xe/display/xe_fb_pin.c| 3 +-
drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +-
12 files changed, 89 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index ea4d8ba55ad8..85dbf5b950e2 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -224,8 +224,8 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state
*crtc_state,
int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
{
- struct drm_i915_private *dev_priv =
- to_i915(plane_state->uapi.plane->dev);
+ struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
int src_x, src_y, src_w;
u32 offset;
@@ -266,7 +266,7 @@ int i9xx_check_plane_surface(struct intel_plane_state
*plane_state)
* despite them not using the linear offset anymore.
*/
if (DISPLAY_VER(dev_priv) >= 4 && fb->modifier ==
I915_FORMAT_MOD_X_TILED) {
- unsigned int alignment = intel_surf_alignment(fb, 0);
+ unsigned int alignment = plane->min_alignment(plane, fb, 0);
int cpp = fb->format->cpp[0];
while ((src_x + src_w) * cpp >
plane_state->view.color_plane[0].mapping_stride) {
@@ -867,6 +867,8 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->max_stride = ilk_primary_max_stride;
}
+ plane->min_alignment = intel_surf_alignment;
+
if (IS_I830(dev_priv) || IS_I845G(dev_priv)) {
plane->update_arm = i830_plane_update_arm;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 2118b87ccb10..026975f569a7 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -896,6 +896,8 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
cursor->check_plane = i9xx_check_cursor;
}
+ cursor->min_alignment = intel_cursor_alignment;
+
cursor->cursor.base = ~0;
cursor->cursor.cntl = ~0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index fec3de25ea54..40d6e5f4c350 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1550,6 +1550,9 @@ struct intel_plane {
int (*max_height)(const struct drm_framebuffer *fb,
int color_plane,
unsigned int rotation);
+ unsigned int (*min_alignment)(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane);
unsigned int (*max_stride)(struct intel_plane *plane,
u32 pixel_format, u64 modifier,
unsigned int rotation);
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index b6638726949d..3f3a9cd534f4 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -775,8 +775,12 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
}
-unsigned int intel_cursor_alignment(const struct drm_i915_private *i915)
+unsigned int intel_cursor_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
{
+ struct
[PATCH 5/9] drm/i915: Split cursor alignment to per-platform vfuncs
From: Ville Syrjälä
Split intel_cursor_alignment() into per-platform variants.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 40 +++--
drivers/gpu/drm/i915/display/intel_fb.c | 16 -
drivers/gpu/drm/i915/display/intel_fb.h | 3 --
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 026975f569a7..737d53c50901 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -193,6 +193,13 @@ i845_cursor_max_stride(struct intel_plane *plane,
return 2048;
}
+static unsigned int i845_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ return 32;
+}
+
static u32 i845_cursor_ctl_crtc(const struct intel_crtc_state *crtc_state)
{
u32 cntl = 0;
@@ -343,6 +350,28 @@ i9xx_cursor_max_stride(struct intel_plane *plane,
return plane->base.dev->mode_config.cursor_width * 4;
}
+static unsigned int i830_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ /* "AlmadorM Errata – Requires 32-bpp cursor data to be 16KB aligned."
*/
+ return 16 * 1024; /* physical */
+}
+
+static unsigned int i85x_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ return 256; /* physical */
+}
+
+static unsigned int i9xx_cursor_min_alignment(struct intel_plane *plane,
+ const struct drm_framebuffer *fb,
+ int color_plane)
+{
+ return 4 * 1024; /* physical for i915/i945 */
+}
+
static u32 i9xx_cursor_ctl_crtc(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -884,20 +913,27 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
cursor->max_stride = i845_cursor_max_stride;
+ cursor->min_alignment = i845_cursor_min_alignment;
cursor->update_arm = i845_cursor_update_arm;
cursor->disable_arm = i845_cursor_disable_arm;
cursor->get_hw_state = i845_cursor_get_hw_state;
cursor->check_plane = i845_check_cursor;
} else {
cursor->max_stride = i9xx_cursor_max_stride;
+
+ if (IS_I830(dev_priv))
+ cursor->min_alignment = i830_cursor_min_alignment;
+ else if (IS_I85X(dev_priv))
+ cursor->min_alignment = i85x_cursor_min_alignment;
+ else
+ cursor->min_alignment = i9xx_cursor_min_alignment;
+
cursor->update_arm = i9xx_cursor_update_arm;
cursor->disable_arm = i9xx_cursor_disable_arm;
cursor->get_hw_state = i9xx_cursor_get_hw_state;
cursor->check_plane = i9xx_check_cursor;
}
- cursor->min_alignment = intel_cursor_alignment;
-
cursor->cursor.base = ~0;
cursor->cursor.cntl = ~0;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index c5bae05cbbc3..c84ecae3a57c 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -776,22 +776,6 @@ bool intel_fb_uses_dpt(const struct drm_framebuffer *fb)
intel_fb_modifier_uses_dpt(to_i915(fb->dev), fb->modifier);
}
-unsigned int intel_cursor_alignment(struct intel_plane *plane,
- const struct drm_framebuffer *fb,
- int color_plane)
-{
- struct drm_i915_private *i915 = to_i915(plane->base.dev);
-
- if (IS_I830(i915))
- return 16 * 1024;
- else if (IS_I85X(i915))
- return 256;
- else if (IS_I845G(i915) || IS_I865G(i915))
- return 32;
- else
- return 4 * 1024;
-}
-
static unsigned int intel_linear_alignment(const struct drm_i915_private
*dev_priv)
{
if (DISPLAY_VER(dev_priv) >= 9)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index 86c01a3ce81e..16ebb573643f 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -60,9 +60,6 @@ unsigned int intel_tile_height(const struct drm_framebuffer
*fb, int color_plane
unsigned int intel_tile_row_size(const struct drm_framebuffer *fb, int
color_plane);
unsigned int
[PATCH 2/9] drm: Export drm_plane_has_format()
From: Ville Syrjälä Export drm_plane_has_format() so that drivers can use it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_crtc_internal.h | 2 -- drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_plane.h | 2 ++ 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_internal.h b/drivers/gpu/drm/drm_crtc_internal.h index 898e0e8b51be..e207759ca045 100644 --- a/drivers/gpu/drm/drm_crtc_internal.h +++ b/drivers/gpu/drm/drm_crtc_internal.h @@ -272,8 +272,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev, /* drm_plane.c */ int drm_plane_register_all(struct drm_device *dev); void drm_plane_unregister_all(struct drm_device *dev); -bool drm_plane_has_format(struct drm_plane *plane, - u32 format, u64 modifier); struct drm_mode_rect * __drm_plane_get_damage_clips(const struct drm_plane_state *state); diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 268aa2299df5..a51d4dd3f7de 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -906,6 +906,7 @@ bool drm_plane_has_format(struct drm_plane *plane, return true; } +EXPORT_SYMBOL(drm_plane_has_format); static int __setplane_check(struct drm_plane *plane, struct drm_crtc *crtc, diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 9507542121fa..dd718c62ac31 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -972,6 +972,8 @@ static inline struct drm_plane *drm_plane_find(struct drm_device *dev, #define drm_for_each_plane(plane, dev) \ list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) +bool drm_plane_has_format(struct drm_plane *plane, + u32 format, u64 modifier); bool drm_any_plane_has_format(struct drm_device *dev, u32 format, u64 modifier); -- 2.43.2
[PATCH 1/9] drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()
From: Ville Syrjälä
Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.
Also matches drm_any_plane_has_format() better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 7 ++-
drivers/gpu/drm/drm_crtc.c | 6 ++
drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
drivers/gpu/drm/drm_plane.c | 22 ++
4 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a91737adf8e7..e22560213b8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -608,7 +608,6 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
unsigned int fb_width, fb_height;
struct drm_mode_rect *clips;
uint32_t num_clips;
- int ret;
/* either *both* CRTC and FB must be set, or neither */
if (crtc && !fb) {
@@ -635,14 +634,12 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
}
/* Check whether this plane supports the fb pixel format. */
- ret = drm_plane_check_pixel_format(plane, fb->format->format,
- fb->modifier);
- if (ret) {
+ if (!drm_plane_has_format(plane, fb->format->format, fb->modifier)) {
drm_dbg_atomic(plane->dev,
"[PLANE:%d:%s] invalid pixel format %p4cc,
modifier 0x%llx\n",
plane->base.id, plane->name,
>format->format, fb->modifier);
- return ret;
+ return -EINVAL;
}
/* Give drivers some help against integer overflows */
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 483969b84a30..3488ff067c69 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -789,12 +789,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
* case.
*/
if (!plane->format_default) {
- ret = drm_plane_check_pixel_format(plane,
- fb->format->format,
- fb->modifier);
- if (ret) {
+ if (!drm_plane_has_format(plane, fb->format->format,
fb->modifier)) {
drm_dbg_kms(dev, "Invalid pixel format %p4cc,
modifier 0x%llx\n",
>format->format, fb->modifier);
+ ret = -EINVAL;
goto out;
}
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 25aaae937ceb..898e0e8b51be 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -272,8 +272,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* drm_plane.c */
int drm_plane_register_all(struct drm_device *dev);
void drm_plane_unregister_all(struct drm_device *dev);
-int drm_plane_check_pixel_format(struct drm_plane *plane,
-u32 format, u64 modifier);
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier);
struct drm_mode_rect *
__drm_plane_get_damage_clips(const struct drm_plane_state *state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 57662a1fd345..268aa2299df5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -877,8 +877,8 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
return 0;
}
-int drm_plane_check_pixel_format(struct drm_plane *plane,
-u32 format, u64 modifier)
+bool drm_plane_has_format(struct drm_plane *plane,
+ u32 format, u64 modifier)
{
unsigned int i;
@@ -887,24 +887,24 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
break;
}
if (i == plane->format_count)
- return -EINVAL;
+ return false;
if (plane->funcs->format_mod_supported) {
if (!plane->funcs->format_mod_supported(plane, format,
modifier))
- return -EINVAL;
+ return false;
} else {
if (!plane->modifier_count)
- return 0;
+ return true;
for (i = 0; i < plane->modifier_count; i++) {
if (modifier == plane->modifiers[i])
break;
}
if (i == plane->modifier_count)
- return -EINVAL;
+ return false;
}
- return 0;
+
[PATCH 0/9] drm/i915: Polish plane surface alignment handling
From: Ville Syrjälä intel_surf_alignment() in particular has devolved into a complete mess. Redesign the code so that we can handle alignment restrictions in a nicer. Also adjust alignment for TGL+ to actually match the hardware requirements. Ville Syrjälä (9): drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format() drm: Export drm_plane_has_format() drm/i915: Introduce plane->min_alignment() vfunc drm/i915: Introduce fb->min_alignment drm/i915: Split cursor alignment to per-platform vfuncs drm/i915: Split pre-skl platforms out from intel_surf_alignment() drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c drm/i915: Update plane alignment requirements for TGL+ drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff drivers/gpu/drm/drm_atomic.c | 7 +- drivers/gpu/drm/drm_crtc.c| 6 +- drivers/gpu/drm/drm_crtc_internal.h | 2 - drivers/gpu/drm/drm_plane.c | 23 ++- drivers/gpu/drm/i915/display/i9xx_plane.c | 75 - drivers/gpu/drm/i915/display/intel_cursor.c | 38 + .../drm/i915/display/intel_display_types.h| 5 + drivers/gpu/drm/i915/display/intel_fb.c | 145 -- drivers/gpu/drm/i915/display/intel_fb.h | 3 - drivers/gpu/drm/i915/display/intel_fb_pin.c | 63 ++-- drivers/gpu/drm/i915/display/intel_fb_pin.h | 3 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 5 +- drivers/gpu/drm/i915/display/intel_sprite.c | 26 .../drm/i915/display/skl_universal_plane.c| 82 +- drivers/gpu/drm/xe/display/xe_fb_pin.c| 3 +- drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +- include/drm/drm_plane.h | 2 + 17 files changed, 324 insertions(+), 168 deletions(-) -- 2.43.2
Re: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no display issue
On Mon, May 13, 2024 at 7:42 PM Robert Foss wrote:
>
> On Mon, May 6, 2024 at 11:36 AM kuro wrote:
> >
> > From: Kuro
> >
> > ITE added a FIFO reset bit for input video. When system power resume,
> > the TTL input of it6505 may get some noise before video signal stable
> > and the hardware function reset is required.
> > But the input FIFO reset will also trigger error interrupts of output
> > module rising.
> > Thus, it6505 have to wait a period can clear those expected error interrupts
> > caused by manual hardware reset in one interrupt handler calling to avoid
> > interrupt looping.
> >
> > Signed-off-by: Kuro Chung
> >
> > ---
> > drivers/gpu/drm/bridge/ite-it6505.c | 73 +++--
> > 1 file changed, 49 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> > b/drivers/gpu/drm/bridge/ite-it6505.c
> > index b53da9bb65a16..64e2706e3d0c3 100644
> > --- a/drivers/gpu/drm/bridge/ite-it6505.c
> > +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> > @@ -1317,9 +1317,15 @@ static void it6505_video_reset(struct it6505 *it6505)
> > it6505_link_reset_step_train(it6505);
> > it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE,
> > EN_VID_MUTE);
> > it6505_set_bits(it6505, REG_INFOFRAME_CTRL, EN_VID_CTRL_PKT, 0x00);
> > - it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > +
> > + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
> > TX_FIFO_RESET);
> > + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x00);
> > +
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO,
> > RST_501_FIFO);
> > it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, 0x00);
> > +
> > + it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> > + usleep_range(1000, 2000);
> > it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, 0x00);
> > }
> >
> > @@ -2249,12 +2255,11 @@ static void it6505_link_training_work(struct
> > work_struct *work)
> > if (ret) {
> > it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > it6505_link_train_ok(it6505);
> > - return;
> > } else {
> > it6505->auto_train_retry--;
> > + it6505_dump(it6505);
> > }
> >
> > - it6505_dump(it6505);
> > }
> >
> > static void it6505_plugged_status_to_codec(struct it6505 *it6505)
> > @@ -2475,31 +2480,53 @@ static void it6505_irq_link_train_fail(struct
> > it6505 *it6505)
> > schedule_work(>link_works);
> > }
> >
> > -static void it6505_irq_video_fifo_error(struct it6505 *it6505)
> > +static bool it6505_test_bit(unsigned int bit, const unsigned int *addr)
> > {
> > - struct device *dev = >client->dev;
> > -
> > - DRM_DEV_DEBUG_DRIVER(dev, "video fifo overflow interrupt");
> > - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > - flush_work(>link_works);
> > - it6505_stop_hdcp(it6505);
> > - it6505_video_reset(it6505);
> > + return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> > }
> >
> > -static void it6505_irq_io_latch_fifo_overflow(struct it6505 *it6505)
> > +static void it6505_irq_video_handler(struct it6505 *it6505, const int
> > *int_status)
> > {
> > struct device *dev = >client->dev;
> > + int reg_0d, reg_int03;
> >
> > - DRM_DEV_DEBUG_DRIVER(dev, "IO latch fifo overflow interrupt");
> > - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > - flush_work(>link_works);
> > - it6505_stop_hdcp(it6505);
> > - it6505_video_reset(it6505);
> > -}
> > + /*
> > +* When video SCDT change with video not stable,
> > +* Or video FIFO error, need video reset
> > +*/
> >
> > -static bool it6505_test_bit(unsigned int bit, const unsigned int *addr)
> > -{
> > - return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> > + if ((!it6505_get_video_status(it6505) &&
> > + (it6505_test_bit(INT_SCDT_CHANGE, (unsigned int *)
> > int_status))) ||
> > + (it6505_test_bit(BIT_INT_IO_FIFO_OVERFLOW, (unsigned int *)
> > int_status)) ||
> > + (it6505_test_bit(BIT_INT_VID_FIFO_ERROR, (unsigned int *)
> > int_status))) {
> > +
> > + it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> > + flush_work(>link_works);
> > + it6505_stop_hdcp(it6505);
> > + it6505_video_reset(it6505);
> > +
> > + usleep_range(1, 11000);
> > +
> > + /*
> > +* Clear FIFO error IRQ to prevent fifo error -> reset loop
> > +* HW will trigger SCDT change IRQ again when video stable
> > +*/
> > +
> > + reg_int03 = it6505_read(it6505, INT_STATUS_03);
> > + reg_0d = it6505_read(it6505, REG_SYSTEM_STS);
> > +
> > + reg_int03 &= (BIT(INT_VID_FIFO_ERROR) |
> >
Re: [PATCH v7 1/1] drm/bridge: it6505: fix hibernate to resume no display issue
On Mon, May 6, 2024 at 11:36 AM kuro wrote:
>
> From: Kuro
>
> ITE added a FIFO reset bit for input video. When system power resume,
> the TTL input of it6505 may get some noise before video signal stable
> and the hardware function reset is required.
> But the input FIFO reset will also trigger error interrupts of output module
> rising.
> Thus, it6505 have to wait a period can clear those expected error interrupts
> caused by manual hardware reset in one interrupt handler calling to avoid
> interrupt looping.
>
> Signed-off-by: Kuro Chung
>
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 73 +++--
> 1 file changed, 49 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> b/drivers/gpu/drm/bridge/ite-it6505.c
> index b53da9bb65a16..64e2706e3d0c3 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -1317,9 +1317,15 @@ static void it6505_video_reset(struct it6505 *it6505)
> it6505_link_reset_step_train(it6505);
> it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE, EN_VID_MUTE);
> it6505_set_bits(it6505, REG_INFOFRAME_CTRL, EN_VID_CTRL_PKT, 0x00);
> - it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> +
> + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
> TX_FIFO_RESET);
> + it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x00);
> +
> it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO,
> RST_501_FIFO);
> it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, 0x00);
> +
> + it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
> + usleep_range(1000, 2000);
> it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, 0x00);
> }
>
> @@ -2249,12 +2255,11 @@ static void it6505_link_training_work(struct
> work_struct *work)
> if (ret) {
> it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> it6505_link_train_ok(it6505);
> - return;
> } else {
> it6505->auto_train_retry--;
> + it6505_dump(it6505);
> }
>
> - it6505_dump(it6505);
> }
>
> static void it6505_plugged_status_to_codec(struct it6505 *it6505)
> @@ -2475,31 +2480,53 @@ static void it6505_irq_link_train_fail(struct it6505
> *it6505)
> schedule_work(>link_works);
> }
>
> -static void it6505_irq_video_fifo_error(struct it6505 *it6505)
> +static bool it6505_test_bit(unsigned int bit, const unsigned int *addr)
> {
> - struct device *dev = >client->dev;
> -
> - DRM_DEV_DEBUG_DRIVER(dev, "video fifo overflow interrupt");
> - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> - flush_work(>link_works);
> - it6505_stop_hdcp(it6505);
> - it6505_video_reset(it6505);
> + return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> }
>
> -static void it6505_irq_io_latch_fifo_overflow(struct it6505 *it6505)
> +static void it6505_irq_video_handler(struct it6505 *it6505, const int
> *int_status)
> {
> struct device *dev = >client->dev;
> + int reg_0d, reg_int03;
>
> - DRM_DEV_DEBUG_DRIVER(dev, "IO latch fifo overflow interrupt");
> - it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> - flush_work(>link_works);
> - it6505_stop_hdcp(it6505);
> - it6505_video_reset(it6505);
> -}
> + /*
> +* When video SCDT change with video not stable,
> +* Or video FIFO error, need video reset
> +*/
>
> -static bool it6505_test_bit(unsigned int bit, const unsigned int *addr)
> -{
> - return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
> + if ((!it6505_get_video_status(it6505) &&
> + (it6505_test_bit(INT_SCDT_CHANGE, (unsigned int *)
> int_status))) ||
> + (it6505_test_bit(BIT_INT_IO_FIFO_OVERFLOW, (unsigned int *)
> int_status)) ||
> + (it6505_test_bit(BIT_INT_VID_FIFO_ERROR, (unsigned int *)
> int_status))) {
> +
> + it6505->auto_train_retry = AUTO_TRAIN_RETRY;
> + flush_work(>link_works);
> + it6505_stop_hdcp(it6505);
> + it6505_video_reset(it6505);
> +
> + usleep_range(1, 11000);
> +
> + /*
> +* Clear FIFO error IRQ to prevent fifo error -> reset loop
> +* HW will trigger SCDT change IRQ again when video stable
> +*/
> +
> + reg_int03 = it6505_read(it6505, INT_STATUS_03);
> + reg_0d = it6505_read(it6505, REG_SYSTEM_STS);
> +
> + reg_int03 &= (BIT(INT_VID_FIFO_ERROR) |
> BIT(INT_IO_LATCH_FIFO_OVERFLOW));
> + it6505_write(it6505, INT_STATUS_03, reg_int03);
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "reg08 = 0x%02x", reg_int03);
> + DRM_DEV_DEBUG_DRIVER(dev, "reg0D = 0x%02x", reg_0d);
> +
> + return;
> + }
> +
> +
> + if
Re: [RESEND 0/6] drm: struct drm_edid conversions
On Fri, 10 May 2024 16:26:03 +0300, Jani Nikula wrote: > Resend of the remaining patches from [1]. > > BR, > Jani. > > [1] https://lore.kernel.org/r/cover.1713273659.git.jani.nik...@intel.com > > [...] Fixed checkpatch issue in "drm/bochs: switch to struct drm_edid" Applied, thanks! [1/6] drm/bridge/analogix/anx6345: switch to struct drm_edid https://cgit.freedesktop.org/drm/drm-misc/commit/?id=37f3821c7cc8 [2/6] drm/bridge/analogix/anx78xx: switch to struct drm_edid https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8aa8781ba3c1 [3/6] drm/bridge: anx7625: use struct drm_edid more https://cgit.freedesktop.org/drm/drm-misc/commit/?id=7c585f9a71aa [4/6] drm/i2c: tda998x: switch to struct drm_edid https://cgit.freedesktop.org/drm/drm-misc/commit/?id=78e90e003b96 [5/6] drm/bochs: switch to struct drm_edid https://cgit.freedesktop.org/drm/drm-misc/commit/?id=5c465601d423 [6/6] drm/virtio: switch to struct drm_edid https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac15c653fb09 Rob
Re: [RESEND 3/6] drm/bridge: anx7625: use struct drm_edid more
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 26 +++
> drivers/gpu/drm/bridge/analogix/anx7625.h | 10 ++---
> 2 files changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 59e9ad349969..d19975c5e5e5 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -464,9 +464,11 @@ static int anx7625_odfc_config(struct anx7625_data *ctx,
> */
> static int anx7625_set_k_value(struct anx7625_data *ctx)
> {
> - struct edid *edid = (struct edid *)ctx->slimport_edid_p.edid_raw_data;
> + struct drm_edid_product_id id;
>
> - if (edid->mfg_id[0] == IVO_MID0 && edid->mfg_id[1] == IVO_MID1)
> + drm_edid_get_product_id(ctx->cached_drm_edid, );
> +
> + if (be16_to_cpu(id.manufacturer_name) == IVO_MID)
> return anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
> MIPI_DIGITAL_ADJ_1, 0x3B);
>
> @@ -1526,7 +1528,8 @@ static int anx7625_wait_hpd_asserted(struct drm_dp_aux
> *aux,
>
> static void anx7625_remove_edid(struct anx7625_data *ctx)
> {
> - ctx->slimport_edid_p.edid_block_num = -1;
> + drm_edid_free(ctx->cached_drm_edid);
> + ctx->cached_drm_edid = NULL;
> }
>
> static void anx7625_dp_adjust_swing(struct anx7625_data *ctx)
> @@ -1787,27 +1790,32 @@ static ssize_t anx7625_aux_transfer(struct drm_dp_aux
> *aux,
> static const struct drm_edid *anx7625_edid_read(struct anx7625_data *ctx)
> {
> struct device *dev = ctx->dev;
> - struct s_edid_data *p_edid = >slimport_edid_p;
> + u8 *edid_buf;
> int edid_num;
>
> - if (ctx->slimport_edid_p.edid_block_num > 0)
> + if (ctx->cached_drm_edid)
> goto out;
>
> + edid_buf = kmalloc(FOUR_BLOCK_SIZE, GFP_KERNEL);
> + if (!edid_buf)
> + return NULL;
> +
> pm_runtime_get_sync(dev);
> _anx7625_hpd_polling(ctx, 5000 * 100);
> - edid_num = sp_tx_edid_read(ctx, p_edid->edid_raw_data);
> + edid_num = sp_tx_edid_read(ctx, edid_buf);
> pm_runtime_put_sync(dev);
>
> if (edid_num < 1) {
> DRM_DEV_ERROR(dev, "Fail to read EDID: %d\n", edid_num);
> + kfree(edid_buf);
> return NULL;
> }
>
> - p_edid->edid_block_num = edid_num;
> + ctx->cached_drm_edid = drm_edid_alloc(edid_buf, FOUR_BLOCK_SIZE);
> + kfree(edid_buf);
>
> out:
> - return drm_edid_alloc(ctx->slimport_edid_p.edid_raw_data,
> - FOUR_BLOCK_SIZE);
> + return drm_edid_dup(ctx->cached_drm_edid);
> }
>
> static enum drm_connector_status anx7625_sink_detect(struct anx7625_data
> *ctx)
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> b/drivers/gpu/drm/bridge/analogix/anx7625.h
> index 39ed35d33836..eb5580f1ab2f 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> @@ -286,8 +286,7 @@
>
> #define MIPI_LANE_CTRL_10 0x0F
> #define MIPI_DIGITAL_ADJ_1 0x1B
> -#define IVO_MID0 0x26
> -#define IVO_MID1 0xCF
> +#define IVO_MID0x26CF
>
> #define MIPI_PLL_M_NUM_23_16 0x1E
> #define MIPI_PLL_M_NUM_15_80x1F
> @@ -417,11 +416,6 @@ enum audio_wd_len {
> #define EDID_TRY_CNT 3
> #define SUPPORT_PIXEL_CLOCK30
>
> -struct s_edid_data {
> - int edid_block_num;
> - u8 edid_raw_data[FOUR_BLOCK_SIZE];
> -};
> -
> /* Display End */
>
> #define MAX_LANES_SUPPORT 4
> @@ -466,7 +460,7 @@ struct anx7625_data {
> struct anx7625_i2c_client i2c;
> struct i2c_client *last_client;
> struct timer_list hdcp_timer;
> - struct s_edid_data slimport_edid_p;
> + const struct drm_edid *cached_drm_edid;
> struct device *codec_dev;
> hdmi_codec_plugged_cb plugged_cb;
> struct work_struct work;
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [RESEND 2/6] drm/bridge/analogix/anx78xx: switch to struct drm_edid
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> .../drm/bridge/analogix/analogix-anx78xx.c| 23 ++-
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 5748a8581af4..ae79bcd8fa55 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -67,7 +67,7 @@ struct anx78xx {
> struct drm_dp_aux aux;
> struct drm_bridge bridge;
> struct i2c_client *client;
> - struct edid *edid;
> + const struct drm_edid *drm_edid;
> struct drm_connector connector;
> struct anx78xx_platform_data pdata;
> struct mutex lock;
> @@ -830,8 +830,8 @@ static int anx78xx_get_modes(struct drm_connector
> *connector)
> if (WARN_ON(!anx78xx->powered))
> return 0;
>
> - if (anx78xx->edid)
> - return drm_add_edid_modes(connector, anx78xx->edid);
> + if (anx78xx->drm_edid)
> + return drm_edid_connector_add_modes(connector);
>
> mutex_lock(>lock);
>
> @@ -841,20 +841,21 @@ static int anx78xx_get_modes(struct drm_connector
> *connector)
> goto unlock;
> }
>
> - anx78xx->edid = drm_get_edid(connector, >aux.ddc);
> - if (!anx78xx->edid) {
> + anx78xx->drm_edid = drm_edid_read_ddc(connector, >aux.ddc);
> +
> + err = drm_edid_connector_update(connector, anx78xx->drm_edid);
> +
> + if (!anx78xx->drm_edid) {
> DRM_ERROR("Failed to read EDID\n");
> goto unlock;
> }
>
> - err = drm_connector_update_edid_property(connector,
> -anx78xx->edid);
> if (err) {
> DRM_ERROR("Failed to update EDID property: %d\n", err);
> goto unlock;
> }
>
> - num_modes = drm_add_edid_modes(connector, anx78xx->edid);
> + num_modes = drm_edid_connector_add_modes(connector);
>
> unlock:
> mutex_unlock(>lock);
> @@ -1091,8 +1092,8 @@ static bool anx78xx_handle_common_int_4(struct anx78xx
> *anx78xx, u8 irq)
> event = true;
> anx78xx_poweroff(anx78xx);
> /* Free cached EDID */
> - kfree(anx78xx->edid);
> - anx78xx->edid = NULL;
> + drm_edid_free(anx78xx->drm_edid);
> + anx78xx->drm_edid = NULL;
> } else if (irq & SP_HPD_PLUG) {
> DRM_DEBUG_KMS("IRQ: Hot plug detect - cable plug\n");
> event = true;
> @@ -1363,7 +1364,7 @@ static void anx78xx_i2c_remove(struct i2c_client
> *client)
>
> unregister_i2c_dummy_clients(anx78xx);
>
> - kfree(anx78xx->edid);
> + drm_edid_free(anx78xx->drm_edid);
> }
>
> static const struct of_device_id anx78xx_match_table[] = {
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: dma-buf sg mangling
Am 10.05.24 um 18:34 schrieb Zack Rusin:
Hey,
so this is a bit of a silly problem but I'd still like to solve it
properly. The tldr is that virtualized drivers abuse
drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
virtgpu and xen punt on it) because there doesn't seem to be a
universally supported way of converting the sg_table back to a list of
pages without some form of gart to do it.
Well the whole point is that you should never touch the pages in the
sg_table in the first place.
The long term plan is actually to completely remove the pages from that
interface.
drm_prime_sg_to_page_array is deprecated (for all the right reasons on
actual hardware) but in our cooky virtualized world we don't have
gart's so what are we supposed to do with the dma_addr_t from the
imported sg_table? What makes it worse (and definitely breaks xen) is
that with CONFIG_DMABUF_DEBUG the sg page_link is mangled via
mangle_sg_table so drm_prime_sg_to_page_array won't even work.
XEN and KVM were actually adjusted to not touch the struct pages any more.
I'm not sure if that work is already upstream or not but I had to
explain it over and over again why their approach doesn't work.
The reason why I'm saying it's a bit of a silly problem is that afaik
currently it only affects IGT testing with vgem (because the rest of
external gem objects will be from the virtualized gpu itself which is
different). But do you have any ideas on what we'd like to do with
this long term? i.e. we have a virtualized gpus without iommu, we have
sg_table with some memory and we'd like to import it. Do we just
assume that the sg_table on those configs will always reference cpu
accessible memory (i.e. if it's external it only comes through
drm_gem_shmem_object) and just do some horrific abomination like:
for (i = 0; i < bo->ttm->num_pages; ++i) {
phys_addr_t pa = dma_to_phys(vmw->drm.dev, bo->ttm->dma_address[i]);
pages[i] = pfn_to_page(PHYS_PFN(pa));
}
or add a "i know this is cpu accessible, please demangle" flag to
drm_prime_sg_to_page_array or try to have some kind of more permanent
solution?
Well there is no solution for that. Accessing the underlying struct page
through the sg_table is illegal in the first place.
So the question is not how to access the struct page, but rather why do
you want to do this?
Regards,
Christian.
z
Re: [RESEND 1/6] drm/bridge/analogix/anx6345: switch to struct drm_edid
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> .../gpu/drm/bridge/analogix/analogix-anx6345.c| 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index c9e35731e6a1..42ab6014fe12 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -47,7 +47,7 @@ struct anx6345 {
> struct drm_dp_aux aux;
> struct drm_bridge bridge;
> struct i2c_client *client;
> - struct edid *edid;
> + const struct drm_edid *drm_edid;
> struct drm_connector connector;
> struct drm_panel *panel;
> struct regulator *dvdd12;
> @@ -458,7 +458,7 @@ static int anx6345_get_modes(struct drm_connector
> *connector)
>
> mutex_lock(>lock);
>
> - if (!anx6345->edid) {
> + if (!anx6345->drm_edid) {
> if (!anx6345->powered) {
> anx6345_poweron(anx6345);
> power_off = true;
> @@ -470,19 +470,18 @@ static int anx6345_get_modes(struct drm_connector
> *connector)
> goto unlock;
> }
>
> - anx6345->edid = drm_get_edid(connector, >aux.ddc);
> - if (!anx6345->edid)
> + anx6345->drm_edid = drm_edid_read_ddc(connector,
> >aux.ddc);
> + if (!anx6345->drm_edid)
> DRM_ERROR("Failed to read EDID from panel\n");
>
> - err = drm_connector_update_edid_property(connector,
> -anx6345->edid);
> + err = drm_edid_connector_update(connector, anx6345->drm_edid);
> if (err) {
> DRM_ERROR("Failed to update EDID property: %d\n",
> err);
> goto unlock;
> }
> }
>
> - num_modes += drm_add_edid_modes(connector, anx6345->edid);
> + num_modes += drm_edid_connector_add_modes(connector);
>
> /* Driver currently supports only 6bpc */
> connector->display_info.bpc = 6;
> @@ -793,7 +792,7 @@ static void anx6345_i2c_remove(struct i2c_client *client)
>
> unregister_i2c_dummy_clients(anx6345);
>
> - kfree(anx6345->edid);
> + drm_edid_free(anx6345->drm_edid);
>
> mutex_destroy(>lock);
> }
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [RESEND 4/6] drm/i2c: tda998x: switch to struct drm_edid
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Russell King
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index d8d7de18dd65..2160f05bbd16 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1283,7 +1283,7 @@ static int read_edid_block(void *data, u8 *buf,
> unsigned int blk, size_t length)
> static int tda998x_connector_get_modes(struct drm_connector *connector)
> {
> struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
> - struct edid *edid;
> + const struct drm_edid *drm_edid;
> int n;
>
> /*
> @@ -1297,25 +1297,26 @@ static int tda998x_connector_get_modes(struct
> drm_connector *connector)
> if (priv->rev == TDA19988)
> reg_clear(priv, REG_TX4, TX4_PD_RAM);
>
> - edid = drm_do_get_edid(connector, read_edid_block, priv);
> + drm_edid = drm_edid_read_custom(connector, read_edid_block, priv);
>
> if (priv->rev == TDA19988)
> reg_set(priv, REG_TX4, TX4_PD_RAM);
>
> - if (!edid) {
> + drm_edid_connector_update(connector, drm_edid);
> + cec_notifier_set_phys_addr(priv->cec_notify,
> +
> connector->display_info.source_physical_address);
> +
> + if (!drm_edid) {
> dev_warn(>hdmi->dev, "failed to read EDID\n");
> return 0;
> }
>
> - drm_connector_update_edid_property(connector, edid);
> - cec_notifier_set_phys_addr_from_edid(priv->cec_notify, edid);
> -
> mutex_lock(>audio_mutex);
> - n = drm_add_edid_modes(connector, edid);
> - priv->sink_has_audio = drm_detect_monitor_audio(edid);
> + n = drm_edid_connector_add_modes(connector);
> + priv->sink_has_audio = connector->display_info.has_audio;
> mutex_unlock(>audio_mutex);
>
> - kfree(edid);
> + drm_edid_free(drm_edid);
>
> return n;
> }
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [RESEND 5/6] drm/bochs: switch to struct drm_edid
On Fri, May 10, 2024 at 3:27 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux.dev
> ---
> drivers/gpu/drm/tiny/bochs.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
> index 2d7ad808cc0e..d12d6e0bf3df 100644
> --- a/drivers/gpu/drm/tiny/bochs.c
> +++ b/drivers/gpu/drm/tiny/bochs.c
> @@ -85,7 +85,7 @@ struct bochs_device {
> u16 yres_virtual;
> u32 stride;
> u32 bpp;
> - struct edid *edid;
> + const struct drm_edid *drm_edid;
>
> /* drm */
> struct drm_device *dev;
> @@ -199,10 +199,10 @@ static int bochs_hw_load_edid(struct bochs_device
> *bochs)
> if (drm_edid_header_is_valid(header) != 8)
> return -1;
>
> - kfree(bochs->edid);
> - bochs->edid = drm_do_get_edid(>connector,
> - bochs_get_edid_block, bochs);
> - if (bochs->edid == NULL)
> + drm_edid_free(bochs->drm_edid);
> + bochs->drm_edid = drm_edid_read_custom(>connector,
> + bochs_get_edid_block, bochs);
> + if (bochs->drm_edid == NULL)
> return -1;
>
> return 0;
> @@ -303,7 +303,7 @@ static void bochs_hw_fini(struct drm_device *dev)
> if (bochs->fb_map)
> iounmap(bochs->fb_map);
> pci_release_regions(to_pci_dev(dev->dev));
> - kfree(bochs->edid);
> + drm_edid_free(bochs->drm_edid);
> }
>
> static void bochs_hw_blank(struct bochs_device *bochs, bool blank)
> @@ -471,12 +471,9 @@ static const struct drm_simple_display_pipe_funcs
> bochs_pipe_funcs = {
>
> static int bochs_connector_get_modes(struct drm_connector *connector)
> {
> - struct bochs_device *bochs =
> - container_of(connector, struct bochs_device, connector);
> - int count = 0;
> + int count;
>
> - if (bochs->edid)
> - count = drm_add_edid_modes(connector, bochs->edid);
> + count = drm_edid_connector_add_modes(connector);
>
> if (!count) {
> count = drm_add_modes_noedid(connector, 8192, 8192);
> @@ -507,10 +504,10 @@ static void bochs_connector_init(struct drm_device *dev)
> drm_connector_helper_add(connector,
> _connector_connector_helper_funcs);
>
> bochs_hw_load_edid(bochs);
> - if (bochs->edid) {
> + if (bochs->drm_edid) {
> DRM_INFO("Found EDID data blob.\n");
> drm_connector_attach_edid_property(connector);
> - drm_connector_update_edid_property(connector, bochs->edid);
> + drm_edid_connector_update(>connector, bochs->drm_edid);
> }
> }
>
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [RESEND 6/6] drm/virtio: switch to struct drm_edid
On Fri, May 10, 2024 at 3:34 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: virtualizat...@lists.linux.dev
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 10 --
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
> drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++--
> 3 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index ad924a8502e9..64baf2f22d9f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -164,11 +164,9 @@ static int virtio_gpu_conn_get_modes(struct
> drm_connector *connector)
> struct drm_display_mode *mode = NULL;
> int count, width, height;
>
> - if (output->edid) {
> - count = drm_add_edid_modes(connector, output->edid);
> - if (count)
> - return count;
> - }
> + count = drm_edid_connector_add_modes(connector);
> + if (count)
> + return count;
>
> width = le32_to_cpu(output->info.r.width);
> height = le32_to_cpu(output->info.r.height);
> @@ -369,5 +367,5 @@ void virtio_gpu_modeset_fini(struct virtio_gpu_device
> *vgdev)
> return;
>
> for (i = 0 ; i < vgdev->num_scanouts; ++i)
> - kfree(vgdev->outputs[i].edid);
> + drm_edid_free(vgdev->outputs[i].drm_edid);
> }
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index bb7d86a0c6a1..64c236169db8 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -179,7 +179,7 @@ struct virtio_gpu_output {
> struct drm_encoder enc;
> struct virtio_gpu_display_one info;
> struct virtio_gpu_update_cursor cursor;
> - struct edid *edid;
> + const struct drm_edid *drm_edid;
> int cur_x;
> int cur_y;
> bool needs_modeset;
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index b1a00c0c25a7..0d3d0d09f39b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -741,21 +741,21 @@ static void virtio_gpu_cmd_get_edid_cb(struct
> virtio_gpu_device *vgdev,
> (struct virtio_gpu_resp_edid *)vbuf->resp_buf;
> uint32_t scanout = le32_to_cpu(cmd->scanout);
> struct virtio_gpu_output *output;
> - struct edid *new_edid, *old_edid;
> + const struct drm_edid *new_edid, *old_edid;
>
> if (scanout >= vgdev->num_scanouts)
> return;
> output = vgdev->outputs + scanout;
>
> - new_edid = drm_do_get_edid(>conn, virtio_get_edid_block,
> resp);
> - drm_connector_update_edid_property(>conn, new_edid);
> + new_edid = drm_edid_read_custom(>conn, virtio_get_edid_block,
> resp);
> + drm_edid_connector_update(>conn, new_edid);
>
> spin_lock(>display_info_lock);
> - old_edid = output->edid;
> - output->edid = new_edid;
> + old_edid = output->drm_edid;
> + output->drm_edid = new_edid;
> spin_unlock(>display_info_lock);
>
> - kfree(old_edid);
> + drm_edid_free(old_edid);
> wake_up(>resp_wq);
> }
>
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [RESEND 4/6] drm/amdgpu: remove amdgpu_connector_edid() and stop using edid_blob_ptr
On Fri, May 10, 2024 at 5:09 PM Jani Nikula wrote:
>
> amdgpu_connector_edid() copies the EDID from edid_blob_ptr as a side
> effect if amdgpu_connector->edid isn't initialized. However, everywhere
> that the returned EDID is used, the EDID should have been set
> beforehands.
>
> Only the drm EDID code should look at the EDID property, anyway, so stop
> using it.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Pan, Xinhui
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.h | 1 -
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 4 ++--
> 6 files changed, 8 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 9caba10315a8..cae7479c3ecf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -246,22 +246,6 @@ amdgpu_connector_find_encoder(struct drm_connector
> *connector,
> return NULL;
> }
>
> -struct edid *amdgpu_connector_edid(struct drm_connector *connector)
> -{
> - struct amdgpu_connector *amdgpu_connector =
> to_amdgpu_connector(connector);
> - struct drm_property_blob *edid_blob = connector->edid_blob_ptr;
> -
> - if (amdgpu_connector->edid) {
> - return amdgpu_connector->edid;
> - } else if (edid_blob) {
> - struct edid *edid = kmemdup(edid_blob->data,
> edid_blob->length, GFP_KERNEL);
> -
> - if (edid)
> - amdgpu_connector->edid = edid;
> - }
> - return amdgpu_connector->edid;
> -}
> -
> static struct edid *
> amdgpu_connector_get_hardcoded_edid(struct amdgpu_device *adev)
> {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.h
> index 61fcef15ad72..eff833b6ed31 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.h
> @@ -24,7 +24,6 @@
> #ifndef __AMDGPU_CONNECTORS_H__
> #define __AMDGPU_CONNECTORS_H__
>
> -struct edid *amdgpu_connector_edid(struct drm_connector *connector);
> void amdgpu_connector_hotplug(struct drm_connector *connector);
> int amdgpu_connector_get_monitor_bpc(struct drm_connector *connector);
> u16 amdgpu_connector_encoder_get_dp_bridge_encoder_id(struct drm_connector
> *connector);
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index b44fce44c066..dddb5fe16f2c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1299,7 +1299,7 @@ static void
> dce_v10_0_audio_write_speaker_allocation(struct drm_encoder *encoder
> return;
> }
>
> - sad_count =
> drm_edid_to_speaker_allocation(amdgpu_connector_edid(connector), );
> + sad_count = drm_edid_to_speaker_allocation(amdgpu_connector->edid,
> );
> if (sad_count < 0) {
> DRM_ERROR("Couldn't read Speaker Allocation Data Block:
> %d\n", sad_count);
> sad_count = 0;
> @@ -1369,7 +1369,7 @@ static void dce_v10_0_audio_write_sad_regs(struct
> drm_encoder *encoder)
> return;
> }
>
> - sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> + sad_count = drm_edid_to_sad(amdgpu_connector->edid, );
> if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> if (sad_count <= 0)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 80b2e7f79acf..11780e4d7e9f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1331,7 +1331,7 @@ static void
> dce_v11_0_audio_write_speaker_allocation(struct drm_encoder *encoder
> return;
> }
>
> - sad_count =
> drm_edid_to_speaker_allocation(amdgpu_connector_edid(connector), );
> + sad_count = drm_edid_to_speaker_allocation(amdgpu_connector->edid,
> );
> if (sad_count < 0) {
> DRM_ERROR("Couldn't read Speaker Allocation Data Block:
> %d\n", sad_count);
> sad_count = 0;
> @@ -1401,7 +1401,7 @@ static void dce_v11_0_audio_write_sad_regs(struct
> drm_encoder *encoder)
> return;
> }
>
> - sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> + sad_count = drm_edid_to_sad(amdgpu_connector->edid, );
> if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> if (sad_count <= 0)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
>
Re: [PATCH v4 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
On Wed, May 08, 2024 at 01:51:48PM -0700, Douglas Anderson wrote: > This is a mechanical conversion of the novatek-nt36672e driver to use > the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for > clients to understand and using it also causes smaller code to be > generated. Specifically: > > $ scripts/bloat-o-meter \ > ...after/panel-novatek-nt36672e.ko \ > ...ctx/panel-novatek-nt36672e.ko > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988) > Function old new delta > nt36672e_1080x2408_60hz_init62365248-988 > Total: Before=10651, After=9663, chg -9.28% > > Cc: Ritesh Kumar > Signed-off-by: Douglas Anderson > --- > This change is only compile tested. I don't use this panel myself but > arbitrarily picked it as an example to look at when working on the > MIPI DSI macros. > > NOTE: as of the posting of v4 this change still has no tags. Without > any tags (Reviewed-by/Tested-by/Acked-by) I won't actually land this > change even if the rest of the series lands. > > (no changes since v3) > > Changes in v3: > - Fix spacing of init function. > > Changes in v2: > - New > > .../gpu/drm/panel/panel-novatek-nt36672e.c| 576 +- > 1 file changed, 289 insertions(+), 287 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [RESEND 3/6] drm/radeon: remove radeon_connector_edid() and stop using edid_blob_ptr
On Fri, May 10, 2024 at 5:08 PM Jani Nikula wrote:
>
> radeon_connector_edid() copies the EDID from edid_blob_ptr as a side
> effect if radeon_connector->edid isn't initialized. However, everywhere
> that the returned EDID is used, the EDID should have been set
> beforehands.
>
> Only the drm EDID code should look at the EDID property, anyway, so stop
> using it.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Pan, Xinhui
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/radeon/radeon_audio.c | 7 ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 15 ---
> drivers/gpu/drm/radeon/radeon_mode.h | 2 --
> 3 files changed, 4 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
> b/drivers/gpu/drm/radeon/radeon_audio.c
> index 16c10db3ce6f..0bcd767b9f47 100644
> --- a/drivers/gpu/drm/radeon/radeon_audio.c
> +++ b/drivers/gpu/drm/radeon/radeon_audio.c
> @@ -303,6 +303,7 @@ void radeon_audio_endpoint_wreg(struct radeon_device
> *rdev, u32 offset,
> static void radeon_audio_write_sad_regs(struct drm_encoder *encoder)
> {
> struct drm_connector *connector =
> radeon_get_connector_for_encoder(encoder);
> + struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct cea_sad *sads;
> int sad_count;
> @@ -310,7 +311,7 @@ static void radeon_audio_write_sad_regs(struct
> drm_encoder *encoder)
> if (!connector)
> return;
>
> - sad_count = drm_edid_to_sad(radeon_connector_edid(connector), );
> + sad_count = drm_edid_to_sad(radeon_connector->edid, );
> if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> if (sad_count <= 0)
> @@ -326,6 +327,7 @@ static void radeon_audio_write_sad_regs(struct
> drm_encoder *encoder)
> static void radeon_audio_write_speaker_allocation(struct drm_encoder
> *encoder)
> {
> struct drm_connector *connector =
> radeon_get_connector_for_encoder(encoder);
> + struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> u8 *sadb = NULL;
> int sad_count;
> @@ -333,8 +335,7 @@ static void radeon_audio_write_speaker_allocation(struct
> drm_encoder *encoder)
> if (!connector)
> return;
>
> - sad_count =
> drm_edid_to_speaker_allocation(radeon_connector_edid(connector),
> - );
> + sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid,
> );
> if (sad_count < 0) {
> DRM_DEBUG("Couldn't read Speaker Allocation Data Block: %d\n",
> sad_count);
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 81b5c3c8f658..80879e946342 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -255,21 +255,6 @@ static struct drm_encoder *radeon_find_encoder(struct
> drm_connector *connector,
> return NULL;
> }
>
> -struct edid *radeon_connector_edid(struct drm_connector *connector)
> -{
> - struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> - struct drm_property_blob *edid_blob = connector->edid_blob_ptr;
> -
> - if (radeon_connector->edid) {
> - return radeon_connector->edid;
> - } else if (edid_blob) {
> - struct edid *edid = kmemdup(edid_blob->data,
> edid_blob->length, GFP_KERNEL);
> - if (edid)
> - radeon_connector->edid = edid;
> - }
> - return radeon_connector->edid;
> -}
> -
> static void radeon_connector_get_edid(struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 546381a5c918..e0a5af180801 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -701,8 +701,6 @@ extern u16
> radeon_connector_encoder_get_dp_bridge_encoder_id(struct drm_connecto
> extern bool radeon_connector_is_dp12_capable(struct drm_connector
> *connector);
> extern int radeon_get_monitor_bpc(struct drm_connector *connector);
>
> -extern struct edid *radeon_connector_edid(struct drm_connector *connector);
> -
> extern void radeon_connector_hotplug(struct drm_connector *connector);
> extern int radeon_dp_mode_valid_helper(struct drm_connector *connector,
>struct drm_display_mode *mode);
> --
> 2.39.2
>
Reviewed-by: Robert Foss
Re: [PATCH] drm/bridge: adv7511: Attach next bridge without creating connector
On Mon, 13 May 2024 at 10:55, Liu Ying wrote:
>
> The connector is created by either this ADV7511 bridge driver or
> any DRM device driver/previous bridge driver, so this ADV7511
> bridge driver should not let the next bridge driver create connector.
>
> If the next bridge is a HDMI connector, the next bridge driver
> would fail to attach bridge from display_connector_attach() without
> the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>
> Add that flag to drm_bridge_attach() function call in
> adv7511_bridge_attach() to fix the issue.
>
> This fixes the issue where the HDMI connector bridge fails to attach
> to the previous ADV7535 bridge on i.MX8MP EVK platform:
>
> [2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /hdmi-connector to encoder None-37: -22
> [2.220675] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using
> ADMA
> [2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/bus@3080/i2c@30a3/hdmi@3d to encoder None-37: -22
> [2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/bus@32c0/dsi@32e6 to encoder None-37: -22
> [2.256445] imx-lcdif 32e8.display-controller: error -EINVAL: Failed
> to attach bridge for endpoint0
> [2.265850] imx-lcdif 32e8.display-controller: error -EINVAL: Cannot
> connect bridge
> [2.274009] imx-lcdif 32e8.display-controller: probe with driver
> imx-lcdif failed with error -22
>
> Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in DT")
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v2 2/7] drm/mipi-dsi: wrap more functions for streamline handling
Hi, On Sat, May 11, 2024 at 4:00 PM Dmitry Baryshkov wrote: > > Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing > MIPI DSI functions to use the context for processing. This simplifies > and streamlines driver code to use simpler code pattern. > > Note, msleep function is also wrapped in this way as it is frequently > called inbetween other mipi_dsi_dcs_*() functions. > > Signed-off-by: Dmitry Baryshkov > --- > drivers/gpu/drm/drm_mipi_dsi.c | 210 > + > include/drm/drm_mipi_dsi.h | 21 + > 2 files changed, 231 insertions(+) Reviewed-by: Douglas Anderson
Re: [RESEND 2/6] drm/radeon: convert to using is_hdmi and has_audio from display info
On Fri, May 10, 2024 at 5:08 PM Jani Nikula wrote:
>
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Pan, Xinhui
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 10 +-
> drivers/gpu/drm/radeon/evergreen_hdmi.c| 5 ++---
> drivers/gpu/drm/radeon/radeon_audio.c | 6 +++---
> drivers/gpu/drm/radeon/radeon_connectors.c | 12 ++--
> drivers/gpu/drm/radeon/radeon_display.c| 2 +-
> drivers/gpu/drm/radeon/radeon_encoders.c | 4 ++--
> 6 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 2bff0d9e20f5..0aa395fac36f 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -701,7 +701,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
> if (radeon_connector->use_digital &&
> (radeon_connector->audio == RADEON_AUDIO_ENABLE))
> return ATOM_ENCODER_MODE_HDMI;
> - else if
> (drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
> + else if (connector->display_info.is_hdmi &&
> (radeon_connector->audio ==
> RADEON_AUDIO_AUTO))
> return ATOM_ENCODER_MODE_HDMI;
> else if (radeon_connector->use_digital)
> @@ -720,7 +720,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
> if (radeon_audio != 0) {
> if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
> return ATOM_ENCODER_MODE_HDMI;
> - else if
> (drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
> + else if (connector->display_info.is_hdmi &&
> (radeon_connector->audio ==
> RADEON_AUDIO_AUTO))
> return ATOM_ENCODER_MODE_HDMI;
> else
> @@ -737,14 +737,14 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
> if ((dig_connector->dp_sink_type ==
> CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
> (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
> {
> if (radeon_audio != 0 &&
> -
> drm_detect_monitor_audio(radeon_connector_edid(connector)) &&
> + connector->display_info.has_audio &&
> ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
> return ATOM_ENCODER_MODE_DP_AUDIO;
> return ATOM_ENCODER_MODE_DP;
> } else if (radeon_audio != 0) {
> if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
> return ATOM_ENCODER_MODE_HDMI;
> - else if
> (drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
> + else if (connector->display_info.is_hdmi &&
> (radeon_connector->audio ==
> RADEON_AUDIO_AUTO))
> return ATOM_ENCODER_MODE_HDMI;
> else
> @@ -755,7 +755,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
> break;
> case DRM_MODE_CONNECTOR_eDP:
> if (radeon_audio != 0 &&
> -
> drm_detect_monitor_audio(radeon_connector_edid(connector)) &&
> + connector->display_info.has_audio &&
> ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
> return ATOM_ENCODER_MODE_DP_AUDIO;
> return ATOM_ENCODER_MODE_DP;
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 681119c91d94..09dda114e218 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -412,7 +412,7 @@ void evergreen_hdmi_enable(struct drm_encoder *encoder,
> bool enable)
> if (enable) {
> struct drm_connector *connector =
> radeon_get_connector_for_encoder(encoder);
>
> - if (connector &&
> drm_detect_monitor_audio(radeon_connector_edid(connector))) {
> + if (connector && connector->display_info.has_audio) {
> WREG32(HDMI_INFOFRAME_CONTROL0 + dig->afmt->offset,
>HDMI_AVI_INFO_SEND | /* enable AVI info frames
> */
>HDMI_AVI_INFO_CONT | /* required for audio
> info values to be updated */
> @@ -450,8 +450,7 @@ void evergreen_dp_enable(struct drm_encoder *encoder,
> bool enable)
>
Re: [PATCH 4/4] drm/xe/guc: Expose raw access to GuC log over debugfs
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.
To allow more efficient access to the GuC log, which could benefit
our CI systems, expose raw binary log data. In addition to less
overhead in preparing text based GuC log file, the new GuC log file
in binary format is also almost 3x smaller.
Any existing script that expects the GuC log buffer in text format
can use command like below to convert from new binary format:
hexdump -e '4/4 "0x%08x " "\n"'
but this shouldn't be the case as most decoders expect GuC log data
in binary format.
I strongly disagree with this.
Efficiency and file size is not an issue when accessing the GuC log via
debugfs on actual hardware. It is an issue when dumping via dmesg but
you definitely should not be dumping binary data to dmesg. Whereas,
dumping in binary data is much more dangerous and liable to corruption
because some tool along the way tries to convert to ASCII, or truncates
at the first zero, etc. We request GuC logs be sent by end users,
customer bug reports, etc. all doing things that we have no control over.
Converting the hexdump back to binary is trivial for those tools which
require it. If you follow the acquisition and decoding instructions on
the wiki page then it is all done for you automatically.
These patches are trying to solve a problem which does not exist and are
going to make working with GuC logs harder and more error prone.
On the other hand, there are many other issues with GuC logs that it
would be useful to solves - including extra meta data, reliable output
via dmesg, continuous streaming, pre-sizing the debugfs file to not have
to generate it ~12 times for a single read, etc.
Hmm. Actually, is this interface allowing the filesystem layers to issue
multiple read calls to read the buffer out in small chunks? That is also
going to break things. If the GuC is still writing to the log as the
user is reading from it, there is the opportunity for each chunk to not
follow on from the previous chunk because the data has just been
overwritten. This is already a problem at the moment that causes issues
when decoding the logs, even with an almost atomic copy of the log into
a temporary buffer before reading it out. Doing the read in separate
chunks is only going to make that problem even worse.
John.
Signed-off-by: Michal Wajdeczko
Cc: Lucas De Marchi
Cc: John Harrison
---
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/xe/xe_guc_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_guc_debugfs.c
b/drivers/gpu/drm/xe/xe_guc_debugfs.c
index d3822cbea273..53fea952344d 100644
--- a/drivers/gpu/drm/xe/xe_guc_debugfs.c
+++ b/drivers/gpu/drm/xe/xe_guc_debugfs.c
@@ -8,6 +8,7 @@
#include
#include
+#include "xe_bo.h"
#include "xe_device.h"
#include "xe_gt.h"
#include "xe_guc.h"
@@ -52,6 +53,29 @@ static const struct drm_info_list debugfs_list[] = {
{"guc_log", guc_log, 0},
};
+static ssize_t guc_log_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
+{
+ struct dentry *dent = file_dentry(file);
+ struct dentry *uc_dent = dent->d_parent;
+ struct dentry *gt_dent = uc_dent->d_parent;
+ struct xe_gt *gt = gt_dent->d_inode->i_private;
+ struct xe_guc_log *log = >uc.guc.log;
+ struct xe_device *xe = gt_to_xe(gt);
+ ssize_t ret;
+
+ xe_pm_runtime_get(xe);
+ ret = xe_map_read_from(xe, buf, count, pos, >bo->vmap,
log->bo->size);
+ xe_pm_runtime_put(xe);
+
+ return ret;
+}
+
+static const struct file_operations guc_log_ops = {
+ .owner = THIS_MODULE,
+ .read = guc_log_read,
+ .llseek = default_llseek,
+};
+
void xe_guc_debugfs_register(struct xe_guc *guc, struct dentry *parent)
{
struct drm_minor *minor = guc_to_xe(guc)->drm.primary;
@@ -72,4 +96,6 @@ void xe_guc_debugfs_register(struct xe_guc *guc, struct
dentry *parent)
drm_debugfs_create_files(local,
ARRAY_SIZE(debugfs_list),
parent, minor);
+
+ debugfs_create_file("guc_log_raw", 0600, parent, NULL, _log_ops);
}
Re: drm/bridge: adv7511: Attach next bridge without creating connector
On Mon, May 13, 2024 at 6:30 PM Sui Jingfeng wrote:
>
> Hi,
>
>
> On 5/13/24 16:02, Liu Ying wrote:
> > The connector is created by either this ADV7511 bridge driver or
> > any DRM device driver/previous bridge driver, so this ADV7511
> > bridge driver should not let the next bridge driver create connector.
> >
> > If the next bridge is a HDMI connector, the next bridge driver
> > would fail to attach bridge from display_connector_attach() without
> > the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
> >
> > Add that flag to drm_bridge_attach() function call in
> > adv7511_bridge_attach() to fix the issue.
> >
> > This fixes the issue where the HDMI connector bridge fails to attach
> > to the previous ADV7535 bridge on i.MX8MP EVK platform:
> >
> > [2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /hdmi-connector to encoder None-37: -22
> > [2.220675] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using
> > ADMA
> > [2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/bus@3080/i2c@30a3/hdmi@3d to encoder None-37: -22
> > [2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/bus@32c0/dsi@32e6 to encoder None-37: -22
> > [2.256445] imx-lcdif 32e8.display-controller: error -EINVAL: Failed
> > to attach bridge for endpoint0
> > [2.265850] imx-lcdif 32e8.display-controller: error -EINVAL: Cannot
> > connect bridge
> > [2.274009] imx-lcdif 32e8.display-controller: probe with driver
> > imx-lcdif failed with error -22
> >
> > Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in
> > DT")
> > Signed-off-by: Liu Ying
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index dd21b81bd28f..66ccb61e2a66 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -953,7 +953,8 @@ static int adv7511_bridge_attach(struct drm_bridge
> > *bridge,
> > int ret = 0;
> >
> > if (adv->next_bridge) {
> > - ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
> > bridge, flags);
> > + ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
> > bridge,
> > + flags |
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>
> As a side note, I think, maybe you could do better in the future.
>
> If we know that the KMS display driver side has the HDMI connector
> already created for us, we should pass DRM_BRIDGE_ATTACH_NO_CONNECTOR
> from the root KMS driver side. Which is to forbidden all potential
> drm bridge drivers to create a connector in the middle.
>
> The KMS display driver side could parse the DT to know if there is
> a hdmi connector, or merely just hdmi connector device node, or
> something else.
>
> However, other maintainer and/or reviewer's opinion are of cause
> more valuable. I send a A-b because I thought the bug is urgency
> and it's probably more important to solve this bug first. And
> maybe you can Cc: if you like.
>
Reviewed-by: Robert Foss
Re: [PATCH v6 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
Hi, On Fri, May 10, 2024 at 7:13 PM Cong Yang wrote: > > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller > which fits in nicely with the existing panel-himax-hx83102 driver. Hence, > we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang > --- > Chage since V6: > > - No change. > > V5: > https://lore.kernel.org/all/20240509015207.3271370-6-yangco...@huaqin.corp-partner.google.com > > Chage since V5: > > - Adjust inital cmds indentation and check accum_err before calling mdelay in > init().. > > V4: > https://lore.kernel.org/all/20240507135234.1356855-6-yangco...@huaqin.corp-partner.google.com > > Chage since V4: > > - Depend Dous'series [1]. > [1]: > https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org > > V3: > https://lore.kernel.org/all/20240424023010.2099949-6-yangco...@huaqin.corp-partner.google.com > > Chage since V3: > > - inital cmds use lowercasehex. > > V2: > https://lore.kernel.org/all/20240422090310.3311429-6-yangco...@huaqin.corp-partner.google.com > > --- > drivers/gpu/drm/panel/panel-himax-hx83102.c | 133 > 1 file changed, 133 insertions(+) Reviewed-by: Douglas Anderson
Re: [PATCH v6 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel
Hi, On Fri, May 10, 2024 at 7:14 PM Cong Yang wrote: > > The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller > which fits in nicely with the existing panel-himax-hx83102 driver. Hence, > we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang > --- > Chage since V6: > > - Add hx83102_enable_extended_cmds(_ctx, false) at end of inital cmds. > > V5: > https://lore.kernel.org/all/20240509015207.3271370-8-yangco...@huaqin.corp-partner.google.com > > Chage since V5: > > - Adjust inital cmds indentation and check accum_err before calling mdelay in > init(). > - Adjust somes inital cmds to Optimize gamma. > > V4: > https://lore.kernel.org/all/20240507135234.1356855-8-yangco...@huaqin.corp-partner.google.com > > Chage since V4: > > - inital cmds use lowercasehex. > > V3: > https://lore.kernel.org/all/20240424023010.2099949-8-yangco...@huaqin.corp-partner.google.com > > Chage since V3: > > - Depend Dous'series [1]. > [1]: > https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org > > V2: > https://lore.kernel.org/all/20240422090310.3311429-8-yangco...@huaqin.corp-partner.google.com > > --- > drivers/gpu/drm/panel/panel-himax-hx83102.c | 131 > 1 file changed, 131 insertions(+) Reviewed-by: Douglas Anderson
Re: [PATCH v6 2/7] drm/panel: himax-hx83102: Break out as separate driver
Hi,
On Fri, May 10, 2024 at 7:13 PM Cong Yang
wrote:
>
> +static int hx83102_prepare(struct drm_panel *panel)
> +{
> + struct hx83102 *ctx = panel_to_hx83102(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = >dev;
> + int ret;
> +
> + gpiod_set_value(ctx->enable_gpio, 0);
> + usleep_range(1000, 1500);
> +
> + ret = regulator_enable(ctx->pp1800);
> + if (ret < 0)
> + return ret;
> +
> + usleep_range(3000, 5000);
> +
> + ret = regulator_enable(ctx->avdd);
> + if (ret < 0)
> + goto poweroff1v8;
> + ret = regulator_enable(ctx->avee);
> + if (ret < 0)
> + goto poweroffavdd;
> +
> + usleep_range(1, 11000);
> +
> + mipi_dsi_dcs_nop(ctx->dsi);
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value(ctx->enable_gpio, 1);
> + usleep_range(1000, 2000);
> + gpiod_set_value(ctx->enable_gpio, 0);
> + usleep_range(1000, 2000);
> + gpiod_set_value(ctx->enable_gpio, 1);
> + usleep_range(6000, 1);
> +
> + ret = ctx->desc->init(ctx);
> + if (ret < 0)
> + goto poweroff;
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret) {
> + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
The above should have been "goto poweroff", not "return ret".
> + msleep(120);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret) {
> + dev_err(dev, "Failed to turn on the display: %d\n", ret);
> + return ret;
> + }
The above should have been "goto poweroff", not "return ret".
Other than that:
Reviewed-by: Douglas Anderson
Re: [PATCH] drm/bridge: tc358767: Enable FRMSYNC timing generator
On Mon, May 13, 2024 at 4:16 AM Marek Vasut wrote:
>
> TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC
> description
> says "This bit should be disabled only in video mode transmission where Host
> transmits video timing together with video data and where pixel clock source
> is from DSI clock." . This driver always sources pixel clock from external
> xtal,
> therefore the FRMSYNC bit must always be enabled, enable it.
>
> This fixes an actual issue with DSI-to-DPI mode, where the display would
> randomly show subtle pixel flickering, or wobble, or shimmering. This is
> visible on solid gray color, but the degree of the shimmering differs
> between boots, which makes it hard to debug.
>
> There is a caveat to the FRMSYNC and this bridge pixel PLL, which can only
> generate pixel clock with limited accuracy, it may therefore be necessary
> to reduce the HFP to fit into line length of input pixel data, to avoid any
> possible overflows, which make the output video look striped horizontally.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Adam Ford
> Cc: Alexander Stein
> Cc: Andrzej Hajda
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Frieder Schrempf
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Michael Walle
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Thomas Zimmermann
> Cc: dri-devel@lists.freedesktop.org
> Cc: ker...@dh-electronics.com
> ---
> drivers/gpu/drm/bridge/tc358767.c | 23 ---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 166f9a3e9622d..fe2b93546eaef 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -382,6 +382,9 @@ struct tc_data {
>
> /* HPD pin number (0 or 1) or -ENODEV */
> int hpd_pin;
> +
> + /* Number of pixels to subtract from a line due to pixel clock delta
> */
> + u32 line_pixel_subtract;
> };
>
> static inline struct tc_data *aux_to_tc(struct drm_dp_aux *a)
> @@ -577,6 +580,11 @@ static int tc_pllupdate(struct tc_data *tc, unsigned int
> pllctrl)
> return 0;
> }
>
> +static u32 div64_round_up(u64 v, u32 d)
> +{
> + return div_u64(v + d - 1, d);
> +}
> +
Could the DIV_ROUND_UP macro in math,h replace this function?
> static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
> {
> int ret;
> @@ -658,8 +666,11 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk,
> u32 pixelclock)
> return -EINVAL;
> }
>
> - dev_dbg(tc->dev, "PLL: got %d, delta %d\n", best_pixelclock,
> - best_delta);
> + tc->line_pixel_subtract = tc->mode.htotal -
> + div64_round_up(tc->mode.htotal * (u64)best_pixelclock,
> pixelclock);
> +
> + dev_dbg(tc->dev, "PLL: got %d, delta %d (subtract %d px)\n",
> best_pixelclock,
> + best_delta, tc->line_pixel_subtract);
> dev_dbg(tc->dev, "PLL: %d / %d / %d * %d / %d\n", refclk,
> ext_div[best_pre], best_div, best_mul, ext_div[best_post]);
>
> @@ -885,6 +896,12 @@ static int tc_set_common_video_mode(struct tc_data *tc,
> upper_margin, lower_margin, vsync_len);
> dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
>
> + if (right_margin > tc->line_pixel_subtract) {
> + right_margin -= tc->line_pixel_subtract;
> + } else {
> + dev_err(tc->dev, "Bridge pixel clock too slow for mode\n");
> + right_margin = 0;
> + }
>
> /*
> * LCD Ctl Frame Size
> @@ -894,7 +911,7 @@ static int tc_set_common_video_mode(struct tc_data *tc,
> */
> ret = regmap_write(tc->regmap, VPCTRL0,
>FIELD_PREP(VSDELAY, right_margin + 10) |
> - OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
> + OPXLFMT_RGB888 | FRMSYNC_ENABLED | MSF_DISABLED);
> if (ret)
> return ret;
>
> --
> 2.43.0
>
With the above question resolved, feel free to add my r-b. I will
snooze this for a week before looking at applying this.
Reviewed-by: Robert Foss
[ANNOUNCE] Graphics & DRM MC at LPC 2024
The Graphics and DRM Microconference was accepted for Linux Plumbers 2024! Please, submit your proposal in the following page: https://lpc.events/event/18/abstracts/ Remember to select "Graphics & DRM MC" in the Track field. The deadline for submissions is Sunday 30th June. The accepted proposals will be listed here: https://lpc.events/event/18/contributions/1664/ LPC 2024 will happen in Vienna, Austria, on September 18-20: https://lpc.events/event/18/ Thanks!
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On Mon, 13 May 2024 at 16:17, Rob Herring wrote: > > On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > Cleanups for display panel bindings. > > > > Rob, maybe you could take entire set if it applies? I based it on > > linux-next, so letl me know if I need to rebase on your for-next. > > Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? > Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml > Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. -- With best wishes Dmitry
Re: [PATCH v2 00/12] Remove redundant checks on existence of 'bridge->encoder'
On Mon, 13 May 2024 23:30:57 +0800, Sui Jingfeng wrote: > The checks on the existence of bridge->encoder in the implementation of > drm_bridge_funcs::attach() is not necessary, as it has already been checked > in the drm_bridge_attach() function call by previous bridge or KMS driver. > The drm_bridge_attach() will quit with a negative error code returned if > it fails for some reasons, hence, it is guaranteed that the .encoder member > of the drm_bridge instance is not NULL when various bridge attach functions > are called. > > [...] Applied, thanks! [01/12] drm/bridge: simple-bridge: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f0a83a2cf9eb [02/12] drm/bridge: tfp410: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=482ade3ec1c5 [03/12] drm/bridge: nxp-ptn3460: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0f4bca4e1be3 [04/12] drm/bridge: panel: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a8f856bf054a [05/12] drm/bridge: it6505: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8761a39e3f9d [06/12] drm/bridge: adv7511: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=41e6ed85e457 [07/12] drm/bridge: cdns-mhdp8546: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b24fd6e9eb66 [08/12] drm/bridge: megachips-stdp-ge-b850v3-fw: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0a59deb2fedb [09/12] drm/bridge: synopsys: dw-mipi-dsi: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=80221a89ff95 [10/12] drm/bridge: lt9611uxc: Remove a redundant check on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=91942a37ebba [11/12] drm/bridge: imx: Remove redundant checks on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ec74951a7507 [12/12] drm/bridge: analogix: Remove redundant checks on existence of bridge->encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=591255853a37 Rob
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Mon, May 13, 2024 at 03:44:00PM +0200, AngeloGioacchino Del Regno wrote: > Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto: > > On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote: > > > Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto: > > > > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno > > > > wrote: > > > > > Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto: > > > > > > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno > > > > > > wrote: > > > > > > > Il 08/05/24 09:19, CK Hu (胡俊光) ha scritto: > > > > > > > > On Tue, 2024-05-07 at 16:07 +0200, AngeloGioacchino Del > > > > > > > > Regno > > > > > > > > wrote: > > > > > > > > > Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto: > > > > > > > > > > On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del > > > > > > > > > > Regno > > > > > > > > > > wrote: > > > > > > > > > > > Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto: > > > > > > > > > > > > Hi, Angelo: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino > > > > > > > > > > > > Del > > > > > > > > > > > > Regno > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Document OF graph on MMSYS/VDOSYS: this supports > > > > > > > > > > > > > up > > > > > > > > > > > > > to > > > > > > > > > > > > > three > > > > > > > > > > > > > DDP > > > > > > > > > > > > > paths > > > > > > > > > > > > > per HW instance (so potentially up to six > > > > > > > > > > > > > displays > > > > > > > > > > > > > for > > > > > > > > > > > > > multi- > > > > > > > > > > > > > vdo > > > > > > > > > > > > > SoCs). > > > > > > > > > > > > > > > > > > > > > > > > > > The MMSYS or VDOSYS is always the first component > > > > > > > > > > > > > in > > > > > > > > > > > > > the > > > > > > > > > > > > > DDP > > > > > > > > > > > > > pipeline, > > > > > > > > > > > > > so it only supports an output port with multiple > > > > > > > > > > > > > endpoints - > > > > > > > > > > > > > where > > > > > > > > > > > > > each > > > > > > > > > > > > > endpoint defines the starting point for one of > > > > > > > > > > > > > the > > > > > > > > > > > > > (currently > > > > > > > > > > > > > three) > > > > > > > > > > > > > possible hardware paths. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: AngeloGioacchino Del Regno < > > > > > > > > > > > > > angelogioacchino.delre...@collabora.com> One of you guys, probably 胡俊光, has a mail client that is completely mangling these quotes. Can you try to fix that please? It makes reading the thread unfun :/ signature.asc Description: PGP signature
Re: drm/bridge: adv7511: Attach next bridge without creating connector
Hi,
On 5/13/24 16:02, Liu Ying wrote:
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.
If the next bridge is a HDMI connector, the next bridge driver
would fail to attach bridge from display_connector_attach() without
the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
Add that flag to drm_bridge_attach() function call in
adv7511_bridge_attach() to fix the issue.
This fixes the issue where the HDMI connector bridge fails to attach
to the previous ADV7535 bridge on i.MX8MP EVK platform:
[2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/hdmi-connector to encoder None-37: -22
[2.220675] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using ADMA
[2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@3080/i2c@30a3/hdmi@3d to encoder None-37: -22
[2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@32c0/dsi@32e6 to encoder None-37: -22
[2.256445] imx-lcdif 32e8.display-controller: error -EINVAL: Failed to
attach bridge for endpoint0
[2.265850] imx-lcdif 32e8.display-controller: error -EINVAL: Cannot
connect bridge
[2.274009] imx-lcdif 32e8.display-controller: probe with driver
imx-lcdif failed with error -22
Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in DT")
Signed-off-by: Liu Ying
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index dd21b81bd28f..66ccb61e2a66 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -953,7 +953,8 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
int ret = 0;
if (adv->next_bridge) {
- ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
bridge, flags);
+ ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
bridge,
+ flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
As a side note, I think, maybe you could do better in the future.
If we know that the KMS display driver side has the HDMI connector
already created for us, we should pass DRM_BRIDGE_ATTACH_NO_CONNECTOR
from the root KMS driver side. Which is to forbidden all potential
drm bridge drivers to create a connector in the middle.
The KMS display driver side could parse the DT to know if there is
a hdmi connector, or merely just hdmi connector device node, or
something else.
However, other maintainer and/or reviewer's opinion are of cause
more valuable. I send a A-b because I thought the bug is urgency
and it's probably more important to solve this bug first. And
maybe you can Cc: if you like.
Thanks.
if (ret)
return ret;
}
--
Best regards
Sui Jingfeng
Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
On Mon, May 13, 2024 at 12:03:07PM +0300, Marius Vlad wrote: > Hi all, > On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote: > > On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote: > > > Le 09/05/24 - 18:18, Jim Shargo a écrit : > > > > Sima--thanks SO MUCH for going through with everything leaving a > > > > detailed review. I am excited to go through your feedback. > > > > > > > > It makes me extremely happy to see these patches get people excited. > > > > > > > > They've bounced between a few people, and I recently asked to take > > > > them over again from the folks who were most recently looking at them > > > > but haven't since had capacity to revisit them. I'd love to contribute > > > > more but I am currently pretty swamped and I probably couldn't > > > > realistically make too much headway before the middle of June. > > > > > > > > José--if you've got capacity and interest, I'd love to see this work > > > > get in! Thanks!! Please let me know your timeline and if you want to > > > > split anything up or have any questions, I'd love to help if possible. > > > > But most important to me is seeing the community benefit from the > > > > feature. > > > > > > > > And (in case it got lost in the shuffle of all these patches) the IGT > > > > tests really make it much easier to develop this thing. Marius has > > > > posted the most recent patches: > > > > https://lore.kernel.org/igt-dev/?q=configfs > > > > > > > > Thanks! > > > > -- Jim > > > > > > > > > > > > > > > > On Wed, May 8, 2024 at 2:17 PM José Expósito > > > > wrote: > > > > > > > > > > Hi everyone, > > > > > > > > > > I wasn't aware of these patches, but I'm really glad they are getting > > > > > some attention, thanks a lot for your review Sima. > > > > > > > > > > Given that it's been a while since the patches were emailed, I'm not > > > > > sure if the original authors of the patches could implement your > > > > > comments. If not, I can work on it. Please let me know. > > > > > > > > > > I'm working on a Mutter feature that'd greatly benefit from this uapi > > > > > and I'm sure other compositors would find it useful. > > > > > > > > > > I'll start working on a new version in a few days if nobody else is > > > > > already working on it. > > > > > > > > > > Best wishes, > > > > > José Expósito > > > > > > Hi all! > > > > > > Very nice to see other people working on this subject. As the series > > > seemed inactive, I started two weeks ago to rebase it on top of [1]. I > > > also started some work to use drmm_* helpers instead of using lists in > > > vkms. I currently struggle with a deadlock during rmmod. > > > > > > I need to clean my commits, but I can share a WIP version. > > > > Hi Louis, > > > > If you could share a RFC/WIP series it would be awesome! > > > > Since you are already working on the kernel patches (and I guess IGT?), > > I'll start working on a libdrm high level API to interact with VKMS from > > user-space on top of your patches. I'll share a link as soon as I have a > > draft PR. > > Just out of curiosity what API would that be? These should fairly > simple that they can be configured from a shell script > (mount/mkdir/rm/echo/umount). Believe should be easy enough to test stuff > with > bunch scripts like that. My plan is to add a very thin C API around mkdir/rmdir/etc. It is true that VKMS can be configure easily using a bash script; however, compositors with test suites written in C (or with bindings to libdrm) would have to write similar wrappers around the mkdir/rmdir/etc calls. I think that it could be beneficial for them to have a shared wrapper available in libdrm. > Perphas landing the I-G-T tests first (assuming we're settled > on how exactly this would work) might be of greated help to get a green lit > the kernel driver side? Skip if vkms/configfs/something else that tells > us VKMS doesn't have ConfigFS eneabled, and run it when that is on. > > The lastest iteration was shared by Jim at > https://lore.kernel.org/igt-dev/20230901092819.16924-1-marius.v...@collabora.com/ > > That way sub-sequent BAT CI would pick up issues, and can also used > independently by Louis. Should also divide the work-load evenly with > Louis focusing on the just the driver. Happy to review and test it. > > > > > > Maybe we can discuss a bit the comment from Daniel (split init between > > > default/configfs, use or not a real platform device...) > > > > > > For the split, I think the first solution (struct vkms_config) can be > > > easier to understand and to implement, for two reasons: > > > - No need to distinguish between the "default" and the "configfs" devices > > > in the VKMS "core". All is managed with only one struct vkms_config. > > > - Most of the lifetime issue should be gone. The only thing to > > > synchronize is passing this vkms_config from ConfigFS to VKMS. > > > > I agree, this seems like the easiest solution. > > > > > The drawback of this is that it
Re: [PATCH] drm/i915/gem/i915_gem_ttm_move: Fix typo
On Mon, May 13, 2024 at 02:14:51AM -0400, Deming Wang wrote: > The mapings should be replaced by mappings. > > Signed-off-by: Deming Wang Reviewed-by: Rodrigo Vivi and pushed to drm-intel-gt-next thanks for the patch > --- > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > index 7078af2f8f79..03b00a03a634 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > @@ -155,7 +155,7 @@ void i915_ttm_adjust_gem_after_move(struct > drm_i915_gem_object *obj) > * @bo: The ttm buffer object. > * > * This function prepares an object for move by removing all GPU bindings, > - * removing all CPU mapings and finally releasing the pages sg-table. > + * removing all CPU mappings and finally releasing the pages sg-table. > * > * Return: 0 if successful, negative error code on error. > */ > -- > 2.31.1 >
[PATCH] drm/msm: Add obj flags to gpu devcoredump
From: Rob Clark
When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 +
drivers/gpu/drm/msm/msm_gpu.c | 6 --
drivers/gpu/drm/msm/msm_gpu.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b7bbef2eeff4..d9ea15994ae9 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -887,6 +887,7 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state
*state,
drm_printf(p, " - iova: 0x%016llx\n",
state->bos[i].iova);
drm_printf(p, "size: %zd\n", state->bos[i].size);
+ drm_printf(p, "flags: 0x%x\n", state->bos[i].flags);
drm_printf(p, "name: %-32s\n", state->bos[i].name);
adreno_show_object(p, >bos[i].data,
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d14ec058906f..ceaee23a4d22 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -222,14 +222,16 @@ static void msm_gpu_crashstate_get_bo(struct
msm_gpu_state *state,
struct drm_gem_object *obj, u64 iova, bool full)
{
struct msm_gpu_state_bo *state_bo = >bos[state->nr_bos];
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
/* Don't record write only objects */
state_bo->size = obj->size;
+ state_bo->flags = msm_obj->flags;
state_bo->iova = iova;
- BUILD_BUG_ON(sizeof(state_bo->name) != sizeof(to_msm_bo(obj)->name));
+ BUILD_BUG_ON(sizeof(state_bo->name) != sizeof(msm_obj->name));
- memcpy(state_bo->name, to_msm_bo(obj)->name, sizeof(state_bo->name));
+ memcpy(state_bo->name, msm_obj->name, sizeof(state_bo->name));
if (full) {
void *ptr;
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 685470b84708..05bb247e7210 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -527,6 +527,7 @@ struct msm_gpu_submitqueue {
struct msm_gpu_state_bo {
u64 iova;
size_t size;
+ u32 flags;
void *data;
bool encoded;
char name[32];
--
2.45.0
Re: drm/bridge: adv7511: Attach next bridge without creating connector
Hi,
On 5/13/24 16:02, Liu Ying wrote:
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.
If the next bridge is a HDMI connector, the next bridge driver
would fail to attach bridge from display_connector_attach() without
the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
Add that flag to drm_bridge_attach() function call in
adv7511_bridge_attach() to fix the issue.
This fixes the issue where the HDMI connector bridge fails to attach
to the previous ADV7535 bridge on i.MX8MP EVK platform:
[2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/hdmi-connector to encoder None-37: -22
[2.220675] mmc1: SDHCI controller on 30b5.mmc [30b5.mmc] using ADMA
[2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@3080/i2c@30a3/hdmi@3d to encoder None-37: -22
[2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@32c0/dsi@32e6 to encoder None-37: -22
[2.256445] imx-lcdif 32e8.display-controller: error -EINVAL: Failed to
attach bridge for endpoint0
[2.265850] imx-lcdif 32e8.display-controller: error -EINVAL: Cannot
connect bridge
[2.274009] imx-lcdif 32e8.display-controller: probe with driver
imx-lcdif failed with error -22
Indeed, looks safer finally.
Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in DT")
Signed-off-by: Liu Ying
Acked-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index dd21b81bd28f..66ccb61e2a66 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -953,7 +953,8 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
int ret = 0;
if (adv->next_bridge) {
- ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
bridge, flags);
+ ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
bridge,
+ flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
return ret;
}
--
Best regards
Sui Jingfeng
Re: [PATCH v4 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
Hi,
On Mon, May 13, 2024 at 2:30 AM Maxime Ripard wrote:
>
> Hi,
>
> On Wed, May 08, 2024 at 01:51:46PM -0700, Douglas Anderson wrote:
> > Through a cooperative effort between Hsin-Yi Wang and Dmitry
> > Baryshkov, we have realized the dev_err() in the
> > mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
> > kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
> > version of the functions that includes the print. While doing this,
> > add a bit more comments to these macros making it clear that they
> > print errors and also that they return out of _the caller's_ function.
> >
> > Without any changes to clients this gives a nice savings. Specifically
> > the macro was inlined and thus the error report call was inlined into
> > every call to mipi_dsi_dcs_write_seq() and
> > mipi_dsi_generic_write_seq(). By using a call to a "chatty" function,
> > the usage is reduced to one call in the chatty function and a function
> > call at the invoking site.
> >
> > Building with my build system shows one example:
> >
> > $ scripts/bloat-o-meter \
> > .../before/panel-novatek-nt36672e.ko \
> > .../after/panel-novatek-nt36672e.ko
> > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-4404 (-4404)
> > Function old new delta
> > nt36672e_1080x2408_60hz_init 106406236 -4404
> > Total: Before=15055, After=10651, chg -29.25%
> >
> > Note that given the change in location of the print it's harder to
> > include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since,
> > theoretically, someone could call the new chatty function with a
> > zero-size array and it would be illegal to dereference data[0].
> > There's a printk format to print the whole buffer and this is probably
> > more useful for debugging anyway. Given that we're doing this for
> > mipi_dsi_dcs_write_seq(), let's also print the buffer for
> > mipi_dsi_generic_write_seq() in the error case.
> >
> > It should be noted that the current consensus of DRM folks is that the
> > mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive
> > return behavior. A future patch will formally mark them as deprecated
> > and provide an alternative.
> >
> > Reviewed-by: Dmitry Baryshkov
> > Reviewed-by: Neil Armstrong
> > Reviewed-by: Linus Walleij
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > Changes in v4:
> > - Update wording as per Linus W.
> >
> > Changes in v3:
> > - Rebased upon patch to remove ratelimit of prints.
> >
> > Changes in v2:
> > - Add some comments to the macros about printing and returning.
> > - Change the way err value is handled in prep for next patch.
> > - Modify commit message now that this is part of a series.
> > - Rebased upon patches to avoid theoretical int overflow.
> >
> > drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
> > include/drm/drm_mipi_dsi.h | 47 +++-
> > 2 files changed, 82 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> > index 795001bb7ff1..8593d9ed5891 100644
> > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > @@ -764,6 +764,34 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device
> > *dsi, const void *payload,
> > }
> > EXPORT_SYMBOL(mipi_dsi_generic_write);
> >
> > +/**
> > + * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error
> > log
> > + * @dsi: DSI peripheral device
> > + * @payload: buffer containing the payload
> > + * @size: size of payload buffer
> > + *
> > + * Like mipi_dsi_generic_write() but includes a dev_err_ratelimited()
>
> You mention in both functions that it's calling dev_err_ratelimited() ...
>
> > + * call for you and returns 0 upon success, not the number of bytes sent.
> > + *
> > + * Return: 0 on success or a negative error code on failure.
> > + */
> > +int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
> > + const void *payload, size_t size)
> > +{
> > + struct device *dev = >dev;
> > + ssize_t ret;
> > +
> > + ret = mipi_dsi_generic_write(dsi, payload, size);
> > + if (ret < 0) {
> > + dev_err(dev, "sending generic data %*ph failed: %zd\n",
> > + (int)size, payload, ret);
>
> ... but it doesn't.
Whoops, thanks for catching this! I'll plan to send a v5 tomorrow to
fix this and then I'll still plan to land the series on Thursday
unless anything major comes up.
-Doug
Re: [PATCH 01/20] drm/drm_managed: try to improve the drmm DOC
On Fri, May 10, 2024 at 07:12:14PM +0100, Matthew Auld wrote:
> Hopefully make it clearer when to use devm vs drmm.
>
> Signed-off-by: Matthew Auld
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_managed.c | 42 +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 7646f67bda4e..20d705bbc0a3 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -34,6 +34,48 @@
> * during the lifetime of the driver, all the functions are fully concurrent
> * safe. But it is recommended to use managed resources only for resources
> that
> * change rarely, if ever, during the lifetime of the _device instance.
> + *
> + * Note that the distinction between devm and drmm is important to get right.
> + * Consider some hotunplug scenarios, where it is valid for there to be
> multiple
> + * unplugged struct _device instances each being kept alive by an open
> + * driver fd. The driver needs a clean separation between what needs to
> happen
> + * when the struct is removed and what needs to happen when a given
> + * struct _device instance is released, as well as in some cases a more
> + * finer grained marking of critical sections that require hardware
> interaction.
> + * See below.
> + *
> + * devm
> + *
> + * In general use devm for cleaning up anything hardware related. So removing
> + * pci mmaps, releasing interrupt handlers, basically anything hw related.
> The
^
Extra space.
> + * devm release actions are called when the struct is removed,
> shortly
> + * after calling into the drivers struct _driver.remove() callback, if
> this
> + * is a pci device.
> + *
> + * devm can be thought of as an alternative to putting all the hw related
nit: perhaps s/thought/seen ?
> + * cleanup directly in the struct _driver.remove() callback, where the
> + * correct ordering of the unwind steps needs to be manually done in the
> error
> + * path of the struct _driver.probe() and again on the remove side. With
> + * devm this is all done automatically.
> + *
> + * drmm
> + *
> + * In general use this for cleaning up anything software related. So data
> + * structures and the like which are tied to the lifetime of a particular
> struct
> + * _device instance.
> + *
> + * drmm can be thought of as an alternative to putting all the software
> related
nit: perhaps s/thought/seen ?
> + * cleanup directly in the struct _driver.release() callback, where again
> + * the correct ordering of the unwind steps needs to be done manually. As
> with
> + * devm this is instead done automatically.
> + *
> + * Sometimes there is no clean separation between software and hardware,
> which
> + * is where drm_dev_enter() comes in. For example, a driver might have some
> + * state tied to a struct _device instance, for which the same cleanup
> path
> + * is called for both a plugged and unplugged device, and the cleanup itself
> + * might require talking to the device if it's still attached to this
> particular
> + * struct _device. For that we instead mark the device sections. See
> + * drm_dev_enter(), drm_dev_exit() and drm_dev_unplug().
perhaps open up a bit more here?
anyway, everything looks good to me.
Sima, thoughts?
> */
>
> struct drmres_node {
> --
> 2.45.0
>
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.1/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
[PATCH v2 12/12] drm/bridge: analogix: Remove redundant checks on existence of bridge->encoder
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it fails for some reasons, hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various bridge attach functions
are called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 5 -
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 5 -
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 -
drivers/gpu/drm/bridge/analogix/anx7625.c | 10 --
4 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index c9e35731e6a1..cfe43d2ca3be 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -528,11 +528,6 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
/* Register aux channel */
anx6345->aux.name = "DP-AUX";
anx6345->aux.dev = >client->dev;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 5748a8581af4..58875dde496f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -897,11 +897,6 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
/* Register aux channel */
anx78xx->aux.name = "DP-AUX";
anx78xx->aux.dev = >client->dev;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index df9370e0ff23..7b841232321f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1228,11 +1228,6 @@ static int analogix_dp_bridge_attach(struct drm_bridge
*bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
if (!dp->plat_data->skip_connector) {
connector = >connector;
connector->polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 59e9ad349969..3d09efa4199c 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2193,11 +2193,6 @@ static int anx7625_bridge_attach(struct drm_bridge
*bridge,
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
return -EINVAL;
- if (!bridge->encoder) {
- DRM_DEV_ERROR(dev, "Parent encoder object not found");
- return -ENODEV;
- }
-
ctx->aux.drm_dev = bridge->dev;
err = drm_dp_aux_register(>aux);
if (err) {
@@ -2435,11 +2430,6 @@ static void anx7625_bridge_atomic_enable(struct
drm_bridge *bridge,
dev_dbg(dev, "drm atomic enable\n");
- if (!bridge->encoder) {
- dev_err(dev, "Parent encoder object not found");
- return;
- }
-
connector = drm_atomic_get_new_connector_for_encoder(state->base.state,
bridge->encoder);
if (!connector)
--
2.43.0
[PATCH v2 11/12] drm/bridge: imx: Remove redundant checks on existence of bridge->encoder
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it fails for some reasons, hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various i.MX specific bridge
attach functions are called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 5 -
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 5 -
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 5 -
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c| 5 -
4 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
index 6967325cd8ee..9b5bebbe357d 100644
--- a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -116,11 +116,6 @@ int ldb_bridge_attach_helper(struct drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_DEV_ERROR(ldb->dev, "missing encoder\n");
- return -ENODEV;
- }
-
return drm_bridge_attach(bridge->encoder,
ldb_ch->next_bridge, bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
index d0868a6ac6c9..e6dbbdc87ce2 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -119,11 +119,6 @@ static int imx8qxp_pc_bridge_attach(struct drm_bridge
*bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_DEV_ERROR(pc->dev, "missing encoder\n");
- return -ENODEV;
- }
-
return drm_bridge_attach(bridge->encoder,
ch->next_bridge, bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
index ed8b7a4e0e11..1d11cc1df43c 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -138,11 +138,6 @@ static int imx8qxp_pixel_link_bridge_attach(struct
drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_DEV_ERROR(pl->dev, "missing encoder\n");
- return -ENODEV;
- }
-
return drm_bridge_attach(bridge->encoder,
pl->next_bridge, bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index 4a886cb808ca..fb7cf4369bb8 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -58,11 +58,6 @@ static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge
*bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
- return -ENODEV;
- }
-
return drm_bridge_attach(bridge->encoder,
p2d->next_bridge, bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
--
2.43.0
[PATCH v2 10/12] drm/bridge: lt9611uxc: Remove a redundant check on existence of bridge->encoder
In the lt9611uxc_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder member of the struct drm_bridge is not NULL when
lt9611uxc_connector_init() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index ab702471f3ab..f864c033ba81 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -337,11 +337,6 @@ static int lt9611uxc_connector_init(struct drm_bridge
*bridge, struct lt9611uxc
{
int ret;
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
lt9611uxc->connector.polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_helper_add(>connector,
--
2.43.0
[PATCH v2 09/12] drm/bridge: synopsys: dw-mipi-dsi: Remove a redundant check on existence of bridge->encoder
In the dw_mipi_dsi_bridge_attach() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function invocked by previous bridge or KMS driver.
The previous drm_bridge_attach() will quit with a negative error code
returned if it fails for some reasons, hence, it is guaranteed that the
.encoder member of the struct drm_bridge is not NULL when
dw_mipi_dsi_bridge_attach() function gets called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 824fb3c65742..c4e9d96933dc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -1071,11 +1071,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge,
{
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found\n");
- return -ENODEV;
- }
-
/* Set the encoder type as caller does not know it */
bridge->encoder->encoder_type = DRM_MODE_ENCODER_DSI;
--
2.43.0
[PATCH v2 08/12] drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: Remove a redundant check on existence of bridge->encoder
In the ge_b850v3_lvds_create_connector function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in the
drm_bridge_attach() function called by upstream bridge or driver. Hence, it
is guaranteed that the .encoder member of the drm_bridge instance is not
NULL when cdns_mhdp_connector_init() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 4480523244e4..37f1acf5c0f8 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -165,11 +165,6 @@ static int ge_b850v3_lvds_create_connector(struct
drm_bridge *bridge)
struct drm_connector *connector = _b850v3_lvds_ptr->connector;
int ret;
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
connector->polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_helper_add(connector,
--
2.43.0
[PATCH v2 07/12] drm/bridge: cdns-mhdp8546: Remove a redundant check on existence of bridge->encoder
In the cdns_mhdp_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. As the cdns_mhdp_connector_init() is
only called by cdns_mhdp_attach(), it is guaranteed that the .encoder
member of the struct drm_bridge is not NULL when cdns_mhdp_attach() gets
called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 8a91ef0ae065..dee640ab1d3a 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1697,11 +1697,6 @@ static int cdns_mhdp_connector_init(struct
cdns_mhdp_device *mhdp)
struct drm_bridge *bridge = >bridge;
int ret;
- if (!bridge->encoder) {
- dev_err(mhdp->dev, "Parent encoder object not found");
- return -ENODEV;
- }
-
conn->polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(bridge->dev, conn, _mhdp_conn_funcs,
--
2.43.0
[PATCH v2 06/12] drm/bridge: adv7511: Remove a redundant check on existence of bridge->encoder
In the adv7511_connector_init() function, the check on the existence of
bridge->encoder is not necessary. As it has already been checked in the
drm_bridge_attach() which happens prior to the adv7511_bridge_attach()
get called. Also note that the adv7511_connector_init() is only called by
adv7511_bridge_attach(). Hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when adv7511_connector_init() get
called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index dd21b81bd28f..6089b0bb9321 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -877,11 +877,6 @@ static int adv7511_connector_init(struct adv7511 *adv)
struct drm_bridge *bridge = >bridge;
int ret;
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
if (adv->i2c_main->irq)
adv->connector.polled = DRM_CONNECTOR_POLL_HPD;
else
--
2.43.0
[PATCH v2 05/12] drm/bridge: it6505: Remove a redundant check on existence of bridge->encoder
In it6505_bridge_attach(), the check on the existence of 'bridge->encoder'
is not necessary, as it has already been checked in the drm_bridge_attach()
which happens prior to it6505_bridge_attach() get called. Note that the
it6505_bridge_attach() will only be called by .attach() of the previous
bridge or KMS driver. The previous drm_bridge_attach() will quit with a
negative error code returned if it fails for some reasons. Hence, it is
guaranteed that the .encoder member of the drm_bridge instance is not NULL
when it6505_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it6505.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index 3f68c82888c2..469157341f3a 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2882,11 +2882,6 @@ static int it6505_bridge_attach(struct drm_bridge
*bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- dev_err(dev, "Parent encoder object not found");
- return -ENODEV;
- }
-
/* Register aux channel */
it6505->aux.drm_dev = bridge->dev;
--
2.43.0
[PATCH v2 04/12] drm/bridge: panel: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the panel_bridge_attach() function get called, and the drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when panel_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/panel.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 32506524d9a2..56c40b516a8f 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -67,11 +67,6 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return 0;
- if (!bridge->encoder) {
- DRM_ERROR("Missing encoder\n");
- return -ENODEV;
- }
-
drm_connector_helper_add(connector,
_bridge_connector_helper_funcs);
--
2.43.0
[PATCH v2 03/12] drm/bridge: nxp-ptn3460: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the ptn3460_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the ptn3460_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index ed93fd4c3265..e77aab965fcf 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -229,11 +229,6 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return 0;
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(bridge->dev, _bridge->connector,
_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
--
2.43.0
[PATCH v2 01/12] drm/bridge: simple-bridge: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the simple_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the simple_bridge_attach() get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
b/drivers/gpu/drm/bridge/simple-bridge.c
index 5813a2c4fc5e..2ca89f313cd1 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -116,11 +116,6 @@ static int simple_bridge_attach(struct drm_bridge *bridge,
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return 0;
- if (!bridge->encoder) {
- DRM_ERROR("Missing encoder\n");
- return -ENODEV;
- }
-
drm_connector_helper_add(>connector,
_bridge_con_helper_funcs);
ret = drm_connector_init_with_ddc(bridge->dev, >connector,
--
2.43.0
[PATCH v2 02/12] drm/bridge: tfp410: Remove a redundant check on existence of bridge->encoder
Because the existence of bridge->encoder has already been checked before
the simple_bridge_attach() function get called, And drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the tfp410_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Reviewed-by: Laurent Pinchart
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ti-tfp410.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index c7bef5c23927..b1b1e4d5a24a 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -133,11 +133,6 @@ static int tfp410_attach(struct drm_bridge *bridge,
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return 0;
- if (!bridge->encoder) {
- dev_err(dvi->dev, "Missing encoder\n");
- return -ENODEV;
- }
-
if (dvi->next_bridge->ops & DRM_BRIDGE_OP_DETECT)
dvi->connector.polled = DRM_CONNECTOR_POLL_HPD;
else
--
2.43.0
[PATCH v2 00/12] Remove redundant checks on existence of 'bridge->encoder'
The checks on the existence of bridge->encoder in the implementation of drm_bridge_funcs::attach() is not necessary, as it has already been checked in the drm_bridge_attach() function call by previous bridge or KMS driver. The drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons, hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when various bridge attach functions are called. V1 -> V2: * Gather all similar patches to form a series (Laurent) * Fix various spell error (Laurent) * Correct commit message for bridges of i.MX (Ying) Sui Jingfeng (12): drm/bridge: simple-bridge: Remove a redundant check on existence of bridge->encoder drm/bridge: tfp410: Remove a redundant check on existence of bridge->encoder drm/bridge: nxp-ptn3460: Remove a redundant check on existence of bridge->encoder drm/bridge: panel: Remove a redundant check on existence of bridge->encoder drm/bridge: it6505: Remove a redundant check on existence of bridge->encoder drm/bridge: adv7511: Remove a redundant check on existence of bridge->encoder drm/bridge: cdns-mhdp8546: Remove a redundant check on existence of bridge->encoder drm/bridge: megachips-stdp-ge-b850v3-fw: Remove a redundant check on existence of bridge->encoder drm/bridge: synopsys: dw-mipi-dsi: Remove a redundant check on existence of bridge->encoder drm/bridge: lt9611uxc: Remove a redundant check on existence of bridge->encoder drm/bridge: imx: Remove redundant checks on existence of bridge->encoder drm/bridge: analogix: Remove redundant checks on existence of bridge->encoder drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 - drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 5 - drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 5 - drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 - drivers/gpu/drm/bridge/analogix/anx7625.c | 10 -- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c| 5 - drivers/gpu/drm/bridge/imx/imx-ldb-helper.c| 5 - drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 5 - drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c| 5 - drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 5 - drivers/gpu/drm/bridge/ite-it6505.c| 5 - drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 5 - .../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 5 - drivers/gpu/drm/bridge/nxp-ptn3460.c | 5 - drivers/gpu/drm/bridge/panel.c | 5 - drivers/gpu/drm/bridge/simple-bridge.c | 5 - drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 5 - drivers/gpu/drm/bridge/ti-tfp410.c | 5 - 18 files changed, 95 deletions(-) -- 2.43.0
Re: /sys/kernel/debug/vgaswitcheroo directory missing
Revert "drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()" a222a6470d7eea91193946e8162066fa88da64c2 The errors I reported are the same as those quoted in the pull request for the revert. On 13/05/2024 08:43, Jani Nikula wrote: > On Sat, 11 May 2024, Chris Clayton wrote: >> Mmm, I see a patch has made it's way to mainline and can confirm that >> it fixes the problems I tbothered you with in this thread. > > Which patch? Might be interesting for posterity. > > BR, > Jani. > >
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1068,7 +1068,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-5.15/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-5.10/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-5.4/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1064,7 +1064,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-4.19/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.6/drm-ttm-print-the-memory-decryption-status-just-once.patch
queue-6.6/drm-vmwgfx-fix-legacy-display-unit.patch
queue-6.6/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/ttm: Print the memory decryption status just once" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/ttm: Print the memory decryption status just once
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ttm-print-the-memory-decryption-status-just-once.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 27906e5d78248b19bcdfdae72049338c828897bb Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Mon, 8 Apr 2024 11:56:05 -0400
Subject: drm/ttm: Print the memory decryption status just once
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Zack Rusin
commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.
Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.
Reduces the spam in the system logs when running guests with SEV enabled.
Signed-off-by: Zack Rusin
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when
needed")
Reviewed-by: Christian König
Cc: Thomas Hellström
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v5.14+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 578a7c37f00b..d776e3f87064 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
*/
if (bdev->pool.use_dma_alloc &&
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
- drm_info(ddev, "TT memory decryption enabled.");
+ drm_info_once(ddev, "TT memory decryption enabled.");
}
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
--
2.45.0
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.6/drm-ttm-print-the-memory-decryption-status-just-once.patch
queue-6.6/drm-vmwgfx-fix-legacy-display-unit.patch
queue-6.6/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/vmwgfx: Fix invalid reads in fence signaled events" has been added to the 6.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
and it can be found in the queue-6.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 25 Apr 2024 15:27:48 -0400
Subject: drm/vmwgfx: Fix invalid reads in fence signaled events
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
Signed-off-by: Zack Rusin
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie
CC: Daniel Vetter
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v3.4+
Reviewed-by: Maaz Mombasawala
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
- event->event.base.length = sizeof(*event);
+ event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.8/drm-ttm-print-the-memory-decryption-status-just-once.patch
queue-6.8/drm-vmwgfx-fix-legacy-display-unit.patch
queue-6.8/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Patch "drm/ttm: Print the memory decryption status just once" has been added to the 6.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/ttm: Print the memory decryption status just once
to the 6.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ttm-print-the-memory-decryption-status-just-once.patch
and it can be found in the queue-6.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 27906e5d78248b19bcdfdae72049338c828897bb Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Mon, 8 Apr 2024 11:56:05 -0400
Subject: drm/ttm: Print the memory decryption status just once
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Zack Rusin
commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.
Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.
Reduces the spam in the system logs when running guests with SEV enabled.
Signed-off-by: Zack Rusin
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when
needed")
Reviewed-by: Christian König
Cc: Thomas Hellström
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: # v5.14+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_obje
*/
if (bdev->pool.use_dma_alloc &&
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
- drm_info(ddev, "TT memory decryption enabled.");
+ drm_info_once(ddev, "TT memory decryption enabled.");
}
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.8/drm-ttm-print-the-memory-decryption-status-just-once.patch
queue-6.8/drm-vmwgfx-fix-legacy-display-unit.patch
queue-6.8/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch
Re: [PATCH v2 2/2] drm/tests: Add a unit test for range bias allocation
On 13/05/2024 16:11, Paneer Selvam, Arunpravin wrote: Hi Matthew, On 5/13/2024 1:49 PM, Matthew Auld wrote: On 12/05/2024 08:59, Arunpravin Paneer Selvam wrote: Allocate cleared blocks in the bias range when the DRM buddy's clear avail is zero. This will validate the bias range allocation in scenarios like system boot when no cleared blocks are available and exercise the fallback path too. The resulting blocks should always be dirty. Signed-off-by: Arunpravin Paneer Selvam --- drivers/gpu/drm/tests/drm_buddy_test.c | 35 ++ 1 file changed, 35 insertions(+) diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests/drm_buddy_test.c index e3b50e240d36..a194f271bc55 100644 --- a/drivers/gpu/drm/tests/drm_buddy_test.c +++ b/drivers/gpu/drm/tests/drm_buddy_test.c @@ -26,6 +26,8 @@ static void drm_test_buddy_alloc_range_bias(struct kunit *test) u32 mm_size, ps, bias_size, bias_start, bias_end, bias_rem; DRM_RND_STATE(prng, random_seed); unsigned int i, count, *order; + struct drm_buddy_block *block; + unsigned long flags; struct drm_buddy mm; LIST_HEAD(allocated); @@ -222,6 +224,39 @@ static void drm_test_buddy_alloc_range_bias(struct kunit *test) drm_buddy_free_list(, , 0); drm_buddy_fini(); + + /* + * Allocate cleared blocks in the bias range when the DRM buddy's clear avail is + * zero. This will validate the bias range allocation in scenarios like system boot + * when no cleared blocks are available and exercise the fallback path too. The resulting + * blocks should always be dirty. + */ + + KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_init(, mm_size, ps), + "buddy_init failed\n"); + mm.clear_avail = 0; Should already be zero, right? Maybe make this an assert instead? No, since the mm declared as a local variable in the test case, mm.clear_avail is not zero. That sounds like a bug IMO. The init() should initialize it, like it does for mm.avail and everything else. + + bias_start = round_up(prandom_u32_state() % (mm_size - ps), ps); + bias_end = round_up(bias_start + prandom_u32_state() % (mm_size - bias_start), ps); + bias_end = max(bias_end, bias_start + ps); + bias_rem = bias_end - bias_start; + + flags = DRM_BUDDY_CLEAR_ALLOCATION | DRM_BUDDY_RANGE_ALLOCATION; + u32 size = max(round_up(prandom_u32_state() % bias_rem, ps), ps); u32 declaration should be moved to above? Sure. Thanks, Arun. Otherwise, Reviewed-by: Matthew Auld + + KUNIT_ASSERT_FALSE_MSG(test, + drm_buddy_alloc_blocks(, bias_start, + bias_end, size, ps, + , + flags), + "buddy_alloc failed with bias(%x-%x), size=%u, ps=%u\n", + bias_start, bias_end, size, ps); + + list_for_each_entry(block, , link) + KUNIT_EXPECT_EQ(test, drm_buddy_block_is_clear(block), false); + + drm_buddy_free_list(, , 0); + drm_buddy_fini(); } static void drm_test_buddy_alloc_clear(struct kunit *test)
Re: [PATCH] nouveau/firmware: using dma non-coherent interfaces for fw loading.
Hi Dave,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip linus/master v6.9 next-20240513]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Dave-Airlie/nouveau-firmware-using-dma-non-coherent-interfaces-for-fw-loading/20240513-144435
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240513064350.1050994-1-airlied%40gmail.com
patch subject: [PATCH] nouveau/firmware: using dma non-coherent interfaces for
fw loading.
config: arm-defconfig
(https://download.01.org/0day-ci/archive/20240513/202405132205.fvkltmcq-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240513/202405132205.fvkltmcq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202405132205.fvkltmcq-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:242:12: error: incompatible
>> pointer types passing 'u64 *' (aka 'unsigned long long *') to parameter of
>> type 'dma_addr_t *' (aka 'unsigned int *')
>> [-Werror,-Wincompatible-pointer-types]
len, >phys,
^
include/linux/dma-mapping.h:321:15: note: passing argument to parameter
'dma_handle' here
dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t
gfp)
^
1 error generated.
vim +242 drivers/gpu/drm/nouveau/nvkm/core/firmware.c
224
225 int
226 nvkm_firmware_ctor(const struct nvkm_firmware_func *func, const char
*name,
227 struct nvkm_device *device, const void *src, int
len, struct nvkm_firmware *fw)
228 {
229 fw->func = func;
230 fw->name = name;
231 fw->device = device;
232 fw->len = len;
233
234 switch (fw->func->type) {
235 case NVKM_FIRMWARE_IMG_RAM:
236 fw->img = kmemdup(src, fw->len, GFP_KERNEL);
237 break;
238 case NVKM_FIRMWARE_IMG_DMA: {
239 len = ALIGN(fw->len, PAGE_SIZE);
240
241 fw->img = dma_alloc_noncoherent(fw->device->dev,
> 242 len, >phys,
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH v2 2/2] drm/tests: Add a unit test for range bias allocation
Hi Matthew, On 5/13/2024 1:49 PM, Matthew Auld wrote: On 12/05/2024 08:59, Arunpravin Paneer Selvam wrote: Allocate cleared blocks in the bias range when the DRM buddy's clear avail is zero. This will validate the bias range allocation in scenarios like system boot when no cleared blocks are available and exercise the fallback path too. The resulting blocks should always be dirty. Signed-off-by: Arunpravin Paneer Selvam --- drivers/gpu/drm/tests/drm_buddy_test.c | 35 ++ 1 file changed, 35 insertions(+) diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests/drm_buddy_test.c index e3b50e240d36..a194f271bc55 100644 --- a/drivers/gpu/drm/tests/drm_buddy_test.c +++ b/drivers/gpu/drm/tests/drm_buddy_test.c @@ -26,6 +26,8 @@ static void drm_test_buddy_alloc_range_bias(struct kunit *test) u32 mm_size, ps, bias_size, bias_start, bias_end, bias_rem; DRM_RND_STATE(prng, random_seed); unsigned int i, count, *order; + struct drm_buddy_block *block; + unsigned long flags; struct drm_buddy mm; LIST_HEAD(allocated); @@ -222,6 +224,39 @@ static void drm_test_buddy_alloc_range_bias(struct kunit *test) drm_buddy_free_list(, , 0); drm_buddy_fini(); + + /* + * Allocate cleared blocks in the bias range when the DRM buddy's clear avail is + * zero. This will validate the bias range allocation in scenarios like system boot + * when no cleared blocks are available and exercise the fallback path too. The resulting + * blocks should always be dirty. + */ + + KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_init(, mm_size, ps), + "buddy_init failed\n"); + mm.clear_avail = 0; Should already be zero, right? Maybe make this an assert instead? No, since the mm declared as a local variable in the test case, mm.clear_avail is not zero. + + bias_start = round_up(prandom_u32_state() % (mm_size - ps), ps); + bias_end = round_up(bias_start + prandom_u32_state() % (mm_size - bias_start), ps); + bias_end = max(bias_end, bias_start + ps); + bias_rem = bias_end - bias_start; + + flags = DRM_BUDDY_CLEAR_ALLOCATION | DRM_BUDDY_RANGE_ALLOCATION; + u32 size = max(round_up(prandom_u32_state() % bias_rem, ps), ps); u32 declaration should be moved to above? Sure. Thanks, Arun. Otherwise, Reviewed-by: Matthew Auld + + KUNIT_ASSERT_FALSE_MSG(test, + drm_buddy_alloc_blocks(, bias_start, + bias_end, size, ps, + , + flags), + "buddy_alloc failed with bias(%x-%x), size=%u, ps=%u\n", + bias_start, bias_end, size, ps); + + list_for_each_entry(block, , link) + KUNIT_EXPECT_EQ(test, drm_buddy_block_is_clear(block), false); + + drm_buddy_free_list(, , 0); + drm_buddy_fini(); } static void drm_test_buddy_alloc_clear(struct kunit *test)
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Le lundi 13 mai 2024 à 11:34 +0300, Laurent Pinchart a écrit : > On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote: > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote: > > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote: > > > > Hi, > > > > > > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit : > > > > > Shorter term, we have a problem to solve, and the best option we have > > > > > found so far is to rely on dma-buf heaps as a backend for the frame > > > > > buffer allocatro helper in libcamera for the use case described above. > > > > > This won't work in 100% of the cases, clearly. It's a stop-gap measure > > > > > until we can do better. > > > > > > > > Considering the security concerned raised on this thread with dmabuf > > > > heap > > > > allocation not be restricted by quotas, you'd get what you want quickly > > > > with > > > > memfd + udmabuf instead (which is accounted already). > > > > > > > > It was raised that distro don't enable udmabuf, but as stated there by > > > > Hans, in > > > > any cases distro needs to take action to make the softISP works. This > > > > alternative is easy and does not interfere in anyway with your future > > > > plan or > > > > the libcamera API. You could even have both dmabuf heap (for Raspbian) > > > > and the > > > > safer memfd+udmabuf for the distro with security concerns. > > > > > > > > And for the long term plan, we can certainly get closer by fixing that > > > > issue > > > > with accounting. This issue also applied to v4l2 io-ops, so it would be > > > > nice to > > > > find common set of helpers to fix these exporters. > > > > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I was > > > about to suggest. Not just as a stopgap, but as the real official thing. > > > > > > udmabuf does kinda allow you to pin memory, but we can easily fix that by > > > adding the right accounting and then either let mlock rlimits or cgroups > > > kernel memory limits enforce good behavior. > > > > I think the main drawback with memfd is that it'll be broken for devices > > without an IOMMU, and while you said that it's uncommon for GPUs, it's > > definitely not for codecs and display engines. > > If the application wants to share buffers between the camera and a > display engine or codec, it should arguably not use the libcamera > FrameBufferAllocator, but allocate the buffers from the display or the > encoder. memfd wouldn't be used in that case. > > We need to eat our own dogfood though. If we want to push the > responsibility for buffer allocation in the buffer sharing case to the > application, we need to modify the cam application to do so when using > the KMS backend. > Agreed, and the new dmabuf feedback on wayland can also be used on top of this. You'll hit the same limitation as we hit in GStreamer, which is that KMS driver only offer allocation for render buffers and most of them are missing allocators for YUV buffers, even though they can import in these formats. (kms allocators, except dumb, which has other issues, are format aware). Nicolas
Re: [PATCH 1/2] drm: bridge: samsung-dsim: Initialize bridge on attach
On 5/13/24 9:57 AM, Marek Szyprowski wrote: On 13.05.2024 04:16, Marek Vasut wrote: Initialize the bridge on attach already, to force lanes into LP11 state, since attach does trigger attach of downstream bridges which may trigger (e)DP AUX channel mode read. This fixes a corner case where DSIM with TC9595 attached to it fails to operate the DP AUX channel, because the TC9595 enters some debug mode when it is released from reset without lanes in LP11 mode. By ensuring the DSIM lanes are in LP11, the TC9595 (tc358767.c driver) can be reset in its attach callback called from DSIM attach callback, and recovered out of the debug mode just before TC9595 performs first AUX channel access later in its attach callback. Signed-off-by: Marek Vasut This patch breaks driver operation on Samsung TM2e board with S6E3HF2 DSI panel. The initialization procedure is very fragile and it looks that the changes must be done very carefully. We discussed this many times when converting this driver from Exynos DSI to generic Samsung DSI used on IMX and other SoCs. Clearly we need to find a way to support both use cases . What options do we have ? Does the panel require DSI lanes in some specific state when it is released from reset ?
Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Le lundi 13 mai 2024 à 15:51 +0200, Maxime Ripard a écrit : > On Mon, May 13, 2024 at 09:42:00AM -0400, Nicolas Dufresne wrote: > > Le lundi 13 mai 2024 à 10:29 +0200, Maxime Ripard a écrit : > > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote: > > > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote: > > > > > Hi, > > > > > > > > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit : > > > > > > Shorter term, we have a problem to solve, and the best option we > > > > > > have > > > > > > found so far is to rely on dma-buf heaps as a backend for the frame > > > > > > buffer allocatro helper in libcamera for the use case described > > > > > > above. > > > > > > This won't work in 100% of the cases, clearly. It's a stop-gap > > > > > > measure > > > > > > until we can do better. > > > > > > > > > > Considering the security concerned raised on this thread with dmabuf > > > > > heap > > > > > allocation not be restricted by quotas, you'd get what you want > > > > > quickly with > > > > > memfd + udmabuf instead (which is accounted already). > > > > > > > > > > It was raised that distro don't enable udmabuf, but as stated there > > > > > by Hans, in > > > > > any cases distro needs to take action to make the softISP works. This > > > > > alternative is easy and does not interfere in anyway with your future > > > > > plan or > > > > > the libcamera API. You could even have both dmabuf heap (for > > > > > Raspbian) and the > > > > > safer memfd+udmabuf for the distro with security concerns. > > > > > > > > > > And for the long term plan, we can certainly get closer by fixing > > > > > that issue > > > > > with accounting. This issue also applied to v4l2 io-ops, so it would > > > > > be nice to > > > > > find common set of helpers to fix these exporters. > > > > > > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I > > > > was > > > > about to suggest. Not just as a stopgap, but as the real official thing. > > > > > > > > udmabuf does kinda allow you to pin memory, but we can easily fix that > > > > by > > > > adding the right accounting and then either let mlock rlimits or cgroups > > > > kernel memory limits enforce good behavior. > > > > > > I think the main drawback with memfd is that it'll be broken for devices > > > without an IOMMU, and while you said that it's uncommon for GPUs, it's > > > definitely not for codecs and display engines. > > > > In the context of libcamera, the allocation and the alignment done to the > > video > > frame is done completely blindly. In that context, there is a lot more then > > just > > the allocation type that can go wrong and will lead to a memory copy. The > > upside > > of memfd, is that the read cache will help speeding up the copies if they > > are > > needed. > > dma-heaps provide cacheable buffers too... Yes, and why we have cache hints in V4L2 now. There is no clue that softISP code can read to make the right call. The required cache management in undefined until all the importer are known. I also don't think heaps currently care to adapt the dmabuf sync behaviour based on the different importers, or the addition of a new importer. On top of which, there is insufficient information on the device to really deduce what is needed. > > > Another important point is that this is only used if the application haven't > > provided frames. If your embedded application is non-generic, and you have > > permissions to access the right heap, the application can solve your > > specific > > issue. But in the generic Linux space, Linux kernel API are just > > insufficient > > for the "just work" scenario. > > ... but they also provide semantics around the memory buffers that no > other allocation API do. There's at least the mediatek secure playback > series and another one that I've started to work on to allocate ECC > protected or unprotected buffers that are just the right use case for > the heaps, and the target frameworks aren't. Let's agree we are both off topic now. The libcamera softISP is currently purely software, and cannot write to any form of protected memory. As for ECC, I would hope this usage will be coded in the application and that this application has been authorized to access the appropriate heaps. And finally, none of this fixes the issue that the heap allocation are not being accounted properly and allow of an easy memory DoS. So uaccess should be granted with care, meaning that defaulting a "desktop" library to that, means it will most of the time not work at all. Nicolas
Re: [PATCH v3 05/10] media: dt-bindings: video-interfaces: Support DisplayPort MST
On Tue, 07 May 2024 15:54:08 +, Paweł Anikiel wrote: > Add a DisplayPort bus type and a multi-stream-support property > indicating whether the interface supports MST. > > Signed-off-by: Paweł Anikiel > --- > .../devicetree/bindings/media/video-interfaces.yaml| 7 +++ > include/dt-bindings/media/video-interfaces.h | 2 ++ > 2 files changed, 9 insertions(+) > Reviewed-by: Rob Herring (Arm)
Re: [RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting
On 09.05.24 11:19, Tvrtko Ursulin wrote:
On 08/05/2024 20:08, Friedrich Vock wrote:
On 08.05.24 20:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would
over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration budget spent.
If the migration failed but data was still moved (which I think could be
the case when we try evicting everything but it still doesn't work?),
shouldn't the eviction movements count towards the ratelimit too?
Possibly, which path would that be?
Thinking about it more, the only case where allocation still won't
succeed after evicting everything from a place is the edge case when the
buffer is larger than the place's size.
The most likely condition for this to happen (without the submission
failing entirely because the buffer just doesn't fit anywhere) would be
if the app tries creating a 256MB+ visible-VRAM buffer if resizeable BAR
is disabled.
This case could potentially trigger an allocation failure when trying
with preferred_domains, but retrying with allowed_domains, which
includes GTT, could subsequently work.
I mean there are definitely more migration which *should not* be
counted which I think your mini-series approaches more accurately.
What this patch achieves, in its current RFC form, is reduces the
"false-positive" migration budget depletions.
So larger improvements aside, point of the series was to illustrate
that even the things which were said to be working do not seem to. See
cover letter to see what I thought does not work either well or at all.
Fair point. If this patchset does "wrong"/inaccurate accounting in a
different way that improves the experience, then it's still an improvement.
Fix it by looking at the before and after buffer object backing
store and
only account if there was a change.
FIXME:
I think this needs a better solution to account for migrations between
VRAM visible and non-visible portions.
FWIW, I have some WIP patches (not posted on any MLs yet though) that
attempt to solve this issue (+actually enforcing ratelimits) by moving
the ratelimit accounting/enforcement to TTM entirely.
By moving the accounting to TTM we can count moved bytes when we move
them, and don't have to rely on comparing resources to determine whether
moving actually happened. This should address your FIXME as well.
Yep, I've seen them. They are not necessarily conflicting with this
series, potentialy TTM placement flag aside. *If* something like this
can be kept small and still manage to fix up a few simple things which
do not appear to work at all at the moment.
For the larger re-work it is quite, well, large and it is not easy to
be certain the end result would work as expected. IMO it would be best
to sketch out a larger series which brings some practical and
masurable change in behaviour before commiting to merge things piecemeal.
Yeah, fully agree. Getting something working and iterating on that based
on the results you get seems like the best way forward, that's what I'll
be focusing on for now.
Thanks,
Friedrich
For instance I have a niggling feeling the runtime games driver plays
with placements and domains are not great and wonder if things could
be cleaner if simplified by letting TTM manage things more, more
explicitly, and having the list of placements more static. Thinking
about it seems a step too far for now though.
Regards,
Tvrtko
Regards,
Friedrich
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26
+-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ec888fc6ead8..22708954ae68 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param,
struct amdgpu_bo *bo)
.no_wait_gpu = false,
.resv = bo->tbo.base.resv
};
+ struct ttm_resource *old_res;
uint32_t domain;
int r;
if (bo->tbo.pin_count)
return 0;
+ old_res = bo->tbo.resource;
+
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
@@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param,
struct amdgpu_bo *bo)
amdgpu_bo_placement_from_domain(bo, domain);
r = ttm_bo_validate(>tbo, >placement, );
- p->bytes_moved += ctx.bytes_moved;
- if (!amdgpu_gmc_vram_full_visible(>gmc) &&
- amdgpu_res_cpu_visible(adev, bo->tbo.resource))
- p->bytes_moved_vis += ctx.bytes_moved;
-
if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
domain = bo->allowed_domains;
goto retry;
}
+ if (!r) {
+
