Kick out firmware DRM and fbdev drivers via the new
drm_kick_out_firmware() before loading radeon.
Cc: Alex Deucher
Signed-off-by: David Herrmann
---
drivers/gpu/drm/radeon/radeon_drv.c | 28
drivers/gpu/drm/radeon/radeon_kms.c | 30
Hi
On Mon, Sep 2, 2013 at 9:43 AM, Daniel Vetter wrote:
> On Sun, Sep 01, 2013 at 03:36:51PM +0200, David Herrmann wrote:
>> Use the new DRM infrastructure to kick out firmware DRM drivers before
>> loading i915.
>>
>> Cc: Daniel Vetter
>> Signed-off-by: David
Hi
On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
> Hi
>
> With the upcoming 3.12 merge-window, I thought people might find themselves
> with
> nothing to do, so here's a new SimpleDRM series. Comments welcome!
>
> This depends on the tip/x86/fb series in
VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
Yepp, looks good. Maybe we should just drop it entirely. It's 200
lines of code and no additional dependencies. Anyway, nice catch:
Reviewed-by: David Herrmann
Thanks
D
Hi
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote:
> Hi guys,
>
> With current git (v3.11-5058-g57d7309) I get the following oops:
>
> [5.434312] [ cut here ]
> [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171
> __ioremap_caller+0x2e3/0x390()
>
Hi
On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote:
> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote:
>> On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote:
>>> Hi guys,
>>>
>>> With current git (v3.11-5058-g57d7309) I get the following oops:
>
Hi Tom
On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann wrote:
> Hi
>
> On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote:
>> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote:
>>>
>>> It seems to be unrelated to the x86-sysfb changes. The WARN_ON
>&g
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
> Hi David,
>
> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
>> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote:
>>> Attached are two patches. The first one should fix this issue, the
>>> sec
Hi
On Sun, Sep 8, 2013 at 1:33 PM, Tom Gundersen wrote:
> Hi David,
>
> On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote:
>> Hi
>>
>> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
>>> Hi
>>>
>>> With the upcoming 3.12 merge-wi
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> It's a tiny bit more logical to find the different capabilities you can
> use with the GET_CAP ioctl next to the structure rather than putting
> them at the end of the file.
>
> Signed-off-by: Damien Lespiau
> ---
> include/uapi/drm/drm
oes as following:
>>> 1/ the DRM client (limited to the DRM master) can notify it knows about
>>> those
>>> flags through SET_CAP
>>
>> Is this capability dropped along with a change in master then?
>
> Yeah, I think it would make sense to store this fl
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> This capability allows user space to control the delivery of modes with
> the 3D flags set. This is to not play games with current user space
> users not knowing anything about stereo 3D flags and that could try
> to set a mode with one o
y prefer "buf = NULL;" and an extended bail-out condition:
if (unlikely(ret != 0 || !buf))
but it's not my decision, so:
Reviewed-by: David Herrmann
Cheers
David
> ---
> drivers/gpu/drm/ttm/ttm_object.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Signed-off-by: David Herrmann
Acked-by: Maarten Lankhorst
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4
ie
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Jerome Glisse
Cc: Rob Clark
Cc: Inki Dae
Cc: Ben Skeggs
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c
was modified to use these. Reason for that is
that I have pending patches to make device hotplugging safer regarding mmaps.
But these aren't ready, yet. Hopefully I can get them ready for rc5 or rc6.
Tested on nouveau.
David
David Herrmann (5):
drm: add drm_dev_alloc() helper
drm: mer
phase, and a registration phase.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 4 +-
drivers/gpu/drm/drm_platform.c | 3 +-
drivers/gpu/drm/drm_stub.c | 121 +
drivers/gpu/drm/drm_usb.c | 7 +--
include/drm/drmP.h
called this in any other error
path either. Instead, we use the recently introduced AGP cleanup helpers.
We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep
semantics.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 56 +++
drivers/gpu
)
- drm_drv.c: Global DRM init + ioctl handling
Well, ioctl handling is still spread throughout hundreds of source files,
but at least the others are clearly defined this way.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 70 --
drivers
_ht_remove(), drm_ctxbitmap_cleanup() and
drm_gem_destroy() are all fine in that regard.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 2 +-
drivers/gpu/drm/drm_platform.c | 2 +-
drivers/gpu/drm/drm_stub.c | 35 +--
drivers/gpu/drm/drm_usb.c
wever, drm_dev_put() definitely does not do any kind of ref-counting.
Hence, use the more appropriate *_register(), *_unregister(), *_alloc()
and *_free() names.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 61 +++---
include/drm/d
. Hence, we need a guarantee that
dummy_con is available.
To avoid recursive Kconfig dependencies, we move the vga-con/sgi-con
conflict directly into VGA_CONSOLE and make DUMMY_CONSOLE always active.
Signed-off-by: David Herrmann
---
drivers/video/console/Kconfig | 2 +-
drivers/video/console
Hi
On Wed, Oct 2, 2013 at 11:25 AM, David Herrmann wrote:
> If vgacon got unloaded for any reason, we can never be sure that vga
> registers are still accessible. fbdev/DRM/xycon might reconfigure graphics
> devices in a way that prevents vgacon from working again. Therefore,
> inhib
't
look very nice to ignore it silently.
Tested with nouveau on x86_64.
Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c| 2 +-
drivers/gpu/drm/drm_drv.c | 1 -
driver
mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.
Signed-off-by: David Herrmann
Wanted-by: Daniel Vetter
---
Hi Linus & Al
Any chance I could get an ACK on this? It's fairly trivial and allows us to
simplify the DRM logic quite a bit (see patch 2/2
hould also kill drm_get_connector_name()
in a follow-up. I don't see why that wrapper is needed.
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/drm_crtc.c | 36
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 22 inserti
ase.id remain unchanged for the lifetime of the
> connector/encoder - is that a correct assumption?
I like the approach. Using dev-name does not work for encoders, so I'd
keep them separate. I mean, we're talking about ~32 bytes per
connector here..
Acked-by: David Herrmann
Thanks
David
be nice.
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +--
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't the kernel-command-line enough? Why is
this a regular feature instead of a debugfs attribute?
> ---
> drivers/g
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> On 19 May 2014 15:13, David Herrmann wrote:
>> Hi
>>
>> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood
>> wrote:
>>> Signed-off-by: Thomas Wood
>>
>> The commit-msg lacks any discussion w
Hi
On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood
>> wrote:
>> > It was intended as a debug/testing feature to allow tests in
>> > int
excludes its zone
If a driver requires pages to be in a specific zone, they _must_ set the
correct GFP flags (like __GFP_DMA32) in mapping_gfp_mask(mapping). shmem
will make sure that any page leaving the swap-cache is located in a
compatible zone.
Signed-off-by: David Herrmann
---
drivers/gpu
nd directly use drm_dev_alloc() and
> drm_dev_register().
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
Reviewed-by: David Herrmann
Thanks
David
> ---
> Changes in v3:
> - address comments by David Herrmann:
> - return -EINVAL when dev->unique not set in drm
it the mercy
> blow.
>
> Signed-off-by: Alexandre Courbot
> Reviewed-by: Thierry Reding
Reviewed-by: David Herrmann
Thanks
David
> ---
> include/drm/ttm/ttm_bo_driver.h | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_dri
Hi
On Fri, May 23, 2014 at 5:58 AM, Alexandre Courbot
wrote:
> The kerneldoc header of ttm_bo_create() was referring to another
> (nonexisting) function and had a few obsolete or incorrect arguments.
>
> Signed-off-by: Alexandre Courbot
Reviewed-by: David Herrmann
ussell King
> Cc: David Airlie
> Cc: Maarten Lankhorst
> Cc: Sumit Semwal
Reviewed-by: David Herrmann
Thanks
David
> ---
>
> Hi,
>
> This can be seen with e.g. linux next-20140523 and arm allmodconfig.
>
> Best regards,
>
> V.
>
> drivers/gpu/drm/armada
wrongly placed DMA32 pages is no longer valid.
Replace it with a proper comment but keep the BUG_ON() to verify correct
shmem behavior.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp
mask. No reason to use shmem_read_mapping_page_gfp() directly if we want
the default behavior.
Cc: Russell King
Signed-off-by: David Herrmann
---
drivers/gpu/drm/armada/armada_gem.c | 4 +---
1 file changed, 1 insertion
Instead of shuffling gfp-masks all the time, use the
shmem_read_mapping_page() helper. Note that __GFP_IO and __GFP_WAIT are
set in mapping_gfp_mask() for i915, so the behavior is still the same.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915
: Rob Clark
Signed-off-by: David Herrmann
---
drivers/gpu/drm/omapdrm/omap_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 95dbce2..1331fd5 100644
--- a/drivers/gpu/drm/omapdrm
llowing
must be true for 'gfp' passed to shmem_read_mapping_pages_gfp():
gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp)
Add a comment to drm_gem_read_pages() explaining that constraint.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 29 -
drivers/g
Hi
On Wed, May 21, 2014 at 3:17 PM, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 02:16:26PM +0200, David Herrmann wrote:
>> The shmem subsystem supports relocating pages on swap-in in case it was
>> loaded into the wrong zone. This was implemented 2 years ago in:
&
patch need to wait for radeon
> and nouveau patches to get merged, obviously.
I tried reviewing these, but it doesn't apply on drm-intel-next.
Trusting in coccinelle, this is:
Acked-by: David Herrmann
Thanks
David
struct drm_file *file_priv);
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f104c26..5b530c7 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -251,6 +251,20 @@ struct drm_mode_get_connector {
> #define DRM_
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
> };
>
> +static inline int64_t U642I64(uint64_t val)
> +{
> + return (int64_t)*((int64_t *)&val);
The cast to "(int64_t)" is unneeded. Dereferencing (int64_t*) will
always yield (int64_t).
Same below.
Btw., why are t
ramebuffer_unreference(struct drm_framebuffer *fb)
> {
> - DRM_DEBUG("FB ID: %d\n", fb->base.id);
> + DRM_DEBUG("%p: FB ID: %d (%d)\n", fb, fb->base.id,
> fb->refcount.refcount.counter);
atomic_read()!!!
With that fixed, this is:
Reviewed-by:
Hi
On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
wrote:
> On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
>> > From: Thierry Reding
>> >
>> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
>
Hey
On Wed, Aug 10, 2016 at 4:34 PM, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 4:27 PM, Noralf Trønnes
> wrote:
>> Den 10.08.2016 10:43, skrev Daniel Vetter:
>>>
>>> On Tue, Aug 09, 2016 at 07:45:40PM +0200, Noralf Trønnes wrote:
This adds a way for in-kernel users to iterate o
minimum, avoids
any dependency on priv->uid or priv->pid (allows us to get rid of them),
and makes libva happy by always *exactly* returning the information it
wants.
Signed-off-by: David Herrmann
---
v2: Just re-order the series and send individual patches, since they do
not depend on eac
the global ioctl handlers. Furthermore, versioning
interfaces breaks backports and as such is deprecated, anyway. We just
keep them for historic reasons. I doubt anyone will ever modify them
again.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 8 +++-
dri
andlers in the exact reverse order of initialization
(except if the order actually matters for syncing-reasons, which is
not the case here, though).
v2:
- Call drm_core_exit() directly from the init-error-handler. Requires to
drop __exit annotation, though.
Signed-off-by: David Herrmann
---
H
bus, before calling into drm_dev_register().
Signed-off-by: David Herrmann
---
Hey
This is just compile-tested for now. I just want to get some comments on the
design. I decided to drop the sysfb infrastructure and rather just use this
generic helper. It keeps things simple and should work just fine
Hi
On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede wrote:
> Hi,
>
> On 26-08-16 02:00, David Herrmann wrote:
>>
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evic
Hi Rob
On Fri, Aug 26, 2016 at 2:36 PM, Rob Herring wrote:
> On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann
> wrote:
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evict
Hi
On Tue, Aug 30, 2016 at 10:58 PM, Rob Herring wrote:
> On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann
> wrote:
>> Sure, all those functions are not meant to be called in parallel by
>> multiple tasks. They are rather meant to have a single holder which
>&g
Hey Rob!
On Wed, Aug 31, 2016 at 1:01 AM, Rob Herring wrote:
> On Tue, Aug 30, 2016 at 4:12 PM, David Herrmann
> wrote:
>> Currently I see at least 3 paths that might add such nodes:
>>
>> - of_platform_populate()
>
> If we assume the node is only under cho
well, we need to keep it working, and the simplest way is to add a
> symlink at the right place in debugfs from controlD* to card*.
>
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Cc: Dave Airlie
> Reported-by: Alex Deucher
> Cc:
>
> In debugfs? This patch seems to be for sysfs.
Yes, typo. It is meant to be sysfs.
>> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
>> Cc: Dave Airlie
>> Reported-by: Alex Deucher
>> Cc: Alex Deucher
>> Cc: David Herrmann
>> Cc: Greg Kro
Hey
On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter wrote:
>> > So it is possible, only reason vram dumb buffers look worse is that there's
>> > only 3 and no one cares about them, vs about 20 and a very active community
>> > of contributors (also for core drm improvements) for the other case.
>>
>
what's been there (David)
> - Add a comment what exactly userspace minimally needs.
> - Correct the analysis for -intel (Chris).
>
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Cc: Dave Airlie
> Reported-by: Alex Deucher
> Cc: Alex Deucher
> Cc: Davi
Hey Chris
On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
wrote:
> For testing, we want a reproducible PRNG, a plain linear congruent
> generator is suitable for our very limited selftests.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/Kconfig| 5 +
> drivers/gpu/drm/Make
On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann
wrote:
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
> wrote:
> for (i = 0; i < count; ++i)
> swap(order[i], order[drm_lcg_random(state) % count]);
>
> Much simpler and I cannot see why it wouldn't work.
Hey Chris
On Tue, Dec 13, 2016 at 4:40 PM, Chris Wilson
wrote:
> On Tue, Dec 13, 2016 at 04:18:35PM +0100, David Herrmann wrote:
>> On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann
>> wrote:
>> > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson > > chris-wilson.co
Hi
On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter wrote:
> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>> did not re-use the fuse/cuse framework to do the serialization of the
>> ioctls.
>>
>> Not sure
Hi
On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres wrote:
> On 08/12/15 13:59, David Herrmann wrote:
>> I looked into all this when working on WFD, but I cannot recommend
>> going down that road. First of all, you still need heavy modifications
>> for gnome-shell, kwin, and f
TASK_INTERRUPTIBLE :
> TASK_UNINTERRUPTIBLE);
> - if (signal_pending(current)) {
> - rc = -EINTR;
> + if (interruptible && signal_pending(current)) {
> +
tier output.
>
> Cc: Tomeu Vizoso
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-uapi.rst | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/Documentati
/drm-mm.rst | 2 +-
> drivers/gpu/drm/drm_mm.c | 41 +++--
> include/drm/drm_mm.h | 84
> ++--
> 3 files changed, 89 insertions(+), 38 deletions(-)
I liked the "DRM Roaster" more than the "Roster"!
Reviewed-by: Da
rivers/dma-buf/dma-buf.c | 6 +++---
> include/linux/dma-buf.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 91aff74ed092..ab814aff0a5b 100644
> --- a/
Hi
On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter
wrote:
> We forgot to clean this up when adding connector refcounting.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 -
> 1 file changed, 5 deletions(-)
Patch 1-10 all:
Reviewed-
Hi
On Tue, Dec 22, 2015 at 10:36 PM, Tiago Vignatti
wrote:
> From: Daniel Vetter
>
> The userspace might need some sort of cache coherency management e.g. when CPU
> and GPU domains are being accessed through dma-buf at the same time. To
> circumvent this problem there are begin/end coherency ma
Hi
On Fri, Feb 5, 2016 at 10:57 PM, Haixia Shi wrote:
> This flag is only used for drm/udl.
Furthermore, it is horribly racy. Lets not make use of it outside of udl.
Reviewed-by: David Herrmann
Thanks
David
> Signed-off-by: Haixia Shi
> Reviewed-by: Stéphane Marchesin
> --
Hi
On Fri, Feb 5, 2016 at 10:57 PM, Haixia Shi wrote:
> Remove the general drm_device_is_unplugged() checks, and move the unplugged
> flag handling logic into drm/udl. In general we want to keep driver-specific
> logic out of common drm code.
I like the idea of moving this hack into udl. However
Hi
On Tue, Feb 9, 2016 at 9:45 PM, Haixia Shi wrote:
> Regarding the following comment:
>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 1ea8790..b4332d4 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -497,8 +497,6 @@ int drm
Hi
On Tue, Feb 9, 2016 at 10:05 PM, Haixia Shi wrote:
> Remove the general drm_device_is_unplugged() checks, and move the unplugged
> flag handling logic into drm/udl. In general we want to keep driver-specific
> logic out of common drm code.
>
> Signed-off-by: Haixia Shi
> Reviewed-by: Stéphan
Hi
On Wed, Feb 10, 2016 at 10:00 PM, Haixia Shi wrote:
> Also note that it is not currently feasible for UDL code to access
> drm_global_mutex.
Then change this.
> Please also refer to the similar comments ("FIXME: open_count is protected
> by drm_global_mutex but that would lead to locking inv
Hi
On Wed, Feb 10, 2016 at 9:51 PM, Haixia Shi wrote:
>> This should rather be:
>>
>> drm_release(inode, filp);
>> mutex_lock(&drm_global_mutex);
>> if (!dev->open_count && udl_device_is_unplugged(dev))
>> drm_put_dev(dev);
>> mutex_unlock(&drm_glob
Hi
On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote:
>
>> + if (udl_device_is_unplugged(dev) &&
>> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) &&
>> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) &&
>> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_DESTROY_DUMB))
Hi
On Wed, Feb 10, 2016 at 10:38 PM, Haixia Shi wrote:
> David
>
> I am having trouble getting the reference to "drm_global_mutex" to link
> correctly in drm/udl. The error is
>
> ERROR: "drm_global_mutex" [drivers/gpu/drm/udl/udl.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [mod
Hi
On Wed, Feb 10, 2016 at 10:46 PM, Stéphane Marchesin
wrote:
> On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann
> wrote:
>> Hi
>>
>> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote:
>>>
>>>> + if (udl_device_is_unplugged(de
Hi
On Wed, Feb 10, 2016 at 11:02 PM, Stéphane Marchesin
wrote:
> On Wed, Feb 10, 2016 at 1:54 PM, David Herrmann
> wrote:
>>>> If a device is unplugged, you should consider all your resources to be
>>>> destroyed. There is no reason to release them manually. Use
Hi
On Thu, Feb 11, 2016 at 12:18 AM, Haixia Shi wrote:
> When USB cable is disconnected, we mark udl device as unplugged so that
> udl_detect reports connector status as disconnected, but still keep
> the drm device alive until user-space closes it.
>
> Signed-off-by: Haixia Shi
> Reviewed-by: S
Hi
On Thu, Feb 11, 2016 at 6:54 PM, Tiago Vignatti
wrote:
> On 02/09/2016 07:26 AM, David Herrmann wrote:
>>> +
>>> + switch (cmd) {
>>> + case DMA_BUF_IOCTL_SYNC:
>>> + if (copy_from_user(&sync, (void __user *) arg,
>>&g
Hi
On Thu, Feb 11, 2016 at 7:08 PM, Ville Syrjälä
wrote:
> On Thu, Feb 11, 2016 at 03:54:38PM -0200, Tiago Vignatti wrote:
>>
>> Thanks for reviewing, David. Please take a look in my comments in-line.
>>
>>
>> On 02/09/2016 07:26 AM, David Herrmann wrote:
>
t; doc about sync usage.
> v9 (Tiago): remove useless is_dma_buf_file check. Fix sync.flags conditionals
> and its mask order check. Add include in dma-buf.h.
>
> Cc: Ville Syrjälä
> Cc: David Herrmann
> Cc: Sumit Semwal
> Reviewed-by: Stéphane Marchesin
> Signed-off-b
Hi
On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
wrote:
> Showing who is the current master is useful for trying to decypher
> errors when trying to acquire master (e.g. a race with X taking over
> from plymouth). By including the process name as well as the pid
> simplifies the task of grabbing
Hi
On Mon, Sep 1, 2014 at 3:29 PM, sean darcy wrote:
> On 08/22/2014 10:52 AM, Alex Deucher wrote:
>>
>> Hi Dave,
>>
>> This pull just contains some new pci ids.
>>
>> The following changes since commit
>> 20a984c2a51d379bce08ee1031b32020f273e532:
>>
>>Merge tag 'drm-intel-fixes-2014-08-21' o
Hi
On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson
wrote:
> On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
>> Hi
>>
>> On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
>> wrote:
>> > Showing who is the current master is useful for trying to
(struct drm_device *dev,
> + struct drm_buf * buf);
> +extern void drm_legacy_core_reclaim_buffers(struct drm_device *dev,
> + struct drm_file *filp);
> +
"_core_" in the name doesn't really make much
Hi
On Wed, Sep 10, 2014 at 12:43 PM, Daniel Vetter
wrote:
> Also sprinkle the drm_legacy_ prefix where missing.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> drivers/gpu/drm/drm_legacy.h | 7 +++
> drivers/gpu/drm/drm_scatter.c | 8
> include/
Hi
On Wed, Sep 10, 2014 at 10:10 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves the drm_dma and drm_bufs stuff out of drmP.h as
> much as possible and hides it in drm_legacy.h.
>
> It built.
I guess this is now obsolete with Daniel's series? I prefer his way
(using a global drm_legac
eed any special driver code to make it work.
Patch #1 and #2 are cleanups and can be applied right away. #3 adds in-kernel
backlight APIs and #4 implements the connector-backlight link.
Comments welcome!
David
David Herrmann (4):
backlight: use static initializers
backlight: use spin-lock to p
Use static initializers instead of setting up global variables during
runtime. This reduces code size and execution time.
Signed-off-by: David Herrmann
---
drivers/video/backlight/backlight.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight
.
Signed-off-by: David Herrmann
---
drivers/video/backlight/backlight.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 726c6c6..33b64be 100644
--- a/drivers/video/backlight/backlight.c
. This allows us to employ the same access-management
we use for mode-setting.
This patch adds few kernel-internal backlight helpers so we can modify
backlights from within DRM.
Signed-off-by: David Herrmann
---
drivers/video/backlight/backlight.c | 65
case the real backlight device is probed after the DRM
card, the backlight will still get properly attached once probed.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_backlight.c | 387 +++
Hi
On Tue, Sep 9, 2014 at 10:16 AM, Ville Syrj?l?
wrote:
> On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> From my POV I don't think the modesetting interface needs to take
>> crtcs, just connectors and modes,
>> so I'm wondering going forward for atomic should we even accept crtc
Hi
On Thu, Sep 11, 2014 at 1:10 PM, Thierry Reding
wrote:
> On Wed, Sep 10, 2014 at 05:54:22PM +0200, David Herrmann wrote:
> [...]
>> +void backlight_set_brightness(struct backlight_device *bd, unsigned int
>> value,
>> + enum backli
Hi
On Thu, Sep 11, 2014 at 8:48 AM, Daniel Vetter wrote:
> Nice you skid around all the pitfalls and trapdoors, I guess we've all
> been rather blind ;-)
>
> Two high-level comments:
> - We also want to forward "bl_power". cros was totally not happy when we
> stopped treating brightness == 0 as
Hi
On Wed, Sep 10, 2014 at 10:40 PM, Matthew Garrett
wrote:
> On Wed, 2014-09-10 at 17:54 +0200, David Herrmann wrote:
>
>> * User-space currently has a hard-time figuring out which backlight device
>> to
>>use, and which backlight device belongs to whi
201 - 300 of 1115 matches
Mail list logo
