Hi Linus,
This one has a core mst fix and two i915 fixes. amdgpu just enables
some hw outside experimental.
The panfrost fix is a little bigger than I'd like at this stage but it
fixes a fairly fundamental problem with global shared buffers in that
driver, and since it's confined to that driver
From: Wen Yang
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing
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_bridge by
making the next bridge mandatory and removing the related
omapdrm-specific display
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/venc.c | 45 --
1 file changed, 45
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
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/omapdrm/dss/base.c | 23
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
---
Changes since
The omap_connector implementation is now used for DSI only. Hardcode its
type and drop unused code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 --
drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 -
drivers/gpu/drm/omapdrm/omap_connector.c |
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.
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.
The omapdss device .set_infoframe() and
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
drivers/gpu/drm/omapdrm/omap_encoder.c | 26
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 96 -
1 file
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
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
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
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
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 18
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 32
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28 ---
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
Reviewed-by: Tomi
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
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
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
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
---
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 6
Implement the newly added bridge connector operations, allowing the
usage of drm_bridge_panel with drm_bridge_connector.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Reviewed-by: Sam Ravnborg
---
Changes since v2:
- Use the connector type from the panel instead of hardcoding
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
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
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
---
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
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/omapdrm/omap_connector.c | 11 ---
In preparation for a connector creation helper based on a chain of
bridges, add a flag to the drm_bridge structure to report support for
interlaced modes. This will be used to set the connector's
interlace_allowed flag.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_bridge.h | 5 +
1
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
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
---
Changes since v2:
- Control CT_CP_HPD GPIO from .hpd_enable() and .hpd_disable()
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
The TI OPA362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
---
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 86 -
1 file
As part of the move to drm_bridge ops, the dssdev ops will become empty
for some of the internal encoders. Make them optional in the driver to
allow them to be removed completely, easing the transition.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
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
Reviewed-by: Andrzej Hajda
Reviewed-by: Stefan Agner
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Acked-by: Sam Ravnborg
---
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
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
-
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
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 146 --
1 file
drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
to name strings, but doesn't expose it. This leads to drivers having to
store a similar map.
Add a new drm_get_connector_type_name() helper function that return a
name string for a connector type.
Signed-off-by: Laurent
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.
The omapdss device .set_infoframe() and
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
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
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
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
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
- Keep MAX_EDID macro
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 36
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
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
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 61
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
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.
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
- I2C
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
Reviewed-by:
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
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Acked-by: Maxime Ripard
Acked-by: Sam Ravnborg
---
Hello,
This patch series is the fifth attempt to (nearly, see [1]) complete the
rework of the omapdrm driver to move to drm_bridge and drm_panel.
Version 2, available at [2], explains in its long cover letter the
rationale for the changes. I won't duplicate it here as it is still
valid as-is.
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
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
The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Acked-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
---
Changes since v1:
- Removed documentation of
Hi Neil,
On Mon, Jan 06, 2020 at 03:45:59PM +0100, Neil Armstrong wrote:
> On 19/12/2019 11:44, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series is the fourth attempt to (nearly, see [1]) complete the
> > rework of the omapdrm driver to move to drm_bridge and drm_panel.
> >
> >
On January 23, 2020 11:57:57 AM PST, Linus Torvalds
wrote:
>On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
> wrote:
>>
>> I'm going to leave it aside, at least for the time being, and do it
>as a
>> second step later after evaluating the real performance impact. I'll
>> respin tomorrow in
From: Jiange Zhao
[ Upstream commit 57d4f3b7fd65b56f98b62817f27c461142c0bc2a ]
Add Navi12 PCI id support.
v2: flag as experimental for now (Alex)
Signed-off-by: Jiange Zhao
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: Geert Uytterhoeven
[ Upstream commit 3986457110a054466bf02f9c4a85aa2bba96177b ]
Commit 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk") states
that LVDS lanes 1 and 3 are inverted on R-Car H2 ES1 only, and that the
problem has been fixed in newer revisions.
However, the code didn't
These are some very loud debug statements that get printed on every
vblank when driver level debug printing is enabled in DRM, and doesn't
really tell us anything that isn't related to vblanks. So let's move
this over to the proper debug flag to be a little less spammy with our
debug output.
213a352f
> > drm/drm_panel: fix export of drm_panel_of_backlight, try #3
> >
> >
> > As we expect this to fix it for good.
> > Maybe the patch has not hit the right tree
> > and is thus not in -next.
>
> Sorry, I don't have the linux-next git tree so
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the topology and as such, it's a good
idea to
This
1) Enables core DRM syncobj support.
2) Adds options to the submission ioctl to wait/signal syncobjs.
Just like the wait fence fd, this does inline waits. Using the
scheduler would be nice but I believe it is out of scope for
this work.
Support for timeline syncobjs is implemented and the
On Mon, Jan 20, 2020 at 5:06 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 07:32:27PM +0100, Bas Nieuwenhuizen wrote:
> > On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse
> > wrote:
> > >
> > > On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> > > > This
> > > >
> > > > 1)
Hi Ville and Laurentiu
On 2019-11-28 03:14, Ville Syrjälä wrote:
On Thu, Nov 28, 2019 at 08:39:41AM +, Laurentiu Palcu wrote:
On Wed, Nov 27, 2019 at 05:17:03PM +0200, Ville Syrjälä wrote:
> Caution: EXT Email
>
> On Wed, Nov 27, 2019 at 02:42:35PM +, Laurentiu Palcu wrote:
> >
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #38 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
On Thu, Jan 23, 2020 at 10:05:26PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> --- Comment #36 from Jacques Belosoukinski (kentos...@whiteninjastudio.com)
> ---
> No,
On Thu, Jan 23, 2020 at 10:05:26PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> --- Comment #36 from Jacques Belosoukinski (kentos...@whiteninjastudio.com)
> ---
> No, I do not have Windows on this computer. There are several benchmark
> results
> available, moreover I noticed that Mesa
From: Uma Shankar
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
This was posted by Uma Shankar at
https://patchwork.kernel.org/patch/10861327/
Modified by Abhinav Kumar:
- Use macros to distinguish the bit fields for clarity
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #37 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
Mesa 20 was installed :
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI, DRM 3.35.0,
5.4.13-amd64, LLVM 9.0.1)
OpenGL core
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device. As the global mutex is indeed global, not only
within the device but across devices, a slow file release mechanism can
bottleneck the
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #36 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
No, I do not have Windows on this computer. There are several benchmark results
available, moreover I noticed that Mesa has much lower performance compared to
DirectX
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #35 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
On Thu, Jan 23, 2020 at 09:21:05PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206231
>
> --- Comment #34 from Jacques
On Thu, Jan 23, 2020 at 09:21:05PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206231
>
> --- Comment #34 from Jacques Belosoukinski (kentos...@whiteninjastudio.com)
> ---
> > > Windows version which should run at an average of 70fps during
On Wed, Jan 22, 2020 at 7:22 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
> 1 file changed, 1 insertion(+), 1
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #34 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
(In reply to Sylvain BERTRAND from comment #32)
> > Is there a reason to have such poor performance with Dirt Rally compared to
> > the
> > Windows version which
On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
wrote:
>
> I'm going to leave it aside, at least for the time being, and do it as a
> second step later after evaluating the real performance impact. I'll
> respin tomorrow in that way.
Ok, good.
>From a "narrow the access window type"
Hi Randy.
Thanks - I think (kidding, this has bugged of for a long time).
On Thu, Jan 23, 2020 at 12:44:25AM -0800, Randy Dunlap wrote:
> On 1/22/20 10:21 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200122:
> >
>
>
> on i386:
>
> ERROR: "drm_panel_of_backlight"
>
Hi Dave, Daniel,
Just one change to remove the experimental flag from renoir.
The following changes since commit def9d2780727cec3313ed3522d0123158d87224d:
Linux 5.5-rc7 (2020-01-19 16:02:49 -0800)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
Hi Jordan,
On Thu, Jan 23, 2020 at 09:42:36AM -0700, Jordan Crouse wrote:
> Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed
> updating the VBIF flush in a6xx_gmu_shutdown and instead
> inserted the new sequence into a6xx_pm_suspend along with a redundant
> GMU idle.
>
> Move
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
>
> On 32 bits powerPC (book3s/32), only write accesses to user are
> protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc just needs to look
more like everybody else, than
Hi Jyri.
dt_binding_check gives following warning:
CHECK Documentation/devicetree/bindings/display/ti/ti,k2g-dss.example.dt.yaml
Documentation/devicetree/bindings/display/ti/ti,k2g-dss.example.dt.yaml:
dss@0254: 'ports' does not match any of the regexes: 'pinctrl-[0-9]+'
Hi Geert & Rob.
On Thu, Jan 23, 2020 at 08:43:39AM +0100, Geert Uytterhoeven wrote:
> Hi Sam,
>
> On Mon, Jan 20, 2020 at 8:02 PM Sam Ravnborg wrote:
> > From 6b54fb0a071c0732cd4bd5b88f456b5a85bcf4f2 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg
> > Date: Mon, 20 Jan 2020 19:55:04 +0100
> >
On Thu, Jan 23, 2020 at 11:56 AM Sam Ravnborg wrote:
>
> On Sun, Jan 19, 2020 at 03:09:07PM -0600, Rob Herring wrote:
> > Convert all the 'simple' panels which match the constraints of the
> > common panel-simple.yaml schema. This conversion is based on how the
> > panels are documented. Some may
Hi Marcel.
On Mon, Jan 20, 2020 at 09:00:58AM +0100, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Add vendor prefix for Logic Technologies Limited [1] which is a Chinese
> display manufacturer e.g. distributed by German Endrich Bauelemente
> Vertriebs GmbH [2].
>
> [1]
On Sun, Jan 19, 2020 at 03:09:07PM -0600, Rob Herring wrote:
> Convert all the 'simple' panels which match the constraints of the
> common panel-simple.yaml schema. This conversion is based on how the
> panels are documented. Some may turn out to be more complex once the
> schema is applied to
On Thu, Jan 23, 2020 at 05:45:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The aux ch is used for more than DDC, so let's give it a better
> name. For maximum ease let's include both the AUX ch identifier
> and the port identifier (for cases where the VBT has redefined
> the
On Thu, Jan 23, 2020 at 05:45:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make it easier to figure out what caused a particular debug
> message let's print out aux->name.
>
> Signed-off-by: Ville Syrjälä
It might be worth adding commas to some of these messages too while
Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed
updating the VBIF flush in a6xx_gmu_shutdown and instead
inserted the new sequence into a6xx_pm_suspend along with a redundant
GMU idle.
Move a6xx_bus_clear_pending_transactions to a6xx_gmu.c and use it in
the appropriate place
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #33 from Alex Deucher (alexdeuc...@gmail.com) ---
Windows has a much bigger team supporting it and optimizing for specific games.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Jan 23, 2020 at 12:49:03PM +0530, Sharat Masetty wrote:
> This patch adds Adreno 618 entry and its associated properties
> to the gpulist entries.
>
> Signed-off-by: Sharat Masetty
I'm extremely confused - these have been in linux-next for weeks. Why are you
sending them out again?
On Thu, 2020-01-23 at 09:17 -0500, Sasha Levin wrote:
> On Fri, Jan 17, 2020 at 08:25:30AM +0100, Iago Toral wrote:
> > Hi Sasha,
> >
> >
> > please notice that there were two separate patches that addressed
> > the
> > same issue and applying both simultaneously leads to a double free
> >
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git
From: Ville Syrjälä
The aux ch is used for more than DDC, so let's give it a better
name. For maximum ease let's include both the AUX ch identifier
and the port identifier (for cases where the VBT has redefined
the relationship of the two).
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git
Quoting Colin King (2020-01-23 15:14:06)
> From: Colin Ian King
>
> Currently if the call to function context_get_vm_rcu returns
> a null pointer for vm then the error exit path via label err_put
> will call i915_vm_put on the null vm, causing a null pointer
> dereference. Fix this by adding a
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #32 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
> Is there a reason to have such poor performance with Dirt Rally compared to
> the
> Windows version which should run at an average of 70fps during the benchmark?
> I
>
> Is there a reason to have such poor performance with Dirt Rally compared to
> the
> Windows version which should run at an average of 70fps during the benchmark?
> I
> noticed that the GPU load was low on the benchmark unlike other circuits where
> the GPU load is 100%.
Ok. What settings did
From: Colin Ian King
Currently if the call to function context_get_vm_rcu returns
a null pointer for vm then the error exit path via label err_put
will call i915_vm_put on the null vm, causing a null pointer
dereference. Fix this by adding a null check on vm and returning
without calling the
On Mon, Jan 20, 2020 at 08:02:49PM +0100, Sam Ravnborg wrote:
> Hi David.
>
> > > +allOf:
> > > + - $ref: panel/panel-common.yaml#
> >
> > not all of these properties are applicable.
> >
>
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - dc-gpios
> > > + - reset-gpios
> >
>
On Fri, Jan 17, 2020 at 08:25:30AM +0100, Iago Toral wrote:
Hi Sasha,
please notice that there were two separate patches that addressed the
same issue and applying both simultaneously leads to a double free
(which is what I see is happening with this patch: see the second call
to kfree(bin)
Am 23.01.20 um 13:48 schrieb Jani Nikula:
> Use drm_core_check_all_features() to ensure both the driver features and
> the per-device driver features are taken into account when registering
> debugfs files.
>
> v3:
> - files[i].driver_features == 0 actually means "don't care"
>
> v2:
> - use
1 - 100 of 196 matches
Mail list logo
