https://bugzilla.kernel.org/show_bug.cgi?id=86351
Lorenzo Bona changed:
What|Removed |Added
CC||lorenz.bona at gmail.com
--- Comment #14
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Split owner removal from rockchip to separate patch (spotted by Mark
Yao).
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
1 file
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
Changes since v1:
1. Split owner removal from rockchip
Hi,
The i2c drivers also do not have to set 'owner' field because
i2c_register_driver() will do it instead.
'owner' is removed from i2c drivers, which I was able to compile
with allyesconfig (arm, arm64, i386, x86_64, ppc64).
Only compile-tested.
The coccinelle script which generated the patch
Add a TFT LCD panel. the TFT LCD panel is WQVGA "480x272",
and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
.../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 49 ++
MAINTAINERS| 1 +
This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
simple panel driver.
Signed-off-by: Jianwei Wang
---
.../bindings/panel/nec,nl4827hc19_05b.txt | 7 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Just so I have a user for this macro.
v2: Use the right macro - somehow I thought gcc should scream at me,
but list_for_each isn't really typesafe unfortunately. Spotted by
Ville.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file
On Fri, Jul 10, 2015 at 07:17:40PM +0800, Jianwei Wang wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
>
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is
On Fri, Jul 10, 2015 at 10:43:11AM +, Wang J.W. wrote:
> Hi Daniel,
>
> Thank you very much for your review!
> See below...
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Friday, July 10, 2015 4:00 PM
> >
On 9 July 2015 at 03:26, Zhou, Jammy wrote:
> Although I don't like the method of manually iterating sysfs, it seems the
> last resort if we want to avoid introducing libudev dependency.
>
I have the same feeling, so if anyone can come with an better solution
I'm all ears.
> Besides, you
On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker
wrote:
> [Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control]
> On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote:
>
>> On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote:
>> > On Fri, Jun 26, 2015 at 02:32:03PM
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/1c4c1608/attachment-0001.html>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/51f84869/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/700bdfba/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/9a1abdd9/attachment.html>
ou 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/20150710/5ceef297/attachment.html>
> rom
--
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/20150710/de454fb4/attachment.html>
river bug. Windows and Linux use the same ucode.
--
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/20150710/a8b39ddf/attachment.html>
windows use the same firmware for DPM?
--
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/20150710/23fd1c91/attachment.html>
AHB clock should be enabled before accessing registers during
enable/disable_vblank(). Since these 2 callbacks are called in
atomic context while clk_prepare may cause thread sleep, a work
is scheduled to control vblanks.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 9
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/62f980ed/attachment.html>
On 10.07.2015 15:50, Mark yao wrote:
> On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
>> i2c_driver does not need to set an owner because i2c_register_driver()
>> will set it.
>>
>> Signed-off-by: Krzysztof Kozlowski
>>
>> ---
>>
>> The coccinelle script which generated the patch was sent
Add a TFT LCD panel node. the TFT LCD panel is
WQVGA "480x272", and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
.../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 49 ++
MAINTAINERS| 1 +
This adds support for the NEC NL4827HC19-05B 480x272 panel to
the DRM simple panel driver.
Signed-off-by: Jianwei Wang
---
.../bindings/panel/nec,nl4827hc19_05b.txt | 8 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
On 2 July 2015 at 02:02, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
>> Adds API that allows callers to find out what other firmware nodes a
>> node depends on.
>>
>> Implementors of bindings documentation can register callbacks that
>> return the
On 2015å¹´07æ10æ¥ 15:01, Krzysztof Kozlowski wrote:
> On 10.07.2015 15:50, Mark yao wrote:
>> On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
>>> i2c_driver does not need to set an owner because i2c_register_driver()
>>> will set it.
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>>
>>>
On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
> i2c_driver does not need to set an owner because i2c_register_driver()
> will set it.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> The coccinelle script which generated the patch was sent here:
>
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/gpu/drm/bridge/ps8622.c | 1 -
Hi,
The i2c drivers also do not have to set 'owner' field because
i2c_register_driver() will do it instead.
'owner' is removed from i2c drivers, which I was able to compile
with allyesconfig (arm, arm64, i386, x86_64, ppc64).
Only compile-tested.
The coccinelle script which generated the patch
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury
> > wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury
> > wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven
On 2 July 2015 at 01:29, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:56 AM Tomeu Vizoso wrote:
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to prevent deferred probes
//lists.freedesktop.org/archives/dri-devel/attachments/20150710/523b57a9/attachment.sig>
esc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/a2ed76e2/attachment.sig>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/9e1dd7e3/attachment.html>
Hi Emil,
Thank you for your guidance. I'll pay attention about this next time.
BR.
Jianwei
> -Original Message-
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Emil Velikov
> Sent: Friday, July 10, 2015 4:42 PM
> To: Wang
On Wed, 2015-07-08 at 23:44 +0100, Emil Velikov wrote:
...
>
> >
> > I guess it doesn't really matter since patching out the code
> > "fixes"
> > it...
> As you wish. Personally I tend to give it a bit more before giving
> up.
>
I typically would, but it isn't my machine, and my priority is
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/d4d8ca23/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/ebac6921/attachment.html>
.
--
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/20150710/9839e126/attachment.html>
rom /usr/lib/mozilla/plugins/libflashplayer.so
--
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/20150710/d5a347e4/attachment.html>
On Thu, Jul 09, 2015 at 11:44:29PM +0200, Daniel Vetter wrote:
> Just so I have a user for this macro.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>
Hi Daniel,
Thank you very much for your review!
See below...
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Friday, July 10, 2015 4:00 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; linux-kernel
--
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/20150710/69d10cdc/attachment.html>
On Fri, Jul 10, 2015 at 03:26:52PM +0800, Jianwei Wang wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
>
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is
On 07/10/2015 07:56 AM, Gustavo Padovan wrote:
> 2015-07-09 Joonyoung Shim :
>
>> +Cc Andrzej,
>>
>> On 07/07/2015 02:41 AM, Daniel Vetter wrote:
>>> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
struct drm_crtc already stores the enabled
Hi Jianwei,
On 10 July 2015 at 08:47, Wang J.W. wrote:
> Hi Mark,
>
> Thank you very much for your review! I have update my DRM driver.
> All your three comments have been applied in this latest version.
> I replied the last email several times, but all refused the mailist.
I'd suspect that the
2015-07-09 ì¤í 10:08ì Daniel Vetter ì´(ê°) ì´ ê¸:
> Also there's a bit a lack of gpu drivers from the arm world in upstream,
> which is probabyl why this patch series doesn't come with a user. Might be
> better to first upstream the driver before talking about additional
>
Hi Mark,
Thank you very much for your review! I have update my DRM driver.
All your three comments have been applied in this latest version.
I replied the last email several times, but all refused the mailist.
Any other comments for this driver?
BR.
Jianwei
> -Original Message-
> From:
Hi Linus,
back from vacation (another one is coming up in August though), thanks for
taking care of direct pulls while I was out.
a bunch of fixes for radeon, intel, omap and one amdkfd fix.
radeon fixes are all over, but it does fix some cursor corruption across
suspend/resume
i915 should
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/ed1c65b3/attachment-0001.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/1f8cb3d6/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/bafaadce/attachment.html>
Two nice things here:
- drm_dev_register will truly register everything in the right order
if the driver doesn't have a ->load callback. Before this we had to
init the primary mode_group after the device nodes where already
registered.
- Less things to keep track of when reworking the
It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.
Given overwhelming evidence it looks like this isn't a
Remaining manual work in the drm core Nothing special here,
no surprises.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 26 ++
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug.
Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.
v2: Rebase onto the extracted list locking assert and add a comment to
explain the rules.
v3: Fixup
Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Signed-off-by: Daniel Vetter
---
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we
Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
Just so I have a user for this macro.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 053adbb97037..60eebf5f6da8 100644
Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check into a small static inline helper to
help readability. This will be more
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
Hi all,
So this is the second iteration of my connector locking series. This tries to
clarify the cargo-culted locking rules around hotadd/removing drm_connector,
which was added to support DP MST. I want to get this in first for a release or
so just to document all the locking rules we have (and
Similar to radeon, except that amdgpu doesn't even use struct_mutex to
protect anything like the shared z buffer (sane gpu architecture,
yay!). And the code already grabs the globa adev->ring_lock, so this
code can't race with itself. Which makes struct_mutex completely
redundnant. Remove it.
Cc:
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Same changes as for readone really.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Daniel Vetter
---
We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock
and rdev->ring_lock), adding another global mutex won't serialize this
code more. And since there's really nothing interesting that gets
protected in radeon by dev->struct mutex (we only have the global z
buffer owners and it's
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_object.c | 4 +---
1 file changed, 1
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_object.c | 4 +---
1 file changed, 1 insertion(+), 3
This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 --
1 file changed, 2 deletions(-)
diff --git
It doesn't protect anything at all. fbdev helper state is all
protected by modeset locks, and nouveau bo state is taken care of by
ttm. There's also nothing else grabbing struct_mutex that might need
to coordinate with this code. Also this is driver load code, no one
can get at the device yet
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
While at it also fix a leak when this ioctl is
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Aside: I stumbled over the mmap handler which
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Cc: Laurent Pinchart
Cc: Rob Clark
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.
While at it stop grabbing dev->struct_mutex, it doesn't protect
anything here.
Signed-off-by: Daniel Vetter
---
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing
bad happens when the locking is lightly busted.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
Cc: Rob Clark
Cc:
Doesn't really add anything which can't be figured out through
proc files. And more clearly separates the new gem mmap handling
code from the old drm maps mmap handling code, which is surely a
good thing.
Cc: Martin Peres
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 11
Hi all,
I wanted to take another look at struct_mutex usage in modern (gem) drivers and
noticed that for a fair lot we're very to be completely struct_mutex free.
This pile here is the the simple part, which mostly just removes code and
mutex_lock/unlock calls. All the patches here are
On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This really doesn't seem to have much chance of working anymore,
>
> esp for irq context, qxl at least tries to talk to the hw,
> and waits for irqs, and fails.
>
> with runtime pm and other stuff I think we
95 matches
Mail list logo
