https://bugs.freedesktop.org/show_bug.cgi?id=99488
Bug ID: 99488
Summary: [r600g]OpenCL driver causes process to hang in
ImageMagick's Gaussian Blur kernel
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
Instead of always sending commands in LP mode, respect the
MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also
request acks if MIPI_DSI_MSG_REQ_ACK is set.
Signed-off-by: John
https://bugs.freedesktop.org/show_bug.cgi?id=96488
nixscrip...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
As an aid to debugging.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
As a side-effect of this, encode the endianness explicitly rather than
casting a u16.
Signed-off-by: John Keeping
---
Unchanged in v2
---
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
According to DW mipi dsi
From: Shawn Guo
With the vblank hooks in struct drm_crtc_funcs, we do not need to
maintain struct rockchip_crtc_funcs and the related registration
functions. Remove them.
Signed-off-by: Shawn Guo
Cc: Mark Yao
---
From: Shawn Guo
The vblank hooks in struct drm_driver are deprecated and only meant for
legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
in struct drm_crtc_funcs should be used instead.
Signed-off-by: Shawn Guo
Cc: Liviu Dudau
From: Shawn Guo
The vblank is mostly CRTC specific and implemented as part of CRTC
driver. Let's keep the vblank hooks struct drm_driver for legacy
drivers, and add corresponding hooks in struct drm_crtc_funcs. These
hooks take struct drm_crtc pointer as argument, and
From: Shawn Guo
With the vblank hooks in struct drm_crtc_funcs, we do not need to
maintain the CRTC specific vblank callbacks with struct
imx_drm_crtc_helper_funcs any more. By moving the stuff that we
currently do in imx_drm_add_crtc(), like of_node setting and
From: Shawn Guo
With the vblank hooks in struct drm_crtc_funcs, we can directly use the
drm_crtc pointer passed in as parameter and make the functions static.
The functions are moved around to save forward delarations.
Signed-off-by: Shawn Guo
---
From: Shawn Guo
The vblank is mostly CRTC specific and implemented as part of CRTC
driver. The first patch adds 3 vblank core-driver hooks into struct
drm_crtc_funcs, and wraps around core vblank handling code to use the
new hooks for modern MODESET drivers and the ones in
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
This is not needed since we can access the mode via the CRTC from the
enable hook. Also remove the "mode" field that is no longer used.
Signed-off-by: John Keeping
---
New
Hi John
Reviewed-by: Chris Zhong
On 01/22/2017 12:31 AM, John Keeping wrote:
This shows that we only use the mode from the enable function and
prepares us to remove the "mode" field and the mode_set hook in the next
commit.
Signed-off-by: John Keeping
Hi John
On 01/22/2017 12:31 AM, John Keeping wrote:
With atomic modesetting the hardware will be powered off when the
mode_set function is called. We should configure the hardware in the
commit function (or even the enable function, but switching from commit
to enable is left for a future
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #6 from Shmerl ---
(In reply to Grazvydas Ignotas from comment #5)
>
> They range from GL_COMBINER0_NV (0x8550) to 0x857f, so probably the trace
> was recorded on something supporting more texture units than
Hi John
On 01/22/2017 12:31 AM, John Keeping wrote:
I haven't found any method for getting the length of a response, so this
just uses the requested rx_len
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54
On 01/22/2017 12:31 AM, John Keeping wrote:
These values are specified as constant time periods but the PHY
configuration is in terms of the current lane byte clock so using
constant values guarantees that the timings will be outside the
specification with some display configurations.
Derive
Hi Chris,
Thank you for the patch.
On Saturday 21 Jan 2017 10:58:25 Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
>
https://bugs.freedesktop.org/show_bug.cgi?id=99419
Andreas Schultes changed:
What|Removed |Added
See Also|
Chris Wilson writes:
> The prototypes were moved to a new header, but the function definitions
> were not updated to pull in the declarations.
>
> drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for
> ‘drm_clflush_pages’ [-Wmissing-prototypes]
>
https://bugs.freedesktop.org/show_bug.cgi?id=99486
--- Comment #1 from Armin K ---
Created attachment 129088
--> https://bugs.freedesktop.org/attachment.cgi?id=129088=edit
dmesg output of the currently running system
xf86-video-amdgpu 1.2.0
mesa 13.0.3
xorg-server 1.19.1
https://bugs.freedesktop.org/show_bug.cgi?id=99486
Bug ID: 99486
Summary: AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status:
The prototypes were moved to a new header, but the function definitions
were not updated to pull in the declarations.
drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for
‘drm_clflush_pages’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_cache.c:120:1: warning: no previous prototype
Am 19.01.2017 11:20, schrieb Thierry Reding:
> Adding back dri-devel@lists.freedesktop.org
>
> On Wed, Jan 18, 2017 at 12:21:23PM +0100, walter harms wrote:
>>
>>
>> Am 18.01.2017 10:02, schrieb Thierry Reding:
>>> Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=98520
--- Comment #32 from Ali Hakkı Demiral ---
i test on windows 10 with Uniengine Heaven directx 11 it crash again.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=99484
Bug ID: 99484
Summary: Crusader Kings 2 - Loading bars, siege bars, morale
bars, etc. do not render correctly
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
https://bugzilla.kernel.org/show_bug.cgi?id=193081
Bug ID: 193081
Summary: amdgpu-related kernel output delays
booting/suspending/resuming
Product: Drivers
Version: 2.5
Kernel Version: 4.9.x, 4.10-rcX
Hardware: All
Hi,
Stopping kmscube application on mx6q through CTRL + C sometimes leads
to the following kernel warning:
^C[ 3939.785516] [ cut here ]
[ 3939.790313] WARNING: CPU: 1 PID: 67 at
drivers/gpu/drm/drm_atomic_helper.c:1032
drm_atomic_helper_wait_for_fences+0xe4/0x104
[
We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 +++--
1 file
I haven't found any method for getting the length of a response, so this
just uses the requested rx_len
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++
1 file changed, 54 insertions(+)
diff
We should configure these functions before enabling them.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
Also don't power up the DSI host at this point since this is not
necessary in order to configure the PHY and we do so later when
selecting video or command mode.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 -
1 file
Instead of always sending commands in LP mode, respect the
MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also
request acks if MIPI_DSI_MSG_REQ_ACK is set.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index
This matches other drivers.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
By dereferencing the MIPI command buffer as a u32* we rely on it being
correctly aligned on ARM, but this may not be the case. Copy it into a
stack variable that will be correctly aligned.
Signed-off-by: John Keeping
---
Unchanged in v2
---
Rockchip DRM is fully atomic and commit is deprecated for atomic
drivers. No changed are needed beyond renaming the function.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
In order to fully reset the state of the MIPI controller we must assert
this reset.
This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.
Signed-off-by: John Keeping
---
Unchanged in v2
Some panels need to be configured with commands sent over the MIPI link,
which they will do in the prepare hook. Call this after the PHY has
been initialized so that we are able to send commands to the panel.
Signed-off-by: John Keeping
---
Unchanged in v2
---
This shows that we only use the mode from the enable function and
prepares us to remove the "mode" field and the mode_set hook in the next
commit.
Signed-off-by: John Keeping
---
New in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 41 ++
1
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index ce1e6f9a2041..cfe7e4ba305c
Use the same calculation as the vendor kernel to derive the escape clock
speed.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
This ensures that the output resolution is known before fbcon loads.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git
These values are specified as constant time periods but the PHY
configuration is in terms of the current lane byte clock so using
constant values guarantees that the timings will be outside the
specification with some display configurations.
Derive the necessary configuration from the byte clock
As an aid to debugging.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index
In a couple of places here we use "val" for the value that is about to
be written to a register but then reuse the same variable for the value
of a status register before we get around to writing it. Rename the
value to be written to so that we write the value we intend to and not
what we have
The multiplication ratio for the PLL is required to be even due to the
use of a "by 2 pre-scaler". Currently we are likely to end up with an
odd multiplier even though there is an equivalent set of parameters with
an even multiplier.
For example, using the 324MHz bit rate with a reference clock
When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the
internal connection but these flags are meaningless for DSI panels.
Switch the test so that we do not set the P{H,V}SYNC bits unless the
mode requires it.
Signed-off-by: John Keeping
---
Unchanged in v2
Requesting the HS clock from the PHY before we initialize it causes an
invalid signal to be sent out since the input clock is not yet
configured. The PHY databook suggests only asserting this signal when
performing HS transfers, so let's do that.
Signed-off-by: John Keeping
As a side-effect of this, encode the endianness explicitly rather than
casting a u16.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
This is not needed since we can access the mode via the CRTC from the
enable hook. Also remove the "mode" field that is no longer used.
Signed-off-by: John Keeping
---
New in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 +
1 file changed, 1 insertion(+), 12
This is a re-roll of a series originally posted back in September [1].
It's mostly unchanged but in response to Chris and Mark's feedback I have
dropped the first two patches and replaces them with the new patches 3
and 4; it's a slightly different approach from Mark's suggestion because
it turns
As the documentation for readx_poll_timeout says, we want to use the
specialized macro for readl rather than using the generic version
directly.
Signed-off-by: John Keeping
---
Unchanged in v2
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 10 +-
1 file changed, 5
With atomic modesetting the hardware will be powered off when the
mode_set function is called. We should configure the hardware in the
commit function (or even the enable function, but switching from commit
to enable is left for a future patch).
Signed-off-by: John Keeping
On Sat, 21 Jan 2017, Manasi Navare wrote:
> This patch series addresses all the review comments from the previous series:
> https://patchwork.freedesktop.org/series/18256/
It does not, and it frustrates me.
BR,
Jani.
>
> On top of that it also adds a fix for CRC
On Sat, Jan 21, 2017 at 12:02:03PM +0100, Noralf Trønnes wrote:
>
> Den 21.01.2017 11:58, skrev Chris Wilson:
> >Some state is coupled into the device lifetime outside of the
> >load/unload timeframe and requires teardown during final unreference
> >from drm_dev_release(). For example, dmabufs
Den 21.01.2017 11:58, skrev Chris Wilson:
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing
60 matches
Mail list logo