https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #23 from arne_woer...@yahoo.com ---
i did another experiment:
i set amdgpu.dc=1 and left amdgpu.msi and amdgpu.audio unchanged and
installed the new firmware (180119-2).
result:
i still get this slowness error during second thaw:
PM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrey Grodzovsky (2):
amdgpu: Update deadlock test to not assert on ECANCELED
amdgpu: Fix segfault in deadlock test.
Anuj Phogat (1):
intel: Add more Coffeelake PCI IDs
Bas Nieuwenhuizen (1):
drm: Fix 32-bit drmSyncobjWait.
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #32 from Bong Cosca ---
Piglit results improved with only 70 fails, after stopping at 23705 tests.
This also works:
raster_config = 0x000f;
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105140
--- Comment #1 from Roland Scheidegger ---
Looks like pretty much the same issue as 105139 to me.
Somehow a depth/stencil format texture gets attached as a color attachment (I
can't think of any reason why anyone would even try that...), and if
https://bugs.freedesktop.org/show_bug.cgi?id=105140
Bug ID: 105140
Summary: clearing related crash in Dying Light
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
P
Hi uma.shankar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on rockchip/for-next]
[also build test WARNING on v4.16-rc1 next-20180216]
[cannot apply to drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #31 from Bong Cosca ---
This fixes the problem for me:
case CHIP_KAVERI:
/* KV should be 0x0002, but that causes problems with
radeon */
raster_config = 0x0003;
raster_c
On 2018-02-16 03:10 PM, Ville Syrjälä wrote:
> On Thu, Feb 15, 2018 at 02:45:29PM -0500, Daniele Castagna wrote:
>> rk3399 has the option of setting per-plane gamma.
>> The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has
>> at least 3 optional stages, two of those being degamma and
Hi,
On Fri, Feb 16, 2018 at 4:34 AM, Enric Balletbo Serra
wrote:
> Hi,
>
> 2018-01-31 17:52 GMT+01:00 Doug Anderson :
>> Hi,
>>
>>
>> On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul wrote:
>>> On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach wrote:
Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb T
Am Freitag, 16. Februar 2018, 21:41:51 CET schrieb Heiko Stuebner:
> From: Zheng Yang
>
> The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
>
> Signed-off-by: Zheng Yang
> Signed-off-by: Heiko Stuebner
Forgot to add that the v1 binding already got a review as
Reviewed-by
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general
mmio, so allow these to be referenced via the regular phy interfaces
and therefore add optional phy-related properties to the binding.
Signed-off-by: Heiko Stuebner
---
Documentation/devicetree/bindings/display/rockchip/dw_
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1 file changed, 10 insertio
From: Zheng Yang
Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
and rk3328 socs from Rockchip.
Signed-off-by: Zheng Yang
Signed-off-by: Heiko Stuebner
---
Patches 1+2 expected to go through the phy-tree
drivers/phy/rockchip/Kconfig |7 +
drivers/phy/rock
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that now output-switch
The rk3328 uses an external hdmi phy from Innosilicon which uses
the generic phy framework for access. Add the necessary data
and the compatible for it.
Signed-off-by: Heiko Stuebner
---
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
From: Zheng Yang
The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
Signed-off-by: Zheng Yang
Signed-off-by: Heiko Stuebner
---
.../bindings/phy/phy-rockchip-inno-hdmi.txt| 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentati
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct. As the chip-data that occupies the phy_data
pointer initially gets assigned to the rockchip_hdmi struct we can not
re-use this phy_data pointer to hold the reference to the rockchip_hdmi
struct, similar
In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
phy from Innosilicon but still report the HDMI20_TX type.
So allow the glue driver to force a specific type, like the vendor-phy
for these cases.
Signed-of
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy
from Innosilicon that resides completely separate from the dw-hdmi block
and gets accessed via mmio.
Additionally the rk3328 dw-hdmi does not report the vendor-phy type
but a different one instead, so add the possibility to ove
On Thu, Feb 15, 2018 at 06:54:48PM +0100, Giulio Benetti wrote:
> Differently from other Lcd signals, HSYNC and VSYNC signals
> result inverted if their bits are cleared to 0.
>
> Invert their settings of IO_POL register.
>
> Signed-off-by: Giulio Benetti
Applied, thanks!
Maxime
--
Maxime Rip
From: Fabio Estevam
The cable_plugin member never receives an assignment, so it is always
false, which causes hdmi_enable_overflow_interrupts() to never
be called as per the logic below:
if (hdmi->cable_plugin && hdmi->sink_is_hdmi)
hdmi_enable_overflow_interrupts(hdmi);
On Thu, Feb 15, 2018 at 02:45:29PM -0500, Daniele Castagna wrote:
> rk3399 has the option of setting per-plane gamma.
> The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has
> at least 3 optional stages, two of those being degamma and gamma, and
> they can be configured per-plane.
>
Hi uma.shankar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on rockchip/for-next]
[also build test WARNING on v4.16-rc1 next-20180216]
[cannot apply to drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
On Thu, 2018-02-15 at 11:55 -0800, Rodrigo Vivi wrote:
> Dave Airlie writes:
>
> > On 6 February 2018 at 06:32, Rodrigo Vivi wrote:
> >> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> >>> Dhinakaran Pandiyan writes:
> >>>
> >>> > From: "Pandiyan, Dhinakaran"
> >>> >
> >>>
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20180216]
[cannot apply to v4.16-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Fri, Feb 16, 2018 at 10:53:08AM -0500, Sean Paul wrote:
> On Fri, Feb 16, 2018 at 04:44:12PM +0100, Maxime Ripard wrote:
> > Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
> > broke the build with one build error and one warning. Fix both.
>
> Reviewed-by: Sean Paul
On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
>
> This is especially useful if we ever want to support extra protocols for
> Wayland like:
> https://lists.freedesktop.org/archives/wayland-devel/2
Hi Daniele,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v4.16-rc1 next-20180216]
[cannot apply to drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Now that we have everything in place, we can make zpos configurable now.
Change the zpos property from an immutable one to a regular.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -
Since we now have a way to enforce the zpos, check for the number of alpha
planes, the only missing part is to assign our pipe automatically instead
of hardcoding it.
The algorithm is quite simple, but requires two iterations over the list of
planes.
In the first one (which is the same one that w
Now that we have support for per-plane alpha in the core, let's use it.
Acked-by: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
2 files changed, 14 insertions(+
Our backend supports a per-plane alpha property. Support it through our new
helper.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 16 +---
drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +++
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
3 files changed, 18 ins
Hi,
This serie aims at enhancing the support for our planes in the current drm
driver on the first generation of Allwinner's display engine.
This also introduces a few generic stuff, as well as some conversion for
some other drivers.
This series basically implements three things that look orthog
We've had some code for quite some time to prevent the alpha bug from
happening on the lowest primary plane. Since we now check for this in our
atomic_check, we can simply remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 12 +++-
1 file changed, 3 inser
The plane description structure was mostly needed to differentiate the
formats usable on the primary plane (because of its lowest position), and
assign the pipes. Now that both are dynamically checked and assigned, we
can remove the static definition.
Signed-off-by: Maxime Ripard
---
drivers/gpu
Some drivers duplicate the logic to create a property to store a per-plane
alpha.
This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
Let's create a helper in order to move that to the
Now that we have support for per-plane alpha in the core, let's use it.
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 +---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
driv
On Fri, Feb 16, 2018 at 9:12 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When the execbuf call receives an in-fence it will get the dma_fence
> related to that fence fd. If that fence is from a foreign context we wait
> on it before submitting the draw call.
>
> v2: - incorporate f
The in-lined comments for channel.port doesn't follow the syntax
described at kernel-doc document, causing the following warning:
$ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c
drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter
or member 'ch
On Friday 16 February 2018 06:35 PM, Heiko Stübner wrote:
> Hi Kishon,
>
> Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
>> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
>>> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
>>> only one P
The current implementation will leak a byte to the log via memmove. The
specified 27 bytes are off-by-one, as the payload is 25 bytes, and the
termination character is only one byte large. To avoid this, factor out
the error message, and furthermore make the second parameter of the
append_entry fun
This series fix two bugs at kernel-doc.rst examples and add support
for in-line nested struct comments.
It also converts one documentation at intel_dpio_phy to use it,
in order to give a practical example about how to use it.
Mauro Carvalho Chehab (6):
doc-guide: kernel-doc: fix example for nes
Hi,
On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
>
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit me
amd-staging-drm-next has removed radeon_kfd.c. Those changes seem to be
missing from amd-staging-dkms-4.13.
Regards,
Felix
On 2018-02-15 04:44 PM, kbuild test robot wrote:
> tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
> head: 7bde112fab15c0a28c1d056959167cd439
On Fri, Feb 16, 2018 at 04:44:12PM +0100, Maxime Ripard wrote:
> Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
> broke the build with one build error and one warning. Fix both.
Reviewed-by: Sean Paul
>
> Cc: Archit Taneja
> Cc: Jernej Skrabec
> Cc: Laurent Pincha
On Fri, 16 Feb 2018 16:35:27 +0100
Kamil Konieczny wrote:
> On 16.02.2018 15:54, Boris Brezillon wrote:
> > Adding back all the people that were Cc-ed on the initial email.
> >
> > On Fri, 16 Feb 2018 15:18:21 +0100
> > Kamil Konieczny wrote:
> >
> >> On 16.02.2018 15:00, Boris Brezillon wro
On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote:
> > If so, and if remember the captures properly, the sampling would occur
> > right before the rise, and not really around the fall.
> >
> > Would 2/3 be better here?
>
> Yes, you're right, 2/3 phase is better:
>
> 1/3 phase: https
Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
broke the build with one build error and one warning. Fix both.
Cc: Archit Taneja
Cc: Jernej Skrabec
Cc: Laurent Pinchart
Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
Reported-by: kbuild t
In randconfig testing, we sometimes get this warning:
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable
CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining
[-Werror=cpp]
From: Gustavo Padovan
To reflect the (backward compatible) changes in the uabi we are bumping
the driver's version.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv
From: Gustavo Padovan
On the out-fence side we get fence returned by the submitted draw call
and attach it to a sync_file and send the sync_file fd to userspace. On
error -1 is returned to userspace.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 49 +++
From: Gustavo Padovan
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENC
From: Gustavo Padovan
Refactor fence creation to remove the potential allocation failure from
the cmd_submit and atomic_commit paths. Now the fence should be allocated
first and just after we should proceed with the rest of the execution.
v2: - only alloc fence in virtio_gpu_alloc_fence(), i
From: Gustavo Padovan
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd. If that fence is from a foreign context we wait
on it before submitting the draw call.
v2: - incorporate fix for context check from Rob Herring
Signed-off-by: Gustavo Padovan
From: Gustavo Padovan
Hi,
So I finally got around to finish this work! :)
Here are the updated patchset with fixes for Rob Herring incorporated.
This follow pretty much the same semantics of other drivers that
implemented explicit fence support. It extends the execbuf ioctl to have
an fence_fd a
On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() functi
Adding back all the people that were Cc-ed on the initial email.
On Fri, 16 Feb 2018 15:18:21 +0100
Kamil Konieczny wrote:
> On 16.02.2018 15:00, Boris Brezillon wrote:
> > On Fri, 16 Feb 2018 12:21:53 +0100
> > Kamil Konieczny wrote:
> >
> >> On 16.02.2018 12:16, Boris Brezillon wrote:
>
Quoting Chunming Zhou (2018-02-09 02:44:08)
> it will be used to check if the driver needs swiotlb
> v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer
> )
>
> Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
> Signed-off-by: Chunming Zhou
> Reviewed-by: Monk Liu
>
Quoting Christian König (2018-02-16 12:43:38)
> i915 is the only driver using those fields in the drm_gem_object
> structure, so they only waste memory for all other drivers.
>
> Move the fields into drm_i915_gem_object instead and patch the i915 code
> with the following sed commands:
>
> sed -i
Hi Alex,
On Thu, Feb 15, 2018 at 07:33:15PM +, Alexandru Gheorghe wrote:
> Errors will be reported in /sys/kernel/debug/tracing/trace,
> still not noisy enough, but better than silently ignoring them.
> E.g:
> -0 [000] d.h1 183.851864: malidp_de_irq: error occurred DE_STATUS
> is 0x000
Needed to avoid a forward declaration in a followup patch.
Pure code move, no functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 47 +++
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qx
The encoder callbacks are only called in case the video mode changes.
So any layout changes without mode changes will go unnoticed.
Add qxl_crtc_update_monitors_config(), based on the old
qxl_write_monitors_config_for_encoder() function. Hook it into the
enable, disable and flush atomic crtc call
These days drm core checks function pointers everywhere before calling
them. So we can drop a bunch of dummy functions now.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 50 ---
1 file changed, 50 deletions(-)
diff --git a/drivers/gpu/
qxl_io_log() sends messages over to the host (qemu) for logging.
Remove the function and all callers, we can just use standard
DRM_DEBUG calls (and if needed a serial console).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_cmd.c | 34 ++-
Gerd Hoffmann (4):
qxl: remove qxl_io_log()
qxl: move qxl_send_monitors_config()
qxl: hook monitors_config updates into crtc, not encoder.
qxl: drop dummy functions
drivers/gpu/drm/qxl/qxl_drv.h | 3 -
drivers/gpu/drm/qxl/qxl_cmd.c | 36 +
drivers/gpu/drm/qxl/qxl_display.
Hi Kishon,
Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
> > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> > only one PHY can connect to DP controller at one time, the other should
> > b
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.
Move the fields into drm_i915_gem_object instead and patch the i915 code
with the following sed commands:
sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/
On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote:
> The current implementation will leak a byte to the log via memmove. The
> specified 27 bytes are off-by-one, as the payload is 25 bytes, and the
> termination character is only one byte large. To avoid this, factor out
> the error messag
Am 16.02.2018 um 13:30 schrieb Chris Wilson:
Quoting Christian König (2018-02-16 12:27:28)
Am 16.02.2018 um 11:18 schrieb Chris Wilson:
Quoting Christian König (2018-02-16 09:31:23)
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all ot
Hi,
2018-01-31 17:52 GMT+01:00 Doug Anderson :
> Hi,
>
>
> On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul wrote:
>> On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach wrote:
>>> Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
From: Sean Paul
Change the mode for Sharp lq12
On Fri, Feb 16, 2018 at 09:49:28AM +0100, Lukas Wunner wrote:
> [trimming cc: a little to avoid spamming folks not directly involved with
> i915]
>
> On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > i915, malidp and
Quoting Christian König (2018-02-16 12:27:28)
> Am 16.02.2018 um 11:18 schrieb Chris Wilson:
> > Quoting Christian König (2018-02-16 09:31:23)
> >> i915 is the only driver using those fields in the drm_gem_object
> >> structure, so they only waste memory for all other drivers.
> >>
> >> Move the fi
Am 16.02.2018 um 11:18 schrieb Chris Wilson:
Quoting Christian König (2018-02-16 09:31:23)
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.
Move the fields into drm_i915_gem_object instead and patch the i915 code
with t
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/core.c | 66
drivers/gpu/drm/o
The new omapdss API is HW independent and cleans up some of the DSS5
specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
register bits and replace them with HW independent generic u64 based
macros. The new macros make it more straight forward to implement the
IRQ code for the future
This series is an RFC or a proof of concept, to demostrate what is
needed to get DSS6 driver workin on top of Laurent Pinchart's
"omapdrm: Allocate objects dynamically" -series:
https://patchwork.freedesktop.org/series/38152/
This series also contains my earlier "drm/omap: Make omapdss API more
g
From: Tomi Valkeinen
Add support for DSS6 IP on TI K2G SoC.
DSS6 is an evolution of the OMAP DSS (DSS2). OMAP DSS has been quite
similar from OMAP2 to OMAP5 (including DRA7 and AM5 which have basically
the same IP as OMAP5), but in DSS6 lots of things have been
restructured.
DSS6 can still be c
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
---
drivers/gpu/drm/omapdrm/dss/core.c | 26 ++
drivers/gpu/drm/omapdrm/dss/dss
From: Tomi Valkeinen
Add "ti,k2g-dss" to the list of DSS devices which need the mangling of
the panels' & encoders' compatible strings.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/
After this patch OMAP_DSS_BASE module is not including any OMAP2_DSS
headers, only the API omapdss.h. "sturct dss_data", the piece of the
data structure needed for base.c is defined in omapdss.h and added as
a member to struct dss_device, and later to struct dss6_device.
The patch is still a bit h
The new DSS6 driver needs some structs and defines which are currently
in dss.h, which is for the old DSS driver.
Move the required structs and defines from dss.h to omapdss.h.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dss.h | 41 ++
Call to omap_drm_irq_install() may fail with an error code. In such a
case the driver probe should fail.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/om
Add ovl_name() and mgr_name() to dispc_ops and get rid of adhoc names
here and there in the omapdrm code. This moves the names of hardware
entities to omapdss side where they have to be when new omapdss
backend drivers are introduced.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
dr
> > Yes.
>
> Would it make sense for virtio-gpu to map buffers to the guest via PCI BARs?
> So we can use a single drm driver for both 2d and 3d.
Should be doable.
I'm wondering two things though:
(1) Will shmem actually help avoiding a copy?
virtio-gpu with virgl will (even if the guest doesn
Free Electrons is now Bootlin.
Signed-off-by: Boris Brezillon
---
Note that I'm planning to take this patch through the MTD tree.
---
.mailmap| 7 ---
MAINTAINERS | 10 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/.mailmap b/.mailmap
index e18cab73e209..50c1
Quoting Christian König (2018-02-16 09:31:23)
> i915 is the only driver using those fields in the drm_gem_object
> structure, so they only waste memory for all other drivers.
>
> Move the fields into drm_i915_gem_object instead and patch the i915 code
> with the following sed commands:
>
> sed -i
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #15 from Hein-Pieter van Braam ---
I just upgraded to 4.16.0-rc1 and the problem is still there with dc=1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.
Move the fields into drm_i915_gem_object instead and patch the i915 code
with the following sed commands:
sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/
We use our own backing store and don't need the shmem file.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 15
We use our own backing store and don't need the shmem file.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_objec
On Wed, Feb 14, 2018 at 09:08:54PM +0100, Jernej Skrabec wrote:
> This patch series implements support for A83T DW HDMI and PHY. Contrary to
> v1 series, this one is based on latest linux-next, since all needed patches
> were merged.
>
> While exactly this combination of HDMI controller and PHY is
[trimming cc: a little to avoid spamming folks not directly involved with i915]
On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > on runtime sus
https://bugs.freedesktop.org/show_bug.cgi?id=104597
--- Comment #13 from Michel Dänzer ---
(In reply to gloriouseggroll from comment #12)
> adding this for obs resolves
> https://bugs.freedesktop.org/show_bug.cgi?id=104540
That probably means it's an OBS bug, not handling 10bpc configs correctly
On Thu, Feb 15, 2018 at 02:04:09AM +0200, Laurent Pinchart wrote:
> The internal LVDS encoder now has DT bindings separate from the DU. Port
> the device tree over to the new model.
>
> Signed-off-by: Laurent Pinchart
I have marked this and the following dts patches in this series
as Deferred. P
rk3399 has the option of setting per-plane gamma.
The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has
at least 3 optional stages, two of those being degamma and gamma, and
they can be configured per-plane.
I'm not sure about Intel HW. I think they might have something similar
plan
On Thu, Feb 15, 2018 at 02:04:08AM +0200, Laurent Pinchart wrote:
> The HDMI encoder is connected to the RGB output of the DU, which is
> port@0, not port@1. Fix the incorrect DT description.
>
> Signed-off-by: Laurent Pinchart
This patch is already queued up for v4.17.
_
https://bugs.freedesktop.org/show_bug.cgi?id=105076
--- Comment #5 from Marta Löfstedt ---
idea is to change the disk on glkb1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesk
97 matches
Mail list logo
