Hi Linus,
I looked at Rob's msm tree, he kept it small due to being late, and it
was in -next for a while before he was ill, so I think it should be
fine. Otherwise this contains a set of i915 fixes and a v3d build fix,
and vc4 leak fix.
Thanks,
Dave.
drm-next-2018-06-11:
msm next, i915, vc4, v3
On Fri, 08 Jun 2018, Hans Verkuil wrote:
> On 08/06/18 10:17, Neil Armstrong wrote:
> > On 08/06/2018 09:53, Hans Verkuil wrote:
> >> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> >>> Hi All,
> >>>
> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> >>> through it's E
This patch add components DPI1/DSI1/DSI2/DSI3 in comp_init.
Because the some parameter for these components initialized
in their driver.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_d
This patch create third crtc by third ddp path
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 5 -
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/driver
This patch add the connection from RDMA2 to DSI3
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index ce89a1d86b93..5a8569fa6505 10064
This patch add the connection from RDMA2 to DSI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 2d883815d79c..ae10f8f1e140 10064
This patch add the connection from RDMA1 to DSI3
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index c3e647b04ffd..a5cee4b7f908 10064
This patch add the DPI1 support for mutex
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 5a8569fa6505..5916fc11693a 100644
--- a/dr
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
This patch add the DSI3 support for mutex
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 1e7e3872eccc..28dd8531a7de 100644
--- a/dr
This patch add the connection from RDMA2 to DPI0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a5cee4b7f908..31a0832ef9ec 1006
This patch add the connection from RDMA2 to DPI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 31a0832ef9ec..2d883815d79c 10064
This patch add the connection from RDMA2 to DSI2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index ae10f8f1e140..ce89a1d86b93 10064
This patch add the connection from RDMA0 to DSI3
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/
This patch add the DSI2 support for mutex
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 5916fc11693a..1e7e3872eccc 100644
--- a/dr
This patch add the component DSI3
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_
This patch add component PWM2
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/media
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 58e
This patch add the connection from RDMA0 to DPI0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8bfc0debd2c2..d7953f2f6a36 100644
-
This patch add the connection from RDMA1 to DPI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index fed1b5704355..4abd5dabeccf 10064
This patch add the connection from RDMA1 to DSI2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7e4ad5580cf6..c3e647b04ffd 1006
This patch add the component DSI2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_
This patch add the connection from RDMA1 to DSI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 4abd5dabeccf..7e4ad5580cf6 1006
This patch add the component DPI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_
This patch add the connection from RDMA0 to DSI2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index d7953f2f6a36..c08aed8dae44 100644
--
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv
This patch add support for the Mediatek MT2712 DISP subsystem.
MT2712 is base on MT8173, there are some difference as following:
MT2712 support three disp output(two ovl and one rdma)
Change in v5:
- Keep the value of MAX_CONNECTOR, because it is useless
- Add the new patch for component DPI1
- Ad
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +-
1 file changed, 47 insertions(+), 28 deletions(-)
diff --gi
This patch add the component OD1 and
rename the OD to OD0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +
This patch add component PWM1 in mtk_ddp_matches
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 87acf
Update device tree binding documentation for the display subsystem for
Mediatek MT2712 SoCs.
Signed-off-by: Stu Hsieh
Acked-by: CK Hu
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #8 from stu...@gmail.com ---
I've done a bit more playing around and it is a race condition, but it's one
that happens on initialization. If I let the loading screen/movie play for a
few minutes before actually attempting to play, th
Hi,
On Sat, May 26, 2018 at 08:25:07PM +0300, Laurent Pinchart wrote:
> Creating all the planes in a single location instead of creating them
> per-CRTC with remaining planes then created in a second step simplifies
> the logic.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian R
Hi,
On Sat, May 26, 2018 at 08:25:06PM +0300, Laurent Pinchart wrote:
> The crtc_idx and plane_idw variables in the main loop are always equal
> to the loop counter i, use it instead. Don't unnecessarily initialize
> dssdev to NULL.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebasti
Hi,
On Sat, May 26, 2018 at 08:25:05PM +0300, Laurent Pinchart wrote:
> Regulators for the DPI, DSI, HDMI, SDI and VENC outputs are all looked
> up when connecting the output omap_dss_device. There's no need to delay
> regulator handling to that time, get the regulators at probe time.
>
> Signed-
On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote:
> Similarly to for_each_dss_display(), the for_each_dss_output() macro
> iterates over all the DSS connected outputs.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/base.c| 20 ++--
> d
Hi,
On Sat, May 26, 2018 at 08:25:01PM +0300, Laurent Pinchart wrote:
> Look up the next dssdev at probe time based on device tree links for all
> DSS outputs and encoders. This will be used to reverse the order of the
> dssdev connect and disconnect call chains.
>
> Signed-off-by: Laurent Pincha
Hi,
On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote:
> The dss_mgr_connect() and dss_mgr_disconnect() functions take two
> omap_dss_device pointers as parameters, which are always set to the same
> value by all callers. Remove the duplicated pointer.
>
> Signed-off-by: Laurent Pi
Hi,
On Sat, May 26, 2018 at 08:25:03PM +0300, Laurent Pinchart wrote:
> Add a new omapdss_display_get() function to retrieve the omap_dss_device
> for a given DSS output. This will be used when reversing the direction
> of the DSS pipeline handling logic.
>
> Signed-off-by: Laurent Pinchart
> --
Hi,
On Sat, May 26, 2018 at 08:25:00PM +0300, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O or enabling runtime PM) to the component bind
> handler. Perform as much of the initialization as possible at probe
> time, initiali
Hi,
On Sat, May 26, 2018 at 08:24:59PM +0300, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O or enabling runtime PM) to the component bind
> handler. Perform as much of the initialization as possible at probe
> time, initiali
Hi,
On Sat, May 26, 2018 at 08:24:58PM +0300, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O or enabling runtime PM) to the component bind
> handler. Perform as much of the initialization as possible at probe
> time, initiali
Hi,
On Sat, May 26, 2018 at 08:24:57PM +0300, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O or enabling runtime PM) to the component bind
> handler. Perform as much of the initialization as possible at probe
> time, initiali
Hi,
On Sat, May 26, 2018 at 08:24:56PM +0300, Laurent Pinchart wrote:
> Rename the jump labels according to the cleanup they perform, not the
> location they're accessed from, and move functions from error checks to
> cleanup paths, and move reference handling to simplify cleanup.
>
> Signed-off-
Hi,
On Sat, May 26, 2018 at 08:24:55PM +0300, Laurent Pinchart wrote:
> The connect handle of the analog TV and HDMI connectors casts the dssdev
> to panel data only to then access fields of the panel data that are also
> present in the dssdev. Remove the cast and use dssdev directly.
>
> Signed-
Hi,
On Sat, May 26, 2018 at 08:24:54PM +0300, Laurent Pinchart wrote:
> The omapdss_of_find_source_for_first_ep() function locates the source
> corresponding to the first endpoint of the first port of a device node.
> We can easily extend it to locate sinks as well by passing the port
> number as
Hi,
On Sat, May 26, 2018 at 08:24:53PM +0300, Laurent Pinchart wrote:
> The omap_dss_device port_num field stores the DT port number associated
> with the device. The field is used in different ways depending on the
> device type:
>
> - For DPI outputs, the port number is used as an identifier of
Hi,
On Sat, May 26, 2018 at 08:24:52PM +0300, Laurent Pinchart wrote:
> The omapdss_find_output_from_display() function is only used to retrieve
> the dispc channel corresponding to the display. Return the dispc channel
> directly, and rename the function to omapdss_device_get_dispc_channel()
> to
Hi,
On Sat, May 26, 2018 at 08:24:50PM +0300, Laurent Pinchart wrote:
> Storing the dss_device pointer in the omap_dss_device structure will
> allow accessing the dss_device from the dss_mgr API functions.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
Hi,
On Sat, May 26, 2018 at 08:24:51PM +0300, Laurent Pinchart wrote:
> The DSS manager ops and private data pointer are specific to a DSS
> instance. Store them in the dss_device structure instead of global
> variable.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
Hi,
On Sat, May 26, 2018 at 08:24:49PM +0300, Laurent Pinchart wrote:
> The functions operate on any omap_dss_device, move them from display.c
> to base.c. While at it rename them to match the naming of the other
> functions operating on struct omap_dss_device.
>
> Signed-off-by: Laurent Pinchart
Hi,
On Sat, May 26, 2018 at 08:24:48PM +0300, Laurent Pinchart wrote:
> The panel devices list isn't used anymore, all panel devices are
> accessed through the global devices list. Remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> .../gpu/drm
Hi,
On Sat, May 26, 2018 at 08:24:47PM +0300, Laurent Pinchart wrote:
> Split the function into omapdss_display_init() to perform
> display-specific initialization of the omap_dss_device, and
> omapdss_register_display() to register the device. The latter will then
> be replaced by more generic re
Hi,
On Sat, May 26, 2018 at 08:24:46PM +0300, Laurent Pinchart wrote:
> Despite its name, the omap_dss_get_next_device() function operates on
> display devices only. Make it more generic by allowing operation on all
> devices, with a parameter to specify the device type.
>
> While at it rename th
Hi,
On Sat, May 26, 2018 at 08:24:45PM +0300, Laurent Pinchart wrote:
> The macro iterates over displays only, rename it accordingly.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
> drivers/gpu/drm/omapd
Hi,
On Sat, May 26, 2018 at 08:24:44PM +0300, Laurent Pinchart wrote:
> The output devices list isn't used anymore, all output devices are
> accessed through the global devices list. Remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/g
Hi,
On Sat, May 26, 2018 at 08:24:43PM +0300, Laurent Pinchart wrote:
> The DSI clocks are dumped in the DSS-level debugfs clocks file. This
> complicates the implementation as the DSI private data has to be looked
> up through the outputs list. Simplify it by creating two debugfs files,
> dsi1_cl
Hi,
On Sat, May 26, 2018 at 08:24:42PM +0300, Laurent Pinchart wrote:
> The DSI debugfs regs and irqs show handlers received a pointer to the
> DSI private data. There's no need to look it up from the list of DSS
> outputs. Use the pointer directly, this allows simplifying the
> implementation of
Hi,
On Sat, May 26, 2018 at 08:24:41PM +0300, Laurent Pinchart wrote:
> All connectors, encoders and panels store a pointer to their input
> omap_dss_device in the panel driver data structure. This duplicates the
> src field in the omap_dss_device structure. Remove the private copy and
> use the s
Hi,
On Sat, May 26, 2018 at 08:24:40PM +0300, Laurent Pinchart wrote:
> The encoders duplicate the same omap_dss_device src and dst fields set
> and checks in their connect and disconnect handlers. Move the code to
> the connect and disconnect wrappers.
>
> Signed-off-by: Laurent Pinchart
> ---
Hi,
On Sat, May 26, 2018 at 08:24:39PM +0300, Laurent Pinchart wrote:
> The connectors, encoders and display duplicate the same debug messages
> and connection checks in their omap_dss_device connect and disconnect
> handlers. Move the code to the connect and disconnect wrappers.
>
> To simplify
Hi,
On Sat, May 26, 2018 at 08:24:38PM +0300, Laurent Pinchart wrote:
> The omap_dss_device objects model display components and are connected
> at runtime to create display pipelines. The connect and disconnect
> operations implemented by each component contain lots of duplicate code.
> As a firs
Hi,
On Sat, May 26, 2018 at 08:24:37PM +0300, Laurent Pinchart wrote:
> The various types of omapdss_*_ops structures define multiple operations
> that are not specific to a bus type. To simplify the code and remove
> dependencies on specific bus types move those operations to a common
> structure
Hi,
On Sat, May 26, 2018 at 08:24:36PM +0300, Laurent Pinchart wrote:
> The omap_dss_find_output_by_port() function looks up an omap_dss_device
> by port from the list of devices registered as outputs. In preparation
> for looking up sinks in addition to sources, allow the function to look
> up an
Hi,
On Sat, May 26, 2018 at 08:24:35PM +0300, Laurent Pinchart wrote:
> The omap_dss_find_output_by_port_node() function defined in output.c
> looks up an output from its port node. To do so it needs to call helper
> functions from dss-of.c to lookup the port parent and the port number.
> As omap_
Hi,
On Sat, May 26, 2018 at 08:24:34PM +0300, Laurent Pinchart wrote:
> The omapdss_component_is_loaded() function test whether a component is
> loaded by checking whether it is present in the displays list or the
> outputs list. Simplify the implementation by checking for the component
> in the g
Hi,
On Sat, May 26, 2018 at 08:24:33PM +0300, Laurent Pinchart wrote:
> The omap_dss_device instances are stored in two separate lists,
> depending on whether they are panels or outputs. Create a third list
> that stores all omap_dss_device instances to allow generic code to
> operate on all insta
Hi,
On Sat, May 26, 2018 at 08:24:32PM +0300, Laurent Pinchart wrote:
> For coherency with the panel_list field, rename list to output_list.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +-
> drivers/gpu/d
Hi,
On Sat, May 26, 2018 at 08:24:31PM +0300, Laurent Pinchart wrote:
> The omap_dss_device panel.dsi_pix_fmt and panel.dsi_mode fields are
> unused. Remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/panel-d
Hi,
On Sat, May 26, 2018 at 08:24:30PM +0300, Laurent Pinchart wrote:
> The omap_dss_device structure stores a videomode. All the connector and
> panel drivers that use omap_dss_device also store the videomode in their
> own panel_drv_data structures. There's no need to duplicate, remove the
> vid
https://bugs.freedesktop.org/show_bug.cgi?id=97909
--- Comment #16 from Joonas Sarajärvi ---
Now that I tried removing the workaround again, it looks like things still work
for me. So now at least one working combination that does not trigger this bug
looks like this:
- Fedora 28
- kernel 4.16.1
Hi,
On Sat, May 26, 2018 at 08:24:29PM +0300, Laurent Pinchart wrote:
> The structure contains function pointers that don't need to be modified.
> Make all its instances const to improve security.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> driver
Hi,
On Sat, May 26, 2018 at 08:24:28PM +0300, Laurent Pinchart wrote:
> All omap_dss_driver instances provide the get_timings operation. Remove
> the default function.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/display
Hi,
On Sat, May 26, 2018 at 08:24:27PM +0300, Laurent Pinchart wrote:
> The get_timings operation from DSS encoders (not to be confused with the
> identically named operation in omap_dss_driver) is never called. Remove
> it.
>
> Signed-off-by: Laurent Pinchart
> ---
good catch!
Reviewed-by: Se
Hi,
On Sat, May 26, 2018 at 08:24:26PM +0300, Laurent Pinchart wrote:
> The operations are never used, remove them. If the need to set wide
> screen signaling data arises later, it should be implemented by
> extending the DRM bridge API.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Se
On Sat, May 26, 2018 at 08:24:25PM +0300, Laurent Pinchart wrote:
> The dpi_init_port() and sdi_init_port() functions can return errors but
> their return value is ignored. This prevents both probe failures and
> probe deferral from working correctly. Propagate the errors up the call
> stack.
>
>
Hi,
On Sat, May 26, 2018 at 08:24:24PM +0300, Laurent Pinchart wrote:
> From: Jyri Sarha
>
> Register the omapdrm device when we know that dss device probe going
> to succeed. This avoids DSS6 and DSS2 omapdrm device registration from
> colliding with each other.
>
> Signed-off-by: Jyri Sarha
Hi,
On Sat, May 26, 2018 at 08:24:23PM +0300, Laurent Pinchart wrote:
> The omapdss_gather_components() function walks the OF graph to create a
> list of all components part of the display device. There's no need to
> delay this operation until DSS bind time as we have all the information
> we nee
Hi,
On Sat, May 26, 2018 at 08:24:21PM +0300, Laurent Pinchart wrote:
> From: Peter Ujfalusi
>
> Sort the dssdev array based on DT aliases.
>
> With this change we can remove the panel ordering from dss/display.c and
> have all sorting related to dssdevs in one place.
>
> Signed-off-by: Peter
Hi,
On Sat, May 26, 2018 at 08:24:20PM +0300, Laurent Pinchart wrote:
> From: Peter Ujfalusi
>
> Instead of reaching back to DSS to iterate through the dss_devices every
> time, use an internal array where we store the available and usable
> dss_devices.
>
> At the same time remove the omapdss_
Return an error code on failure.
Problem found using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 12 +++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd1
https://bugs.freedesktop.org/show_bug.cgi?id=106877
Bug ID: 106877
Summary: The game Rise of the Tomb Raider lead to GPU hang when
I try in same place jump into the hole.
Product: DRI
Version: XOrg git
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #17 from udo ---
Latest firmwares do influence the situation in a positive way.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
Hi,
On Sat, May 26, 2018 at 08:24:19PM +0300, Laurent Pinchart wrote:
> From: Peter Ujfalusi
>
> If we allocate the drm_device earlier we can just return the error code
> without the need to use goto.
> Do the unref of the drm_device as a last step when cleaning up. This will
> make the drm_devi
Hi,
On Wed, Feb 28, 2018 at 01:26:04PM +0200, Tomi Valkeinen wrote:
> From: Benoit Parrot
>
> When dispc_wb_setup() calls dispc_ovl_setup_common() it does not
> check for failure but instead keeps on partially setting up WB.
> This causes the WB H/W to be partially initialized and yield
> unexpe
Hi,
On Wed, Feb 28, 2018 at 01:26:03PM +0200, Tomi Valkeinen wrote:
> A few enums are not used anywhere, so remove them.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 15
Hi,
On Wed, Feb 28, 2018 at 01:26:02PM +0200, Tomi Valkeinen wrote:
> Add hpd-gpios property to dvi-connector.txt.
>
> Signed-off-by: Tomi Valkeinen
> Cc: devicet...@vger.kernel.org
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
-- Sebastian
> ---
Hi,
On Wed, Feb 28, 2018 at 01:26:01PM +0200, Tomi Valkeinen wrote:
> Add HPD support to the DVI connector driver. The code is almost
> identical to the HPD code in the HDMI connector driver.
>
> Signed-off-by: Tomi Valkeinen
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/d
Hi,
On Wed, Feb 28, 2018 at 01:26:00PM +0200, Tomi Valkeinen wrote:
> From: Peter Ujfalusi
>
> Do not try to init the fbdev if either num_crtcs or num_connectors is 0.
> In this case we do not have display so the fbdev init would fail anyways.
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by:
Hi,
On Wed, Feb 28, 2018 at 01:25:59PM +0200, Tomi Valkeinen wrote:
> omap_fbdev_init() and omap_fbdev_free() use priv->fbdev directly.
> However, omap_fbdev_init() returns the fbdev, and omap_drv.c also
> assigns the return value to priv->fbdev. This is slightly confusing.
>
> Clean this up by r
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #16 from Sebastian Frysztak ---
Hi everyone,
I have the same issue with 2400g, and I believe I have found a way to reproduce
it.
Please try the following apitrace of a game called Deadly Premonition [1]. Just
decompress it (it's al
https://bugs.freedesktop.org/show_bug.cgi?id=106875
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
apitrace is here: https://dumps.sy24.ru/GoMLinux.x86_64.tar.xz (1.1GB)
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106875
Bug ID: 106875
Summary: The game Anima Gate of Memories has artefects on Vega
56
Product: Mesa
Version: 18.0
Hardware: Other
OS: All
Status: NE
93 matches
Mail list logo