This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from
When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
Cc: Ville Syrjala
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
A source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
This patch adds a function to add the output colorspace
information in the AVI infoframes.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Rebase
V6: Made patch independent of HDMI
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65
Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
which is currently supported on HDMI 2.0 sources/sinks. Due to lower
chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half
the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA
4K@60, RGB
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the
The late 2009, 27 inch Apple iMac10,1 has an
internal eDP display and an external Mini-
Displayport output, driven by a DCE-3.2, RV730
Radeon Mobility HD-4670.
The machine worked fine in a dual-display setup
with eDP panel + externally connected HDMI
or DVI-D digital display sink, connected via
On 07/07/17 10:34 AM, Michel Dänzer wrote:
> On 07/07/17 12:04 AM, Keith Packard wrote:
>> Michel Dänzer writes:
>>
@@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev)
if (!dev_priv)
return -EINVAL;
+ if
On 07/07/17 12:04 AM, Keith Packard wrote:
> Michel Dänzer writes:
>
>>> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev)
>>> if (!dev_priv)
>>> return -EINVAL;
>>>
>>> + if (dev->driver->get_vblank_counter)
>>> +
https://bugs.freedesktop.org/show_bug.cgi?id=101712
Michel Dänzer changed:
What|Removed |Added
Component|Drivers/Gallium/radeonsi
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 69133a7dd030d061a2c7a0334441cfe657e4b53f
commit: 22cdbf5cc45dba5c8f7be3277cafeee6bcf67978 [552/612] drm/amd/display:
Universal cursor plane hook-up.
coccinelle warnings: (new ones prefixed by >>)
>>
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1802:2-7:
WARNING: NULL check before freeing functions like kfree, debugfs_remove,
debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider
reorganizing relevant code to avoid passing NULL values.
On 2017年07月07日 05:58, Gustavo A. R. Silva wrote:
The right variable to check here is port, not dp.
This issue was detected using Coccinelle and the following semantic patch:
@@
expression x;
identifier fld;
@@
* x = devm_kzalloc(...);
... when != x == NULL
x->fld
Signed-off-by: Gustavo
The redundant fb helper .load_lut is no longer used, and can not
work right without also providing the fb helpers .gamma_set and
.gamma_get thus rendering the code in this driver suspect.
Just remove the dead code.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/stm/ltdc.c | 12
Rob,
2017-06-30 17:46 GMT-03:00 Marco Franchi :
> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel.
>
> Datasheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Seiko 43WVF1G panel has two power supplies:
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 rather
> > broken (tda998x has stopped working as its stuck with a physical
> >
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
---
The redundant fb helpers .gamma_set and .gamma_get are no longer used.
Remove the dead code.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/armada/armada_crtc.c | 10 --
drivers/gpu/drm/armada/armada_crtc.h | 2 --
drivers/gpu/drm/armada/armada_fbdev.c | 2 --
3
While at it, add some words in the kernel-doc about the 'replaced' arg and
remove a faulty kernel-doc comment on the return value.
Also remove a redundant return statement.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_atomic.c | 17 +
Drivers no longer have any need for these callbacks, and there are no
users. Zap. Zap-zap-zzzap-p-pp-p.
Signed-off-by: Peter Rosin
---
include/drm/drm_crtc.h | 8
include/drm/drm_fb_helper.h | 32
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
---
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
---
Hi!
While trying to get CLUT support for the atmel_hlcdc driver, and
specifically for the emulated fbdev interface, I received some
push-back that my feeble in-driver attempts should be solved
by the core. This is my attempt to do it right.
I have obviously not tested all of this with more than
On Thu, Jul 06, 2017 at 01:29:54PM +0200, Neil Armstrong wrote:
> 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
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 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
-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.
The right variable to check here is port, not dp.
This issue was detected using Coccinelle and the following semantic patch:
@@
expression x;
identifier fld;
@@
* x = devm_kzalloc(...);
... when != x == NULL
x->fld
Signed-off-by: Gustavo A. R. Silva
---
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
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
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
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 |
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
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 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, );
>>>
>>> With atomic you don't need to grab locks, this is done behind the scenes
>>> (as long as you handle the
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
>
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
---
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
---
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 |
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
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
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
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
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
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 +--
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
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
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
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
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 +-
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
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
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
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
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
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
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 +++--
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
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ä
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
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
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
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
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
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 |
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
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ä
---
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.
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
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
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
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(_priv->pm.wakeref_count);
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
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
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=edit
kern.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
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
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)
[
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
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
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:
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
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
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:
> 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
>>
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Alexander Tsoy (alexan...@tsoy.me) changed:
What|Removed |Added
CC||alexan...@tsoy.me
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
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
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
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
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
1 - 100 of 136 matches
Mail list logo