On Wed, Jul 05, 2017 at 03:10:11PM -0700, Keith Packard wrote:
> This modifies the datatypes used by the vblank code to provide both 64
> bits of vblank count and to increase the resolution of the vblank
> timestamp from microseconds to nanoseconds.
>
> The driver interfaces have also been changed
On Wed, Jul 05, 2017 at 03:10:12PM -0700, Keith Packard wrote:
> Place drm_event_vblank in a new union that includes that and a bare
> drm_event structure. This will allow new members of that union to be
> added in the future without changing code related to the existing vbl
> event type.
>
> Assi
On 06/07/17 07:10 AM, Keith Packard wrote:
> This modifies the datatypes used by the vblank code to provide both 64
> bits of vblank count and to increase the resolution of the vblank
> timestamp from microseconds to nanoseconds.
>
> The driver interfaces have also been changed to return 64-bits o
On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote:
> These provide crtc-id based functions instead of pipe-number, while
> also offering higher resolution time (ns) and wider frame count (64)
> as required by the Vulkan API.
>
> Signed-off-by: Keith Packard
I very much like this sinc
On 07/05/2017 04:42 PM, Emil Velikov wrote:
On 5 July 2017 at 10:14, Archit Taneja wrote:
On 07/05/2017 02:35 PM, Inki Dae wrote:
2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch removes unnecessary checking of return value.
Ps. this
On 06/07/17 04:45 PM, Michel Dänzer wrote:
> On 06/07/17 07:10 AM, Keith Packard wrote:
>> This modifies the datatypes used by the vblank code to provide both 64
>> bits of vblank count and to increase the resolution of the vblank
>> timestamp from microseconds to nanoseconds.
>>
>> The driver inte
> >> @@ -1369,27 +1362,57 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
> >> struct fb_info *info)
> >>memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(*g));
> >>memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(*b));
> >>
> >> - for (j = 0; j <
On Tue, Jul 04, 2017 at 12:36:59PM +0200, Peter Rosin wrote:
> drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
> now always kept up to date by drm_fb_helper_setcmap.
>
> Signed-off-by: Peter Rosin
Merged up to this patch to drm-misc-next, thanks. Pleas base your next
round o
On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch series changes return type of drm_bridge_add
function to void one and also removes unnecessary checking
of the return type from relevant drivers.
Ps. I had just build test so each maintainer may need to check this.
I pushed all the bridge dr
On 5 July 2017 at 22:31, Li, Samuel wrote:
>> - above all, as-is make check will fail
> Right, I did not check that.
>
>> - keeping the radeon API symmetrical to the amdgpu one would a good idea
> The issue is Radeon does not have a struct similar to amdgpu_device_handle.
Attach it to analogous
From: Colin Ian King
The arrays pctl0_data and pctl1_data do not need to be in global scope,
so them both static.
Cleans up sparse warnings:
symbol 'pctl0_data' was not declared. Should it be static?
symbol 'pctl1_data' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
On Thu, Jul 06, 2017 at 09:53:13AM +0200, Daniel Vetter wrote:
> On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote:
> > These provide crtc-id based functions instead of pipe-number, while
> > also offering higher resolution time (ns) and wider frame count (64)
> > as required by the Vul
From: Russell King
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Acked-by: Hans Verkuil
Signed-off-by: Russell King
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/br
On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä
wrote:
>> > + if (!dev->irq_enabled)
>> > + return -EINVAL;
>> > +
>> > + crtc = drm_crtc_find(dev, get_seq->crtc_id);
>> > + if (!crtc)
>> > + return -ENOENT;
>> > +
>> > + pipe = drm_crtc_index(crtc);
>> > +
>> > + get_
Looks good to me:
Reviewed-by: Tomeu Vizoso
I guess you have tested this with IGT? In any case, I think it would
be good to mention how a patch has been tested in the changelog. That
can be very useful to others if things go wrong at some point.
Thanks,
Tomeu
On 21 June 2017 at 13:00, Maar
On 07/06/2017 12:43 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 06-07-2017 11:33, Neil Armstrong wrote:
>> From: Russell King
>>
>> Add CEC notifier support to the HDMI bridge driver, so that the CEC
>> part of the IP can receive its physical address.
>>
>> Tested-by: Neil Armstrong
>> Acked-by:
On 07/06/2017 01:05 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote:
>> From: Russell King
>>
>> Add CEC notifier support to the HDMI bridge driver, so that the CEC
>> part of the IP can receive its physical address.
>>
>> Tested-by: Neil Armstr
e on it when it appears on drm-misc-next...
>
> Well, from what I can see in 4.12, the cec-notifier stuff is rather
> broken (tda998x has stopped working as its stuck with a physical
> address of f.f.f.f) so I think the whole thing is rather moot right
> now. I don't yet know wh
Hi all,
So the original simple hack failed and we need to do a bit more. This time
tested including depmod for all combos. And since I had the pleasure to read
more fbdev code, 3 simple patches on top to clean up some more.
Cheers, Daniel
Daniel Vetter (4):
fbcon: Make fbcon a built-time depen
There's a bunch of folks who're trying to make printk less
contended and faster, but there's a problem: printk uses the
console_lock, and the console lock has become the BKL for all things
fbdev/fbcon, which in turn pulled in half the drm subsystem under that
lock. That's awkward.
There reasons fo
- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed
the entire panic handling code in our fbdev emulation. We might
restore kms panic output, but not through the bazillion of legacy
code layers called fbdev/fbcon, there's just no way to make that
work safely.
- With the m
It's not accelarated, just system memory. Note we don't even need to
set the default flag since that's now always 0.
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
1 file changed, 1 insertion
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbc
We could probably hit this already with our current async fbdev init,
but it's much easier to hit this with the new deferred fbdev setup
that I'm working on polishing.
Cc: Maarten Lankhorst
Reported-by: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/
With deferred fbdev setup we always need to forward hotplug events,
even if fbdev isn't fully set up yet. Otherwise the deferred setup
will neer happen.
Originally this check was added in
commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag:
drm-intel-next-fixes-2016-08-05)
Author: Chris Wilson
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place becaus
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Dont' resurrect drm_vblank_cleanup.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Thierry Reding (v1)
Signed-off-by: Daniel Vetter
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Thierry Reding
Op 06-07-17 om 13:09 schreef Tomeu Vizoso:
> Looks good to me:
>
> Reviewed-by: Tomeu Vizoso
>
> I guess you have tested this with IGT? In any case, I think it would
> be good to mention how a patch has been tested in the changelog. That
> can be very useful to others if things go wrong at some po
Op 06-07-17 om 15:00 schreef Daniel Vetter:
> With deferred fbdev setup we always need to forward hotplug events,
> even if fbdev isn't fully set up yet. Otherwise the deferred setup
> will neer happen.
>
> Originally this check was added in
>
> commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag:
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Emil Velikov
> Sent: Thursday, July 06, 2017 5:21 AM
> To: Li, Samuel
> Cc: ML dri-devel; amd-gfx mailing list
> Subject: Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name
>
On Thu, Jul 06, 2017 at 01:04:18PM +0200, Daniel Vetter wrote:
> On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä
> wrote:
> >> > + if (!dev->irq_enabled)
> >> > + return -EINVAL;
> >> > +
> >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id);
> >> > + if (!crtc)
> >> > + re
On Thu, Jul 6, 2017 at 5:58 AM, Colin King wrote:
> From: Colin Ian King
>
> The arrays pctl0_data and pctl1_data do not need to be in global scope,
> so them both static.
>
> Cleans up sparse warnings:
> symbol 'pctl0_data' was not declared. Should it be static?
> symbol 'pctl1_data' was not dec
Hi, Dave:
This include new color format support and some fixups.
Please kindly let me know if there is any problem.
Regards,
CK
The following changes since commit
6d61e70ccc21606ffb8a0a03bd3aba24f659502b:
Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)
are available in th
On 07/04/2017 06:30 PM, Philippe CORNU wrote:
> The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using
> a MIPI-DSI video interface. Its backlight is managed through the DSI link.
>
> Signed-off-by: Philippe CORNU
> ---
> .../bindings/display/panel/orisetech,otm8009a.txt
> On Jul 5, 2017, at 18:56, Hyun Kwon wrote:
>
> For VDMA, I think you can use the DMA engine complete callback to generate
> the vblank.
>
> But, please note that it's not a global solution, and it doesn't work for
> some other pipelines. For example, the ZU+ DPDMA operation is synchronized
On 07/05/2017 11:28 AM, Andrzej Hajda wrote:
> On 04.07.2017 18:30, Philippe CORNU wrote:
>> This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD
>> panel driver (MIPI-DSI video mode). The panel backlight is
>> managed through the DSI link. This panel driver is used in
>> several STM32 board
Daniel Vetter writes:
> Extending the reported/sw vblank counter to u64 makes sense imo, but do we
> have to extend the driver interfaces too? If there's no 64 bit hw vblank
> currently I think I'd be good to postpone that part, simply because I'm
> too lazy to audit all the drivers for correctly
Michel Dänzer writes:
> Subtle breakage here: vblwait->request.sequence must still get updated
> for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal.
Thanks for finding this.
I think it might be better to just not modify the request.type field
instead, so that on re-entry it gets re
Michel Dänzer writes:
> BTW, this got me thinking that we should probably treat
> _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating
> vblwait->request.sequence. Otherwise there could theoretically (though
> unlikely) be an infinite loop:
I was thinking that we should just r
https://bugs.freedesktop.org/show_bug.cgi?id=99801
--- Comment #13 from Matthew Treinish ---
I was wondering if there was any update on this? I'm still seeing the same
issue on a 4.11.7 kernel. I'm willing to test out any patches or provide any
additional debug info that is needed.
--
You are r
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Alexander Tsoy (alexan...@tsoy.me) changed:
What|Removed |Added
CC||alexan...@tsoy.me
--
Daniel Vetter writes:
> A few nits below, but looks good otherwise.
Thanks.
>> static struct drm_pending_vblank_event *create_vblank_event(
>> -struct drm_device *dev, uint64_t user_data)
>> +struct drm_device *dev, struct drm_crtc *crtc, uint64_t
>> user_data)
>
> Nit
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #71 from Alexander Tsoy (alexan...@tsoy.me) ---
(In reply to Alexander Tsoy from comment #70)
> For me P4_8x16 config fixed this issue.
>
> $ sudo dmesg | egrep 'RAM width|OLAND'
> [1.670667] [drm] initializing kernel modesetting
Daniel Vetter writes:
> I very much like this since the old ioctl really is a rather bad horror
> show. And since it's tied in with ums drivers everything is
> complicated.
Thanks for your kind words.
> I started a discussion a while back whether these should be restricted to
> DRM_MASTER (i.e.
Ville Syrjälä writes:
> Maybe, or maybe we want to turn the interrupt on in that case? That's
> what the old ioctl does.
That's what I suggested in my reply to Daniel's review. Even if we add
the accurate function, we'll still need the interrupt-enable case as a
fallback for drivers which don't
https://bugs.freedesktop.org/show_bug.cgi?id=99292
--- Comment #5 from Christoph Haag ---
I don't know if it's still the same problem but now it always happens *very*
quickly after starting the app. Here's a fresh api trace:
https://haagch.frickel.club/files/interface-2.trace.xz
--
You are rece
On Thu, Jul 06, 2017 at 09:28:40AM -0700, Keith Packard wrote:
> Ville Syrjälä writes:
>
> > Maybe, or maybe we want to turn the interrupt on in that case? That's
> > what the old ioctl does.
>
> That's what I suggested in my reply to Daniel's review. Even if we add
> the accurate function, we'l
Ville Syrjälä writes:
> I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern
> where we can avoid doing the full update more than once if we enable
> the interrupt already during the query.
Don't we still wait 5 seconds before disabling vblank? In that case, the
chances of hittin
https://bugs.freedesktop.org/show_bug.cgi?id=99859
--- Comment #22 from intermedi...@hotmail.com ---
last mesa xorg log
just to report.
different error. with last mesa dev
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel
(git-f78aa2c986)
[ 5057.542] (II) glamor: OpenG
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #8 from Olaf H B (o...@seldiame.net) ---
(In reply to Michel Dänzer from comment #6)
> Is this a regression from older kernel versions? If yes, can you bisect?
I don't think this is a regression because I had similar issues with kerne
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #9 from Olaf H B (o...@seldiame.net) ---
Created attachment 257391
--> https://bugzilla.kernel.org/attachment.cgi?id=257391&action=edit
kern.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote:
> Ville Syrjälä writes:
>
> > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern
> > where we can avoid doing the full update more than once if we enable
> > the interrupt already during the query.
>
> Don't we stil
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you get a log with symbols?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing lis
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.
Normally this is taken care of by the i915_pmic_bus_access_notifier()
which doe
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_bus
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."
Reported-by: Ville Syrjälä
Suggested-by: Imre Deak
Signed-off-by: Hans de Goede
--
Ville Syrjälä writes:
> With the disable_immediate thing we only wait until the next vblank
> before disabling the irq again.
Ok, still sounds like we'll be doing fine if the application does a
get immediately followed by a queue event. At least most of the time.
--
-keith
signature.asc
Desc
From: Ville Syrjälä
In an effort to eliminate the obj->state usage let's pass on the
new crtc state pointer (which we already have!) to the color management
code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/intel_drv.h | 8
drivers/gpu/drm/i915/intel_pm.c | 30 +++---
3 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/drivers/gp
From: Ville Syrjälä
Pass the appropriate new crtc state explicitly to
intel_pipe_update_start/end() instead of of mucking around with
crtc->state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +++---
drivers/gpu/drm/i915/intel_drv.h | 13 ++
From: Ville Syrjälä
Dig up the appropriate new crtc and plane states from the top level
atomic state in intel_pre_plane_update() and intel_post_plane_update().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
From: Ville Syrjälä
OK, so here's the full version of my rw_semaphore GPU vs. display reset
fix.
The only issue I'm aware of is that SKL watermark code still uses
obj->state and thus I have no clue what would happen if one tries to
run this on SKL. Untangling that would likely mean making the SK
From: Ville Syrjälä
Eliminate plane->state and crtc->state usage from
intel_plane_atomic_check_with_state() and its callers. Instead pass the
proper states in or dig them up from the top level atomic state.
Note that intel_plane_atomic_check_with_state() itself isn't allowed to
use the top level
From: Ville Syrjälä
We already have the correct new crtc state so just use that instead of
crtc->state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driver
From: Ville Syrjälä
Pass the correct new crtc state to intel_update_pipe_config() instead
of using crtc->state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
From: Ville Syrjälä
Add a small helper that gives us dynamically growing arrays. We have a
couple hand rolled implementations of this in the atomic code, which we
can unify to use a common implementation.
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/drm-utils.rst | 15 +++
Documentat
From: Ville Syrjälä
We will never add private objects with a NULL state into the atomic
state, hence checking for that is pointless.
Cc: Dhinakaran Pandiyan
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 3 +--
1 file changed, 1 insertion(+), 2 del
From: Ville Syrjälä
We'll be wanting to duplicate other states besides the one pointed to
by crtc->state & co., so pass the duplicated state in explicitly.
@r@
identifier F =~ "^__drm_atomic_helper_.*_duplicate_state$";
identifier O, S;
type T, TS;
@@
F(T O, TS *S
+ ,const TS *old_state
)
{
<.
From: Ville Syrjälä
state->connectors[] can grows dynamically, so we can switch over to
using the new drm_dynarray.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 49 +++--
drivers/gpu/drm/drm_atomic_helper.c | 4 +--
include/drm/drm_ato
From: Ville Syrjälä
Rename the local 'old_state' variable to 'old_mtk_state' to get it
out of the way of some cocci refactoring.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/med
Am 06.07.2017 um 22:16 schrieb Felix Kuehling:
This allows drivers to check if a DMA-buf contains a GEM object and
whether it comes from the same driver. It may be from the same or a
different device.
Signed-off-by: Felix Kuehling
I think Daniel/Dave hadmore a function which returns the caste
From: Ville Syrjälä
state->private_objs grows dynamically, so switch it over to use
the new drm_dynarray helper.
Cc: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 64 -
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
From: Ville Syrjälä
Coccinelle doesn't fix up the docs for us, so let's do it manually.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 12 +---
include/drm/drm_connector.h | 2 +-
include/drm/drm_crtc.h | 2 +-
include/drm/drm_plane.h
From: Ville Syrjälä
We'll be wanting to duplicate other states besides the one pointed to
by crtc->state & co., so pass the duplicated state in explicitly.
I wanted to make the old_state const, but that would have results in
tons of new warnings because some drivers have their to_foo_state()s
as
From: Ville Syrjälä
Make the atomic private object stuff less special by introducing proper
base classes for the object and its state. Drivers can embed these in
their own appropriate objects, after which these things will work
exactly like the plane/crtc/connector states during atomic operations
From: Ville Syrjälä
Split intel_atomic_commit_tail() into a lower level function that does
the actual commit, and a higher level one that waits for the
dependencies and signals the commit as done. We'll reuse the lower
level function to perform commits during GPU resets.
Signed-off-by: Ville Syr
From: Ville Syrjälä
To avoid having to deference plane_state->vma during the commit phase of
plane updates, let's store the vma gtt offset (or the bus address when
we need it) in the plane state. This is crucial for doing the modeset
operations during GPU reset as as plane_state->vma gets cleared
From: Ville Syrjälä
For i915 GPU reset handling we'll want to be able to duplicate the state
that was last commited to the hardware. For that purpose let's start to
track the commited state for each object and provide a way to duplicate
the commmited state into a new drm_atomic_state. The locking
From: Ville Syrjälä
Make drm_connector_get() return the connector. This allows the nice
pattern of 'foo->connector = drm_connector_get(connector)'
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 3 +--
drivers/gpu/drm/drm_fb_helper.c | 7 +++
include/drm/drm_connector.h
From: Ville Syrjälä
Rename the local 'old_state' variable to 'old_mali_state' to get it
out of the way of some cocci refactoring.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arm/malidp_crtc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ar
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 commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
This allows drivers to check if a DMA-buf contains a GEM object and
whether it comes from the same driver. It may be from the same or a
different device.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 24
include/drm/drmP.h | 2 ++
2 files chan
On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> I very much like this since the old ioctl really is a rather bad horror
>> show. And since it's tied in with ums drivers everything is
>> complicated.
>
> Thanks for your kind words.
>
>> I started a discussion a wh
Chrstian,
you are probably the best person to ack this, I'd like to get the radv
code landed
and allow the GL code to get going.
Dave.
> This adds kernel semaphore support to the command submission
> interface in what should be a backwards compatible manner,
> it adds a new command submission AP
https://bugs.freedesktop.org/show_bug.cgi?id=101712
guiscara...@gmail.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
The redundant fb helpers .gamma_set and .gamma_get are no longer
used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/gma500/framebuffer.c | 22 --
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 -
On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote:
> From: Russell King
>
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
>
> Tested-by: Neil Armstrong
> Acked-by: Neil Armstrong
> Acked-by: Hans Verkuil
> S
On 2017-07-06 07:55, Daniel Vetter wrote:
> On Wed, Jul 5, 2017 at 7:50 PM, Peter Rosin wrote:
+retry:
+ret = drm_modeset_lock_all_ctx(dev, &ctx);
>>>
>>> With atomic you don't need to grab locks, this is done behind the scenes
>>> (as long as you handle the retry/backoff correctly).
Do not waste cycles looking up the property id when we have the
actual property already.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_atomic_helper.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/
On Thu, Jul 06, 2017 at 02:38:41PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 06, 2017 at 12:56:43PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote:
> > > Well, from what I can see in 4.12, the cec-notifier stuff is rath
Hi Neil,
On 06-07-2017 11:33, Neil Armstrong wrote:
> From: Russell King
>
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
>
> Tested-by: Neil Armstrong
> Acked-by: Neil Armstrong
> Acked-by: Hans Verkuil
> Signed-off-by
On Thu, Jul 06, 2017 at 01:55:58PM +0200, Neil Armstrong wrote:
> On 07/06/2017 01:45 PM, Russell King - ARM Linux wrote:
> > Well, from what I can see in 4.12, the cec-notifier stuff is rather
> > broken (tda998x has stopped working as its stuck with a physical
> > address of f.f.f.f) so I think t
The legacy path implements setcmap in terms of crtc .gamma_set.
The atomic path implements setcmap by directly updating the crtc gamma_lut
property.
This has a couple of benefits:
- it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
completely obsolete. They are now unused a
-love.SAKURA.ne.jp/tmp/serial-20170706.txt.xz :
[ 779.494100] Mem-Info:
[ 779.495493] active_anon:846948 inactive_anon:5416 isolated_anon:0
[ 779.495493] active_file:33 inactive_file:13 isolated_file:47
[ 779.495493] unevictable:0 dirty:11
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.
1 - 100 of 136 matches
Mail list logo
