For atomic, it will be quite necessary to not need to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to
From: Daniel Vetter
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->
All the call-sites save one need locking. Add an _unlocked() variant
which handles the locking for you. This simplifies the call-sites,
and will make it easier for atomic and ww_mutex conversion.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 +---
drivers/gpu/drm/
I find myself making this change locally whenever debugging FB reference
counting. Which seems a bit silly.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
i
From: Ville Syrj?l?
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrj?l?
Signed-off-by: Rob Clark
--
Add a few more useful helpers to find mode objects.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 90 +++---
include/drm/drm_crtc.h | 33 +
2 files changed, 61 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm
Like range, but values are signed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 45 +
include/drm/drm_crtc.h | 12
include/uapi/drm/drm_mode.h | 1 +
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/driv
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 50 +
include/drm/drm_crtc.h | 27
As suggested by Daniel, splitting out ww_mutex conversion and a few
other bits out.
Daniel Vetter (1):
drm: Split connection_mutex out of mode_config.mutex (v2)
Rob Clark (6):
drm: add object property type
drm: add signed-range property type
drm: helpers to find mode objects
drm: spiff
org/archives/dri-devel/attachments/20140528/401ff247/attachment.html>
Digging out an ooold post of Daniel's...
On 04.03.2014 18:13, Daniel Vetter wrote:
> On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel D?nzer wrote:
>>
>> When the pre/post-modeset hooks were originally added, it worked like
>> this: the pre-modeset hook enabled the vblank interrupt, which update
On Wed, May 28, 2014 at 03:21:41PM +0200, Daniel Vetter wrote:
> On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote:
> > On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter wrote:
> > > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
> > >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vett
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/6232763c/attachment.html>
On Wed, May 28, 2014 at 05:14:21PM +0300, Ville Syrj?l? wrote:
> On Wed, May 28, 2014 at 03:21:41PM +0200, Daniel Vetter wrote:
> > On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote:
> > > On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter wrote:
> > > > On Tue, May 27, 2014 at 04:06:28PM -040
Hi Daniel,
On Wednesday 28 May 2014 15:36:38 Daniel Vetter wrote:
> On Wed, May 28, 2014 at 02:43:36PM +0200, Laurent Pinchart wrote:
> > Commit e3d6ddb35f6221859b6054879d186e13a3af351e ("drm/crtc-helper: don't
> > disable disconnected outputs") made the for each loop over connectors
> > empty in
https://bugzilla.kernel.org/show_bug.cgi?id=77001
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=76861
--- Comment #13 from Christian K?nig ---
Crap, I freared that this could happen.
Please try values of 50,60,70,80,90 as well and see where the limit is that the
lines disapear.
--
You are receiving this mail because:
You are watching the assign
On 27.05.2014 23:49, Christian K?nig wrote:
> From: Christian K?nig
>
> Instead of trying to flip inside the vblank period when
> the buffer is idle, offload blocking for idle to a kernel
> thread and program the flip directly into the hardware.
>
> v2: add error handling, fix EBUSY handling
> v
https://bugzilla.kernel.org/show_bug.cgi?id=76861
--- Comment #12 from Sven Dziadek ---
Ok, new report ;-)
With this line commented out, the lines reappear.
I tried with these values:
dmesg.log_pll_105: 154000 - 154000, pll dividers - fb: 1129.2 ref: 15, post 7
dmesg.log_pll_110: 154000 - 154000
On Wed, May 28, 2014 at 02:43:36PM +0200, Laurent Pinchart wrote:
> Commit e3d6ddb35f6221859b6054879d186e13a3af351e ("drm/crtc-helper: don't
> disable disconnected outputs") made the for each loop over connectors
> empty in __drm_helper_disable_unused_functions(). Remove the loop
> altogether.
>
>
On Tue, May 27, 2014 at 07:47:42PM -0400, Rob Clark wrote:
> On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter wrote:
> > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
> >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter wrote:
> >
> > [snip]
> >
> >> Well, there was the NONBLOCK atomic
https://bugzilla.kernel.org/show_bug.cgi?id=77001
Grzegorz Kowal changed:
What|Removed |Added
Summary|Radeon R9 270X GPU lockup |Radeon R9 270X GPU lockup
On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote:
> On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter wrote:
> > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
> >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter wrote:
> >
> > [snip]
> >
> >> Well, there was the NONBLOCK atomic
On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I tried to test whether it is OK (from point of view of reentrant) to use
> mutex_lock() or mutex_lock_killable() inside shrinker functions when shrinker
> functions do memory allocation, for drivers/gpu/drm/ttm/ttm_page_al
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/8523c237/attachment.html>
Commit e3d6ddb35f6221859b6054879d186e13a3af351e ("drm/crtc-helper: don't
disable disconnected outputs") made the for each loop over connectors
empty in __drm_helper_disable_unused_functions(). Remove the loop
altogether.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc_helper.c | 5 -
On Wed, May 28, 2014 at 06:12:54PM +0900, Michel D?nzer wrote:
>
> Digging out an ooold post of Daniel's...
>
> On 04.03.2014 18:13, Daniel Vetter wrote:
> > On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel D?nzer wrote:
> >>
> >> When the pre/post-modeset hooks were originally added, it worked
On Mon, May 26, 2014 at 04:19:39PM +0200, Philipp Zabel wrote:
> The i.MX Image Processing Unit (IPU) contains a number of image processing
> blocks that sit right in the middle between DRM and V4L2. Some of the modules,
> such as Display Controller, Processor, and Interface (DC, DP, DI) or CMOS
>
On 2014? 05? 28? 05:21, Thierry Reding wrote:
> On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote:
>> 2014-05-27 16:53 GMT+09:00 Thierry Reding :
>>> On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote:
Hi Thierry,
On 05/26/2014 03:41 PM, Thierry Reding wrote:
>
Hi Inki,
On 05/27/2014 02:42 PM, Inki Dae wrote:
> This patch makes sure that exynos drm framework handles deferred
> probe case correctly.
>
> Sub drivers could be probed before resources, clock, regulator,
> phy or panel, are ready for them so we should make sure that exynos
> drm core waits unt
https://bugzilla.kernel.org/show_bug.cgi?id=77001
Bug ID: 77001
Summary: Radeon R9 270X GPU lockup and resume failure after all
night inactivity
Product: Drivers
Version: 2.5
Kernel Version: 3.14.4
Hardware: x86-64
I already tried a similar patch as well, without any more noticeable
crashes. But going to give this another round with your patch and openarena.
Thanks,
Christian.
Am 27.05.2014 23:55, schrieb Marek Ol??k:
> Hi Christian,
>
> I test on Bonaire (ChipID = 0x665c). Unfortunately, the hangs are not
On 28.05.2014 03:10, Christian K?nig wrote:
> From: Christian K?nig
>
> Fill VM page tables from the GART page table if applicable.
>
> v2: fix copy&paste error
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/cik_sdma.c | 21 -
> 1 file changed, 20 insert
Thanks Inki,
I removed fimd_clear_win from fimd_probe and verified this change in chrome
setup. Not seeing any noticeable difference.
I have posted another patch at:
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg31629.html
Thanks everybody for your review effort.
Regards,
System hangs when FIMD registers are accessed to disable
hardware overlays. This is because of the clocks which are
not enabled before register access.
'Hardware overlay disable' is cleaned from the FIMD probe.
Signed-off-by: Rahul Sharma
---
Based on exynos-drm-next branch.
drivers/gpu/drm/ex
On Wed, May 28, 2014 at 9:21 AM, Daniel Vetter wrote:
> On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote:
>> On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter wrote:
>> > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
>> >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter wrote:
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/5693352d/attachment-0001.html>
Hi Inki,
There is no problem with the DSI panels, so there is nothing to fix.
DSI receives notifications about panel presence via mipi dsi bus,
so it can attach/detach it to/from drm using connector's hotplug mechansim.
Deferring DSI in unnecessary.
Regards
Andrzej
On 05/27/2014 02:42 PM, Inki
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140528/a9c58545/attachment.html>
On 05/28/2014 06:50 AM, Inki Dae wrote:
> On 2014? 05? 28? 05:21, Thierry Reding wrote:
>> On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote:
>>> 2014-05-27 16:53 GMT+09:00 Thierry Reding :
On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote:
> Hi Thierry,
>
> On 0
https://bugzilla.kernel.org/show_bug.cgi?id=76981
Bug ID: 76981
Summary: unsave locking
Product: Drivers
Version: 2.5
Kernel Version: 3.15.0-rc6
Hardware: All
OS: Linux
Tree: Fedora
Status: NEW
On Tue, May 27, 2014 at 5:59 PM, Daniel Vetter
wrote:
> After the split-out of crtc locks from the big mode_config.mutex
> there's still two major areas it protects:
> - Various connector probe states, like connector->status, EDID
> properties, probed mode lists and similar information.
> - The
as scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/c0b0e04d/attachment.html>
no
tearing. Possibly related?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/7d52744a/attachment.html>
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140528/c1fa3756/attachment.html>
sts.freedesktop.org/archives/dri-devel/attachments/20140528/536af429/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140528/73ecfd03/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #6 from Alex Deucher ---
It was a long weekend in the US. I haven't had a chance to look into it yet.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter wrote:
[snip]
> Well, there was the NONBLOCK atomic flag.. I'm not entirely sure if we
> should hang so much off of that one flag.
Yeah, a separate VBLANK_SYNCED might be useful. Apparent
49 matches
Mail list logo
