On Fri, Jul 05, 2019 at 02:23:48PM +0200, Daniel Vetter wrote:
> On Fri, Jul 05, 2019 at 11:44:16AM +, james qian wang (Arm Technology
> China) wrote:
> > Since the property slave_planes have been removed, to avoid the resource
> > assignment problem in user disable slave pipeline support
Enable image enhancer when the input data flow is 2x+ upscaling.
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 7 ++-
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 4
For layer_split no need user to enable/disable it, but compute it in
komeda internally, komeda will enable it if the scaling exceed the
acceptable range of scaler.
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h | 3 ++-
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #39 from Samuel Sieb ---
(In reply to shadow.archemage from comment #37)
> I tried the kernel parameters above, and the game still crashed for me.
Are you saying that the game is crashing or the graphics device is?
--
You are
On Fri, Jul 5, 2019 at 8:12 PM Mark Brown wrote:
>
> On Fri, Jul 05, 2019 at 03:08:37PM +0800, Tzung-Bi Shih wrote:
> > On Fri, Jul 5, 2019 at 12:26 PM Cheng-Yi Chiang
> > wrote:
>
> > > +typedef void (*hdmi_codec_plugged_cb)(struct platform_device *dev,
> > > +
On Fri, Jul 05, 2019 at 09:57:37PM +0800, Liviu Dudau wrote:
> On Fri, Jul 05, 2019 at 02:10:06PM +0200, Daniel Vetter wrote:
> > From discussions with Liviu it sounded like the komeda team would
> > benefit a bit from more cross-review with other drivers. To make sure
> > komeda is aligned with
Hi all,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/dma-buf/dma-buf.c: In function 'dma_buf_fs_mount':
drivers/dma-buf/dma-buf.c:65:9: error: implicit declaration of function
'mount_pseudo'; did you mean 'mount_bdev'?
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
include/uapi/linux/magic.h
between commit:
ea8157ab2ae5 ("zsfold: Convert zsfold to use the new mount API")
from the vfs tree and commit:
ed63bb1d1f84 ("dma-buf: give each buffer a full-fledged inode")
from the drm
https://bugs.freedesktop.org/show_bug.cgi?id=110924
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111082
nuc...@hotmail.com changed:
What|Removed |Added
Resolution|NOTABUG |FIXED
--- Comment #2 from
Hi Jacopo,
Thank you for the patch.
On Sat, Jul 06, 2019 at 04:07:38PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-N device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
>
Hi Jacopo,
Thank you for the patch.
On Sat, Jul 06, 2019 at 04:07:30PM +0200, Jacopo Mondi wrote:
> Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
> match what's in in the documentation example.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #3 from Timothy Arceri ---
Are you able to build mesa from git and do a git bisect to find the problem
commit?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111082
Bug ID: 111082
Summary: Severe stutter in CS:GO surf servers, despite ~300fps
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi all,
On Wed, 3 Jul 2019 17:09:16 -0400 Alex Deucher wrote:
>
> On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix wrote:
> >
> > On 2019-07-03 10:10 a.m., Jason Gunthorpe wrote:
> > > On Wed, Jul 03, 2019 at 01:55:08AM +, Kuehling, Felix wrote:
> > >> From: Philip Yang
> > >>
> > >> In
https://bugs.freedesktop.org/show_bug.cgi?id=111081
Bug ID: 111081
Summary: OS Fails to Boot to Runlevel 5
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
3 files
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 6
drivers/gpu/drm/omapdrm/omap_encoder.c | 44
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
drivers/gpu/drm/omapdrm/omap_drv.c| 7 ---
3 files changed, 4 insertions(+), 13
Now that the omap_connector is used for DSI only we can simplify its
implementation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 31 ++--
1 file changed, 2 insertions(+), 29 deletions(-)
diff --git
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index
Group functions based on their purpose and split them in sections to
make the source code easier to navigate.
No functional change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 146 --
1 file changed, 79 insertions(+), 67
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 32 ---
1
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01,
NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the
omapdrm-specific drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 38 -
drivers/gpu/drm/omapdrm/displays/Makefile |
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 86 -
1 file changed, 35 insertions(+), 51
Now that the VENC output is driven fully through the drm_bridge API its
omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 45 --
1 file changed, 45 deletions(-)
diff --git
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 96 -
1 file changed, 40 insertions(+), 56
Due to the removal of several omapdrm display drivers, the omapdss HPD,
detected and EDID operations are not used anymore. Remove them and all
related code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 59 ---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 44
Now that the HDMI outputs are driven fully through the drm_bridge API
their omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 18 --
The TPD12S015, OPA362 and analog and HDMI connectors are now supported
by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
handled through the drm_bridge API. Switch the outputs to drm_brdige by
making the next bridge mandatory and removing the related
omapdrm-specific display
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
drivers/gpu/drm/omapdrm/omap_encoder.c | 26 --
2 files changed, 29
In order to integrate with a chain of drm_bridge, the internal VENC
encoder has to expose the mode valid, fixup and set, the enable and
disable and the get modes operations through the drm_bridge API.
Register a bridge at initialisation time to do so.
Most of those operations are removed from the
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signed-off-by: Laurent Pinchart
---
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signed-off-by: Laurent Pinchart
---
In order to integrate with a chain of drm_bridge, the internal HDMI4
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on
In order to integrate with a chain of drm_bridge, the internal HDMI5
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 89 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 48 +++--
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 94 +++-
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 59 +++
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 34
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 22 ++-
In order to support drm_bridge-based pipeline, the internal HDMI
encoders will need to expose the EDID read operation through the
drm_bridge API, and thus to expose a drm_bridge instance corresponding
to the encoder. The HDMI encoders are however handled as omap_dss_device
instances, which
As part of the move to drm_bridge ops for some of the internal encoders
will be removed. Make them optional in the driver to ease the
transition.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 21 -
drivers/gpu/drm/omapdrm/dss/dss.c|
The DSS core looks up the next device connected to an output by
traversing the OF graph. It currently hardcodes the local port number to
0, which breaks any output with a different port number (SDI on OMAP3
and any DPI output but the first one). Fix this by repurposing the
currently unused
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 12
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 +++
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can
be accessed directly from the connector's display info.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 11 ---
drivers/gpu/drm/omapdrm/omap_connector.h | 1 -
The omapdrm driver attaches to panels with drm_panel_attach() at probe
time but never calls drm_panel_detach(). Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
This panel is used on the Nokia N900.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/Kconfig| 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 691 +++
3 files changed, 700 insertions(+)
This panel is used on the OpenMoko Neo FreeRunner and Neo 1973.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/Kconfig| 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 382 +++
3 files
This panel is used on the SDP3430.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 231 ++
3 files changed, 239 insertions(+)
create
This panel is used on the Zoom2/3/3630 SDP boards.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 249 +++
3 files changed, 257
This panel is used on the Gumstix Overo Palo35.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 235 ++
3 files changed, 243 insertions(+)
The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB
parallel data interface and an SPI control interface.
Signed-off-by: Laurent Pinchart
---
.../bindings/display/panel/nec,nl8048hl11.txt | 38 +++
1 file changed, 38 insertions(+)
create mode 100644
The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor
prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and
document it as legacy.
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2
LG Display is an LCD display manufacturer. Originally formed as a joint
venture by LG Electronics and Philips Electronics, it was formerly known
as LG.Philips LCD, hence the DT vendor prefix lgphilips (which is
already in active use in the kernel).
More information is available at
The tfp410 driver can operate as part of a pipeline where the
drm_connector is created by the display controller. Enable this mode of
operation by skipping creation of a drm_connector internally.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
1 file changed, 1
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations to the next bridge. This
brings us one step
The drmP.h header is deprecated, replace it with the headers
specifically needed by the tfp410 driver. While at it, replace the DRM
print macros with dev_info() and dev_err() instead of including
drm_print.h
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
1
Implement the newly added bridge connector operations, allowing the
usage of drm_bridge_panel with drm_bridge_connector.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/panel.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig| 8 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ti-tpd12s015.c |
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix this, implement a bridge driver for display
To support implementation of DRM connectors on top of DRM bridges
instead of by bridges, the drm_bridge needs to expose new operations and
data:
- Output detection, hot-plug notification, mode retrieval and EDID
retrieval operations
- Bitmask of supported operations
- Bridge output type
Add
The TI OP362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
On Sun, Jul 7, 2019 at 2:15 PM Laurent Pinchart
wrote:
>
> Sorry, forgot to CC Bartlomiej on this patch.
>
> On Sun, Jul 07, 2019 at 09:07:54PM +0300, Laurent Pinchart wrote:
> > The hdmi_avi_infoframe_init() never needs to return an error, change its
> > return type to void.
> >
> >
If an enable GPIO is declared in the firmware, assert it when enabling
the bridge and deassert it when disabling it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git
Create a new simple_bridge_info structure that stores information about
the bridge model, and store the bridge timings in there, along with the
connector type. Use that new structure for of_device_id data. This
enables support for non-VGA bridges.
Signed-off-by: Laurent Pinchart
---
The dumb-vga-dac driver can support simple DRM bridges without being
limited to VGA DACs. Rename it to simple-bridge.
Signed-off-by: Laurent Pinchart
---
arch/arm/configs/davinci_all_defconfig | 2 +-
arch/arm/configs/integrator_defconfig| 2 +-
Sorry, forgot to CC Bartlomiej on this patch.
On Sun, Jul 07, 2019 at 09:07:54PM +0300, Laurent Pinchart wrote:
> The hdmi_avi_infoframe_init() never needs to return an error, change its
> return type to void.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_edid.c | 5 +
>
The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
DACs that don't require configuration. Other non-VGA bridges fall in a
similar category, and would benefit from a common driver. Prepare for
this by renaming the internal symbols from dumb-vga-dac to
simple-bridge.
The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_edid.c | 5 +
drivers/video/hdmi.c | 9 ++---
include/linux/hdmi.h | 2 +-
3 files changed, 4 insertions(+), 12 deletions(-)
Hello,
This patch series (nearly, see [1]) completes the rework of the omapdrm
driver to move to drm_bridge and drm_panel.
What a journey. This work was started more than a year ago, and this
last piece is perhaps the one that will generate the most bikeshedding
as it touches the DRM core. I'm
The drm_display_info structure contains many fields related to HDMI
sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
populate it according to section 8.3.3 ("DVI/HDMI Device
Discrimination") of the HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #2 from rol...@rptd.ch ---
I don't know what other information can help so I collected information about
the state that worked (before the update) and the state that does not work
anymore (after the update):
before update (working
On Sun, Jul 07, 2019 at 05:31:34AM +, bugzilla-dae...@freedesktop.org wrote:
> 2. Valve sponsored an interesting project that removes dependency of AMD Mesa
> from LLVM. And instead uses ACO. Valve made this available for Arch based
> systems via AUR, and Ubuntu based system via PPA. If you
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #38 from Sylvain BERTRAND ---
On Sun, Jul 07, 2019 at 05:31:34AM +, bugzilla-dae...@freedesktop.org
wrote:
> 2. Valve sponsored an interesting project that removes dependency of AMD Mesa
> from LLVM. And instead uses ACO. Valve
Hi
Am 07.07.19 um 16:37 schrieb Noralf Trønnes:
>
>
> Den 05.07.2019 11.26, skrev Thomas Zimmermann:
>> Generic framebuffer emulation uses a shadow buffer for framebuffers with
>> dirty() function. If drivers want to use the shadow FB without such a
>> function, they can now set prefer_shadow
Den 05.07.2019 11.26, skrev Thomas Zimmermann:
> Generic framebuffer emulation uses a shadow buffer for framebuffers with
> dirty() function. If drivers want to use the shadow FB without such a
> function, they can now set prefer_shadow or prefer_shadow_fbdev in their
> mode_config structures.
Den 05.07.2019 11.26, skrev Thomas Zimmermann:
> This patch changes DRM clients to not map the buffer by default. The
> buffer, like any buffer object, should be mapped and unmapped when
> needed.
>
> An unmapped buffer object can be evicted to system memory and does
> not consume video ram
Den 05.07.2019 11.26, skrev Thomas Zimmermann:
> DRM clients, such as the fbdev emulation, have their buffer objects
> mapped by default. Mapping a buffer implicitly prevents its relocation.
> Hence, the buffer may permanently consume video memory while it's
> allocated. This is a problem for
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #37 from shadow.archem...@gmail.com ---
(In reply to Mauro Gaspari from comment #36)
> (In reply to shadow.archemage from comment #35)
> I am not an expert, but I am quite sure shaders have a big part in this. If
> you can, disable
86 matches
Mail list logo
