Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
v3: (Rodrigo)
- add return false
Cc: Rodrigo Vivi
Cc: Jim
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170106/0bbee6f4/attachment-0001.html>
are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/55aa150c/attachment.html>
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170106/80be984c/attachment.html>
Reports live state of PSR2 form PSR2_STATUS register.
bit field 31:28 gives the live state of PSR2.
It can be used to check if system is in deep sleep,
selective update or selective update standby.
During video play back, we can use this to check
if system is entering SU mode or not.
when system
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
v2: (Rodrigo)
- Move the check to intel_psr_match_conditions
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala
Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.
Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.
v2: (Ilia Mirkin)
- Remove
As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
must be programmed.
Enable bit 12 for programmable header packet.
Enable bit 15 for Y cordinate support.
v2: (Rodrigo)
- move CHICKEN_TRANS_EDP bit set logic right
after setup_vsc
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: vathsala nagaraju
Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 42837 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/378adde6/attachment-0001.gz>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/2a2eec31/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/1b52ff59/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170106/808c9b2c/attachment-0001.html>
nts/20170106/16e0262b/attachment.html>
ILE on CIK-VI.
I have attached the output when glxgears is debugged with gdb.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20
Hei,
839ca903f12e (drm/nouveau/kms/nv50: transition to atomic interfaces internally,
2016-11-04) seems to introduce a regression on my machine. Attached dmesg
output. Has anyone else seen this on a MacBookPro?
Thanks.
--
Mit freundlichen GrüÃen
Alexander Alemayhu
-- next part
On Fri, 2017-01-06 at 17:55 +, Nagaraju, Vathsala wrote:
> 1) I am still not able to get psr1 working on y-cordinate panels. Only psr2
> works.
> 2) I haven't got a GTC panel to test this scenario. Once we test psr1 on psr2
> GTC panel, we could add dev_priv->psr.psr2_support = false; till
On Sat, 2017-01-07 at 00:28 +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
> must be programmed.
> Enable bit 12 for programmable header packet.
> Enable bit 15 for Y cordinate support.
>
> v2: (Rodrigo)
> - move CHICKEN_TRANS_EDP bit set logic right after setup_vsc
> -Original Message-
> From: Jason Gunthorpe [mailto:jgunthorpe at obsidianresearch.com]
> Sent: Friday, January 06, 2017 1:26 PM
> To: Jerome Glisse
> Cc: Sagalovitch, Serguei; Jerome Glisse; Deucher, Alexander; 'linux-
> kernel at vger.kernel.org'; 'linux-rdma at vger.kernel.org';
Am 06.01.2017 um 18:57 schrieb Gabriel Krisman Bertazi:
> The integer returned by the unload hook is ignored by the drm core, so
> let's make it void.
>
> This patch was created using the following Coccinelle semantic script
> (except for the declaration and comment in drm_drv.h):
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=191571
--- Comment #5 from Przemek ---
I can confirm that this commit is makeing problems on A6 6310 APU.
I have compiled kernel 4.9 with reversed patch
[274ad65c9d02bdcbee9bae045517864c3521d530] and I can hibernate without
problems.
Moreover I have
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/999c9ab9/attachment-0001.html>
Hi Dave,
Fixes for 4.10:
- Polaris 12 support
- Add new amd-gfx mailing list to MAINTAINERS file
- UVD clockgating fix
- SI dpm fixes
The following changes since commit 4a401ceeef7bf3bc55f5e913cbf19d6038cf83c6:
Merge tag 'drm-intel-next-fixes-2016-12-22' of
1) I am still not able to get psr1 working on y-cordinate panels. Only psr2
works.
2) I haven't got a GTC panel to test this scenario. Once we test psr1 on psr2
GTC panel, we could add dev_priv->psr.psr2_support = false; till GTC is
implemented.
-Original Message-
From: Vivi,
In case no connector is found while creating the fbdev, gives the
possibility to specify the default fbdev size by firstly checking if the
command line is defining a preferred mode. Else go into fallback and set
1024x768 fbdev size as it was already done.
Cc: Tomi Valkeinen
Signed-off-by:
drm_pick_cmdline_mode width and height parameters are useless.
Just remove them.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/drm_fb_helper.c| 7 +++
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
include/drm/drm_fb_helper.h| 3 +--
3 files
In case no connector is found while creating the fbdev, gives the
possibility to specify the default fbdev size by firstly checking if the
command line is defining a preferred mode. Else go into fallback and set
1024x768 fbdev size as it was already done.
It is usefull in case you forgot to plug
I was going to write the rv-b,
but something came to my mind...
In this case where y_cord_support but we don't have gtc yet, couldn't we
enable PSR1 instead?
in this case instead of return false we would do
dev_priv->psr.psr2_support = false;
what do you think/advise?
On Fri, 2017-01-06 at
2017ë
01ì 06ì¼ 17:18ì Andi Shyti ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> Thanks for the reply, but...
>
+static const struct drm_display_mode default_mode = {
+ .clock = 222372,
+ .hdisplay = 1440,
+ .hsync_start = 1440 + 1,
+ .hsync_end = 1440 + 1 + 1,
+
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/639dad3d/attachment.html>
On Fri, 2017-01-06 at 21:59 +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
> must be programmed.
> Enable bit 12 for programmable header packet.
> Enable bit 15 for Y cordinate support.
>
> v2: (Rodrigo)
> - move CHICKEN_TRANS_EDP bit set logic right
> after
Reviewed-by: Rodrigo Vivi
On Fri, 2017-01-06 at 22:02 +0530, vathsala nagaraju wrote:
> Reports live state of PSR2 form PSR2_STATUS register.
> bit field 31:28 gives the live state of PSR2.
> It can be used to check if system is in deep sleep,
> selective update or selective update standby.
>
On Fri, 2017-01-06 at 22:21 +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
>
> v2: (Rodrigo)
> - Move the check to
Hi Inki,
Thanks for the reply, but...
> >> +static const struct drm_display_mode default_mode = {
> >> + .clock = 222372,
> >> + .hdisplay = 1440,
> >> + .hsync_start = 1440 + 1,
> >> + .hsync_end = 1440 + 1 + 1,
> >> + .htotal = 1440 + 1 + 1 + 1,
> >> + .vdisplay = 2560,
> >> +
Hi Jose,
On Friday 06 Jan 2017 10:07:03 Jose Abreu wrote:
> Hi Laurent,
>
> Sorry for the delayed answer but I am quite busy at the moment.
No worries, your help is really appreciated.
> On 06-01-2017 01:48, Laurent Pinchart wrote:
>
> [snip]
>
> The TX_READY signal is documented in the
Some SoC without MMU have display driver where a drm/kms driver
could be implemented.
Before doing such kind of thing drm/kms must allow to use mmuless devices.
This patch propose to remove MMU configuration flag and add a cma helper
function to help implementing mmuless display driver
version
The integer returned by the unload hook is ignored by the drm core, so
let's make it void.
This patch was created using the following Coccinelle semantic script
(except for the declaration and comment in drm_drv.h):
Compile-tested only.
//
@ get_name @
struct drm_driver drv;
identifier fn;
@@
Hi Dave,
Here is an update of the STI drm driver.
It contains file cleanup and various fixes.
Regard,
Vincent
The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d:
Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next
(2016-12-13 14:29:05 +1000)
On 17-01-04 20:42:23, Ville Syrjälä wrote:
>From: Ville Syrjälä
>
>This series enables the SKL+ display engine render decompression
>support. Some bits and pieces of the i915 code are based on work
>from various people, but I just put my name on it since it
>would be hard to figure out which
Allows usage of the new page_flip_target hook for drivers implementing
the atomic path.
Provides default atomic helper for the new hook.
v2:
Update code sharing logic between exsiting and the new flip hooks.
Improve kerneldoc.
Signed-off-by: Andrey Grodzovsky
---
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
v2: Reuse drm_crtc_wait_one_vblank
Update
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 100644
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store
On Fri, Jan 06, 2017 at 10:15:03AM +0100, Benjamin Gaignard wrote:
> Each time new data has being added in CRC list inform reader by calling
> wake_up_interruptible().
> This should avoid to do it in all drivers.
>
> Signed-off-by: Benjamin Gaignard
> Cc: Tomeu Vizoso
> Cc: Daniel Vetter
On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
> Make a generic API for all of this and you'd have my vote..
>
> IMHO, you must support basic pinning semantics - that is necessary to
> support generic short lived DMA (eg filesystem, etc). That hardware
> can clearly do that if it can support
2017ë
01ì 06ì¼ 14:22ì Andi Shyti ì´(ê°) ì´ ê¸:
> Hi Hoegeun,
>
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +
On Wed, Jan 04, 2017 at 09:23:34PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> Thanks for your patches!
>
> On 4 January 2017 at 20:40, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote:
> >> As the fence->status is an optional field that may be set before
>
Hi Hoegeun,
> +static const struct drm_display_mode default_mode = {
> + .clock = 222372,
> + .hdisplay = 1440,
> + .hsync_start = 1440 + 1,
> + .hsync_end = 1440 + 1 + 1,
> + .htotal = 1440 + 1 + 1 + 1,
> + .vdisplay = 2560,
> + .vsync_start = 2560 + 1,
> +
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/efdae206/attachment.html>
Hi Hoegeun,
On Thu, Jan 05, 2017 at 07:20:09PM +0900, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
>
Rodrigo,
The code is
if (dev_priv->psr.psr2_support) {
/* PSR2 is restricted to work with panel resolutions
upto 3200x2000 */
if (crtc->config->pipe_src_w > 3200 ||
crtc->config->pipe_src_h > 2000)
+rantogno
Rafael, I finally discovered the source of the bug I was hitting.
On Fri 06 Jan 2017, Chad Versace wrote:
> Was this a mistake in the API? If so, can we fix this ABI mistake before
> kernel consumers rely on this?
>
> I naïvely expected that OUT_FENCE_PTR would be a pointer to,
On 01/06/2017 11:21 AM, Benjamin Gaignard wrote:
> 2017-01-06 10:58 GMT+01:00 Daniel Vetter :
>> On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote:
>>> 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
On 5 January 2017 at 12:12, Benjamin Gaignard
wrote:
> Use CRC API to
Was this a mistake in the API? If so, can we fix this ABI mistake before
kernel consumers rely on this?
I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a fence
fd (s32 __user *). But it's not. It's s64 __user *. Due to that surprise, I
spent several hours chasing down
On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote:
> On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> > > On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:
> > >
> > > > > I still don't understand
Hello, I've been watching this thread not as a kernel developer, but
as an user interested in doing peer-to-peer access between network
card and GPU. I believe that merging raw direct access with vma
overcomplicates things for our use case. We'll have a very large
camera streaming data at high
On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
>> On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:
>>
I still don't understand what you driving at - you've said in both
cases a user VMA exists.
>>> In the
On Fri, Jan 06, 2017 at 12:37:22PM -0500, Jerome Glisse wrote:
> On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote:
> > On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> > > > On Thu, Jan 05, 2017 at 06:23:52PM
2017-01-06 10:58 GMT+01:00 Daniel Vetter :
> On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote:
>> 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
>> > On 5 January 2017 at 12:12, Benjamin Gaignard
>> > wrote:
>> >> Use CRC API to retrieve the 3 crc values from hardware.
>> >>
>> >>
On Thu, Jan 05, 2017 at 12:40:29PM +0200, Peter Ujfalusi wrote:
> On 01/05/2017 10:43 AM, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 02:00:53PM +0200, Peter Ujfalusi wrote:
> >> Instead of scheduling the work to handle the initial delayed event, use 1s
> >> delay.
> >>
> >> When the delayed
On Wed, Jan 04, 2017 at 10:12:57AM +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add
On Fri, Jan 06, 2017 at 10:06:50AM +0100, Benjamin Gaignard wrote:
> 2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
> > On 5 January 2017 at 12:12, Benjamin Gaignard
> > wrote:
> >> Use CRC API to retrieve the 3 crc values from hardware.
> >>
> >> Signed-off-by: Benjamin Gaignard
> >> ---
> >> This
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> Implement the .set_crc_source() callback and call the DP helpers
> accordingly to start and stop CRC capture.
>
> This is only done if this CRTC is currently using the eDP connector.
>
> v3: Remove superfluous check on
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> Adds helpers for starting and stopping capture of frame CRCs through the
> DPCD. When capture is on, a worker waits for vblanks and retrieves the
> frame CRC to put it in the queue on the CRTC that is using the
> eDP connector, so it's passed
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
wrote:
> This backpointer allows DP helpers to access the connector it's being
> used for.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> include/drm/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h
Use CRC API to retrieve the 3 crc values from hardware.
Signed-off-by: Benjamin Gaignard
---
This patch should be applied on top of drm-misc branch where Tomeu
has change crc.lock.
Cc: Tomeu Vizoso
Cc: Daniel Vetter
---
drivers/gpu/drm/sti/sti_crtc.c | 23 ++
Each time new data has being added in CRC list inform reader by calling
wake_up_interruptible().
This should avoid to do it in all drivers.
Signed-off-by: Benjamin Gaignard
Cc: Tomeu Vizoso
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs_crc.c | 2 ++
1 file changed, 2 insertions(+)
diff
Hi Laurent,
Sorry for the delayed answer but I am quite busy at the moment.
On 06-01-2017 01:48, Laurent Pinchart wrote:
[snip]
The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
output signal, but there seems to be no HDMI TX register from which its
state
2017-01-06 9:22 GMT+01:00 Tomeu Vizoso :
> On 5 January 2017 at 12:12, Benjamin Gaignard
> wrote:
>> Use CRC API to retrieve the 3 crc values from hardware.
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> This patch should be applied on top of drm-misc branch where Tomeu
>> has change crc.lock.
On 5 January 2017 at 12:12, Benjamin Gaignard
wrote:
> Use CRC API to retrieve the 3 crc values from hardware.
>
> Signed-off-by: Benjamin Gaignard
> ---
> This patch should be applied on top of drm-misc branch where Tomeu
> has change crc.lock.
>
> I think that wake_up_interruptible() could
Hi Linus,
This pull request has a merge conflict and requires a build fix with
kvmgt (merged in ed40875), which is a consumer of the new vfio-mdev
work. Stephen Rothwell has fixed both of these correctly for
linux-next as documented here:
merge conflict:
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/a8054767/attachment.html>
n't help, you could try bisecting
between LLVM 3.9.0 and 3.9.1.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/4c
.org/archives/dri-devel/attachments/20170106/9a8f81f4/attachment.html>
Hi Bartlomiej,
On Thu, 05 Jan 2017 12:45:32 +0100 Bartlomiej Zolnierkiewicz wrote:
>
> Could you please add:
>
> git://github.com/bzolnier/linux.git fbdev-for-next
>
> To the linux-next tree?
>
> Linus has recently accepted u pull request from the fbdev-v4.10-rc2
> tag that added fbdev
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/b33d6e73/attachment.html>
On 3 January 2017 at 20:23, Lorenzo Stoakes wrote:
> Hi All,
>
> Just a gentle ping on this one :)
>
> Cheers, Lorenzo
>
> On 1 November 2016 at 19:43, Lorenzo Stoakes wrote:
>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
>> and takes advantage of VM_FAULT_RETRY
On 6 January 2017 at 04:29, Linus Torvalds
wrote:
> On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote:
>>
>> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
>
> I'm going to ignore this on the assumption that Dave is around. But if
> nothing happens for a few days, ping me again and
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/8a25b22c/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170106/e80558d9/attachment.html>
Hi Jose,
On Thursday 05 Jan 2017 17:33:58 Laurent Pinchart wrote:
> On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> > On 05-01-2017 12:29, Laurent Pinchart wrote:
> >> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >>> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue,
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/723b7ec0/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/9ec9d3c4/attachment.html>
Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170106/372a2b30/attachment.html>
88 matches
Mail list logo
