https://bugs.freedesktop.org/show_bug.cgi?id=101653
--- Comment #4 from Alexander Tsoy ---
(In reply to Alex Deucher from comment #3)
> Created attachment 132374 [details] [review]
> possible fix
It works. Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.___
Change-Id: Iac1c4870253e8b8860a61b7cf175e7a25cc95921
Signed-off-by: Samuel Li
---
Makefile.sources | 10 +-
amdgpu/Makefile.am | 3 +-
amdgpu/Makefile.sources | 7 +-
amdgpu/amdgpu_asic_id.c | 219 ---
amdgpu/amdgpu_device.c | 7 +-
amdgpu/amdgpu_i
No functional change. Just organizing the code
so it gets clear for future platforms.
Paulo deserves credits becuase he was the one
that just noticed this IS_9XX was in the wrong position
after CNL patches got introduced.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h |
From: Fabio Estevam
When enable_gpio is provided via an I2C or SPI expander, it may not be
available when panel-simple probes leading to the following error:
panel-simple panel: failed to request GPIO: -517
As this error message is not very useful to the end user, skip printing
it in the case o
Change-Id: I24b6624789d1a9dc0fd3a446b0e6f21ed5183ff2
Signed-off-by: Samuel Li
---
radeon/Makefile.am | 6 +++
radeon/Makefile.sources | 6 ++-
radeon/radeon_asic_id.c | 106
radeon/radeon_asic_id.h | 37 +
4 files changed,
On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> wrote:
> >> And if the GEM folks insist the old behavior can't be restored, then we
> >> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
> >> in i915_sw_fence
On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
wrote:
>> And if the GEM folks insist the old behavior can't be restored, then we
>> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
>> in i915_sw_fence. Force-completing all render requests atomic updates
>> depend upon is i
On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Add drm_crtc_vblank_get_accurate() which is the same as
>> drm_crtc_vblank_get() except that it will forcefully update the
>> the cur
On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> if no output is connected at framebuffer setup time, we get a default
> 1024x768 mode that is going to be used when we first connect a monitor.
> After the commit, on fir
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commi
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v5: call drm_atomic_helper_async_check() from the check hook
v4: add missing atomic asyn
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
Tested-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++--
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we
From: Gustavo Padovan
Hi,
Follow up after Daniel's comments. Here I move the common async code to
drm_atomic_helper.c. i915 and msm now have to call the
drm_atomic_helper_async_check() themselves.
Please review! Thanks.
Gustavo
Gustavo Padovan (6):
drm/atomic: initial support for asynchron
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v4:
- call drm_atomic_helper_async_check() from the check hook
v3:
- set corr
Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
if no output is connected at framebuffer setup time, we get a default
1024x768 mode that is going to be used when we first connect a monitor.
After the commit, on first connection after deferred setup, we probe
the monitor and
On Sat, Jul 01, 2017 at 12:14:44AM +1000, Jonathan Liu wrote:
> Hi Chen-Yu and Maxime,
>
> On 30 June 2017 at 13:16, Chen-Yu Tsai wrote:
> > On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu wrote:
> >> Hi Maxime,
> >>
> >> On 30 June 2017 at 01:56, Maxime Ripard
> >> wrote:
> >>> On Wed, Jun 28, 2
On Fri, Jun 30, 2017 at 03:30:33PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Introduce an rw_semaphore to protect the di
Quoting Daniel Vetter (2017-06-30 16:30:59)
> On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chri
series pushed to libdrm. Thanks for the review.
On Thu, Jun 29, 2017 at 3:16 PM, Clint Taylor
wrote:
> Reviewed-by: Clinton Taylor
>
> -Clint
>
>
>
>
> On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
>>
>> By the Spec all CNL Y skus are 2+2, i.e. GT2.
>>
>> This is a copy of merged i915's
>> commit
On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > > > Quoting ville.syrj...@linux.
On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add drm_crtc_vblank_get_accurate() which is the same as
> drm_crtc_vblank_get() except that it will forcefully update the
> the current vblank counter/timestamp value even if the interrupt
> i
On Fri, Jun 30, 2017 at 10:59:15AM +0300, Dan Carpenter wrote:
> We recently added an integer overflow check but it needs an additional
> tweak to work properly on 32 bit systems.
>
> The problem is that we're doing the right hand side of the assignment as
> type unsigned long so the max it will h
Regards
Shashank
On 6/30/2017 7:45 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On
From: Ville Syrjälä
Make sure that we have an up to date vblank counter value for sending
out the completion event. On gen2/3 the vblank irq fires at frame start
rather than at start of vblank, so if we perform an update between
vblank start and frame start we would potentially sample a stale vbl
From: Ville Syrjälä
Add drm_crtc_vblank_get_accurate() which is the same as
drm_crtc_vblank_get() except that it will forcefully update the
the current vblank counter/timestamp value even if the interrupt
is already enabled.
And we'll switch drm_wait_one_vblank() over to using it to make sure it
From: Ville Syrjälä
To make sure intel_atomic_wait_for_vblanks() really waits for at least
one vblank let's switch to using drm_crtc_vblank_get_accurate().
Also toss in a FIXME that we should really be sampling the vblank
counter when we did the plane/wm update instead of resampling it
potential
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> > > Regards
> > >
> > > Shashank
> > >
> > >
> > > On 6/27/2017 5:46 PM, Ander Cons
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #7 from Andreas Brogle (an...@ok.de) ---
Hello Michel,
is that what you need ?
The last 7 turns caused a kernel panic, all the 4.10.0-rc1 versions. I declared
them as bad with git bisect. Hence I can't say if that ring 0 bug does exis
https://bugs.freedesktop.org/show_bug.cgi?id=101653
--- Comment #3 from Alex Deucher ---
Created attachment 132374
--> https://bugs.freedesktop.org/attachment.cgi?id=132374&action=edit
possible fix
Depends on attachment 132358.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=101654
Shmerl changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi, Daniel,
If possible, throw it into drm-misc. We have no changes for the next
merge window at this time so it's a bit unnecessary to generate a
separate pull request for this.
Thanks,
Thomas
On 06/30/2017 03:39 PM, Daniel Vetter wrote:
Want me to throw this into drm-misc too, or will yo
On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver. All drivers have changes to deal with the
> clean up. In order to allo
On Fri, Jun 30, 2017 at 03:36:50PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 04:26:49PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 03:12:51PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 03:27:29PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > > > From: Ville Syrjälä
> > > >
>
On Wed, Jun 28, 2017 at 03:28:12PM +0200, Maarten Lankhorst wrote:
> Without waiting for hw_done, previous atomic updates may dereference
> the wrong state and cause a lot of confusion. The real fix is fixing
> all obj->state to use the accessor macros, but for now wait
> indefinitely and interrupt
Want me to throw this into drm-misc too, or will you pick this up in
wmvgfx trees? Since it's not tree-wide there's no reason for it to go
through drm-misc.
-Daniel
On Fri, Jun 30, 2017 at 3:04 PM, Thomas Hellstrom wrote:
> Reviewed-by: Thomas Hellstrom
>
>
>
> On 06/30/2017 11:36 AM, Laurent Pi
Reviewed-by: Thomas Hellstrom
On 06/30/2017 11:36 AM, Laurent Pinchart wrote:
The CRTC .prepare() helper operation is legacy code, drivers should
use the .atomic_disable() operation instead.
When a CRTC is temporarily disabled prior to a mode set, the atomic
helpers call the .prepare() operat
On Fri, Jun 30, 2017 at 04:26:49PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 03:12:51PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 03:27:29PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Make sure the armed even doesn't fire until
On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > > From: Ville Syrjälä
> > >
> > > Introduce an rw_semaphore to protect the display commits. All normal
On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Introduce an rw_semaphore to protect the display commits. All normal
> > commits use down_read() and hence can proceed in
On Fri, 2017-06-30 at 17:47 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > This patch sets the is_hdmi2_src identifier in drm connector
> > > for GLK platform
On Fri, Jun 30, 2017 at 03:12:51PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 03:27:29PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make sure the armed even doesn't fire until the next vblank by adding
> > one to the current vblank counter value. This w
On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other com
On Thu, Jun 29, 2017 at 04:49:44PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Pull the code to reallocate the state->connectors[] array into a
> helper function. We'll have another use for this later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomi
On Fri, Jun 30, 2017 at 03:27:29PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure the armed even doesn't fire until the next vblank by adding
> one to the current vblank counter value. This will prevent the event
> being fired off prematurely if drm_handle_vblank(
Hi Daniel,
2017-06-30 Daniel Vetter :
> Core code should never have to look at helper stuff, to make sure that
> all helper code is 100% optional and can be overriden.
>
> Cc: Gustavo Padovan
> Signed-off-by: Daniel Vetter
Reviewed-by: Gustavo Padovan
Gustavo
___
Hi Dieter,
thanks a lot for testing that.
But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...
Well, actually you only need to figure out how to enable a PCIe window
above the 4GB limit.
Could be that the BIOS supports this
On Fri, Jun 30, 2017 at 12:36:45PM +0300, Laurent Pinchart wrote:
> The CRTC .disable() helper operation is deprecated for atomic drivers,
> the new .atomic_disable() helper operation being preferred. Convert all
> atomic drivers to .atomic_disable() to avoid cargo-cult use of
> .disable() in new d
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
With a real commit message (just explain why it's needed):
Reviewed-by: Daniel Vetter
Also needs
Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.")
Cc: sta...@vger.ker
Am 30.06.2017 um 14:39 schrieb Daniel Vetter:
On Fri, Jun 30, 2017 at 08:47:27AM +0200, Christian König wrote:
Am 30.06.2017 um 04:24 schrieb Michel Dänzer:
On 29/06/17 07:05 PM, Daniel Vetter wrote:
On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
On 29/06/17 05:23 PM, Christia
On Thu, Jun 29, 2017 at 05:17:39PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/drm_framebuffer.c | 1 +
> >
On Fri, Jun 30, 2017 at 08:47:27AM +0200, Christian König wrote:
> Am 30.06.2017 um 04:24 schrieb Michel Dänzer:
> > On 29/06/17 07:05 PM, Daniel Vetter wrote:
> > > On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
> > > > On 29/06/17 05:23 PM, Christian König wrote:
> > > > > Am 29.0
On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > Hi,
> >
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe
From: Ville Syrjälä
Make sure the armed even doesn't fire until the next vblank by adding
one to the current vblank counter value. This will prevent the event
being fired off prematurely if drm_handle_vblank() is called
redundantly, or if the irq handler gets delayed somehow.
This is actually a
Regards
Shashank
On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID hand
Regards
Shashank
On 6/30/2017 5:28 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR4
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> This patch sets the is_hdmi2_src identifier in drm connector
> for GLK platform. GLK contains a native HDMI 2.0 controller.
> This identifier will help the EDID handling functions to save
> lot of work which is specific to HDMI 2.0 sources
Regards
Shashank
On 6/30/2017 5:16 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:25 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
CEA-861-F adds ycbcr capability map b
The patch
drm: adv7511_audio: Add .get_dai_id callback to map port number to dai id
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To get a YCBCR420 outpu
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:25 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
> >> CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> >> This block conta
https://bugzilla.kernel.org/show_bug.cgi?id=84041
Jani Nikula (jani.nik...@intel.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Res
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To get a YCBCR420 output from intel platforms, we need one
> > > scaler to scale do
On Fri, 2017-06-30 at 11:33 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To support ycbcr HDMI output, we need a pipe CSC block to
> > > do the RGB->YCBCR c
On Thu, Jun 29, 2017 at 12:58:02PM +, Mukunda, Vijendar wrote:
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, June 28, 2017 11:36 PM
> To: Alex Deucher
Please fix your mail client to quote mails in a more normal fashion,
this looks pretty broke
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #22 from Carlo Caione ---
Just to keep you updated we have verified that with a bigger VRAM this is not
reproducible anymore.
--
You are receiving this mail because:
You are the assignee for the bug.
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.
Signed-off-by: Laurent Pinchart
Acked-by: Maxime Ripard # for s
The CRTC .prepare() helper operation is legacy code, drivers should
use the .atomic_disable() operation instead.
When a CRTC is temporarily disabled prior to a mode set, the atomic
helpers call the .prepare() operation if provided instead of the
.atomic_disable() operation. In order to avoid modif
Hello,
The first version of this patch series removed legacy CRTC helper operations
from most atomic drivers, and got partially merged in the drm-misc tree. This
second version is a repost of the two unmerged patches from the original
series, with an additional patch to complete removal of the las
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.
Hi,
On Fri, Jun 30, 2017 at 08:22:13AM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On 30 June 2017 at 01:56, Maxime Ripard
> wrote:
> > On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
> >> >> + u32 int_status;
> >> >> + u32 fifo_status;
> >> >> + /* Read needs empty fla
Hi Dan,
Thank you for the patch.
On Friday 30 Jun 2017 11:00:12 Dan Carpenter wrote:
> "params" can't be NULL here. The next lines assume that we either
> hit the break statement of "params->mpixelclock == ~0UL". The
> inconsistent NULL checking makes static checkers complain. I've just
> remo
On 30/06/17 11:58, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
>> On 29/06/17 21:50, Aaro Koskinen wrote:
>>> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
On 15/06/17 01:11, Aaro Koskinen wrote:
> When booting v4.12-rc5
On 29.06.2017 17:22, Eric Anholt wrote:
> Andrzej Hajda writes:
>
>> On 29.06.2017 07:03, Archit Taneja wrote:
>>> On 06/28/2017 01:28 AM, Eric Anholt wrote:
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings. Those get registered as DSI
On 30/06/17 09:41, Tomi Valkeinen wrote:
> So, I don't know... I guess I need to try to invent some horrible hacks
> around the driver to somehow manage the omap3 problems. Perhaps
> disabling/enabling the outputs when sync lost happens...
Well, I tried that (attached), but it didn't work either.
"params" can't be NULL here. The next lines assume that we either
hit the break statement of "params->mpixelclock == ~0UL". The
inconsistent NULL checking makes static checkers complain. I've just
removed the test.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi
We recently added an integer overflow check but it needs an additional
tweak to work properly on 32 bit systems.
The problem is that we're doing the right hand side of the assignment as
type unsigned long so the max it will have an integer overflow instead
of being larger than SIZE_MAX. That mean
On Fri, Jun 30, 2017 at 09:30:50AM +0200, Daniel Vetter wrote:
> On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The cur
https://bugs.freedesktop.org/show_bug.cgi?id=101499
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #21
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #6 from Michel Dänzer (mic...@daenzer.net) ---
That's not the end of the bisection yet. Every time you run "git bisect
good/bad/skip", it will check out a new commit that you need to compile and
test, and print the estimated number of
Core code should never have to look at helper stuff, to make sure that
all helper code is 100% optional and can be overriden.
Cc: Gustavo Padovan
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drive
On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thu
On Wed, Jun 28, 2017 at 05:54:56PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add support to async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> intel_legacy_cursor_update() did but through atomic.
>
> v3:
> - s
87 matches
Mail list logo
