Those are now all protected using fb_helper->lock.
v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.
v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #7 from Matias N. Goldberg ---
As I keep reading the code and getting familiar, everything starts making
sense:
/**
* If a shader can be created when we get its source.
* This means it has only 1 variant,
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Michel Dänzer changed:
What|Removed |Added
CC||mar...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #5 from Matias N. Goldberg ---
Mystery solved:
When I click the material button, this function is hit:
1 st_get_fp_variantst_program.c 1326 0x7fbb34c5c595
2 get_color_fp_variant
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #4 from Matias N. Goldberg ---
+1
I get this error too.
This bug is NOT https://bugs.freedesktop.org/show_bug.cgi?id=97059 which gets
fixed by either using DRI2 or selecting Triple Buffer in Blender.
This
Regards
Shashank
On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
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
Regards
Shashank
On 7/4/2017 9:25 PM, Ville Syrjälä wrote:
On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote:
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is
https://bugzilla.kernel.org/show_bug.cgi?id=196271
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
FWIW, this is more likely an issue in Mesa than the kernel.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #6 from Michel Dänzer (mic...@daenzer.net) ---
Is this a regression from older kernel versions? If yes, can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi again!
As I said before, our pipeline is transparent and opaque to the cpu. To
implement vblank, all I have is the xilinx vdma frame counter interrupt. I
was wondering why it was not used in xilinx_drm_crtc_enable_vblank and
rather a specific method for vtc and dp was used.
Wouldn't it be
On 2017-07-04 12:36, Peter Rosin wrote:
> The pseudo-palette has nothing to do with the crtc, so move it
> out of the crtc loop and update the palette once, then break out
> early.
>
> Signed-off-by: Peter Rosin
Should of course be p...@axentia.se
I wonder when I managed to
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 19 +++
1
On Tue, Jul 04, 2017 at 05:48:21PM +0100, Colin King wrote:
> From: Colin Ian King
>
> A recent compat change removed the copying of i32.mode from info.mode.
> Add it back in to fix this removal as we currently are leaking information
> from the stack.
>
> Detected by
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
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
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
---
Handle the atomics directly in the ioctl instead, in preparation for the
fb_setcmap helper needing to commit the gamma map for several crtc in one
commit.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |
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
---
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
---
drivers/gpu/drm/drm_fb_helper.c | 17 -
1 file changed, 17 deletions(-)
diff --git
The pseudo-palette has nothing to do with the crtc, so move it
out of the crtc loop and update the palette once, then break out
early.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 60 +
1 file changed, 37
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
---
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
completely obsolete.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 165 +++-
1 file changed, 94 insertions(+), 71 deletions(-)
diff --git
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 |
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
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
if 'eb_create()' fails, we must release some resources as done in all other
error handling paths of this function.
Signed-off-by: Christophe JAILLET
---
This patch is just a guess based on surrounding gotos and function names.
(i.e. 'get_unused_fd_flags()' and
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
---
drivers/gpu/drm/ast/ast_drv.h |
https://bugzilla.kernel.org/show_bug.cgi?id=196247
guiscara...@gmail.com changed:
What|Removed |Added
CC||guiscara...@gmail.com
---
> do you also have a Mesa patch showing how the new APIs will be used?
Sent out to mesa dev just now.
> Remove these lines.
Right.
> Please consistently either use this, or don't add the util directory to the
> include path anywhere.
OK.
> Put an empty line between declarations and statements.
https://bugs.freedesktop.org/show_bug.cgi?id=100742
--- Comment #1 from Felix Hellmann ---
I can observe the same behaviour. Setting power_dpm_force_performance_level to
high reduces ans smoothes out the StreamVr Compositor frame timings. Even when
no "real" app is running (so
Den 04.07.2017 17.28, skrev Daniel Vetter:
On Tue, Jul 04, 2017 at 05:00:46PM +0200, Noralf Trønnes wrote:
Den 28.06.2017 19.12, skrev Daniel Vetter:
On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote:
Den 26.06.2017 11.43, skrev Daniel Vetter:
On Thu, Jun 08, 2017 at 05:14:34PM
Hi,
On Sun, Jul 02, 2017 at 05:27:10PM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
>
On Tue, Jul 4, 2017 at 2:45 PM, Geert Uytterhoeven wrote:
> On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>>
On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark wrote:
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #4 from Olaf H B (o...@seldiame.net) ---
Created attachment 257361
--> https://bugzilla.kernel.org/attachment.cgi?id=257361=edit
kernel.log (fragment)
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #5 from Olaf H B (o...@seldiame.net) ---
Created attachment 257363
--> https://bugzilla.kernel.org/attachment.cgi?id=257363=edit
some debug msgs for amdgpu powerplay code
I don't know if this useful but I added some extra prints in
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.
Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and make corresponding fixups
to clk enable/prepare_count
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #3 from Olaf H B (o...@seldiame.net) ---
Created attachment 257359
--> https://bugzilla.kernel.org/attachment.cgi?id=257359=edit
lspci verbose output for the vga card
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #2 from Olaf H B (o...@seldiame.net) ---
Created attachment 257357
--> https://bugzilla.kernel.org/attachment.cgi?id=257357=edit
configuration used in the kernel
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=196273
--- Comment #1 from Olaf H B (o...@seldiame.net) ---
Created attachment 257355
--> https://bugzilla.kernel.org/attachment.cgi?id=257355=edit
dmesg output
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=196273
Bug ID: 196273
Summary: Loss of video output and system freezes *ERROR*
Couldn't read SADs: 0
Product: Drivers
Version: 2.5
Kernel Version: 4.12.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=196271
Bug ID: 196271
Summary: [AMD] Computer crashes when trying to execute any
particle animation
Product: Drivers
Version: 2.5
Kernel Version: 4.9.30-1-MANJARO
Hardware:
https://bugs.freedesktop.org/show_bug.cgi?id=101695
Bug ID: 101695
Summary: mesa fails to compile illegal conversion of »int« in
»radeon_bo_domain«
Product: Mesa
Version: git
Hardware: Other
OS: All
From: Colin Ian King
A recent compat change removed the copying of i32.mode from info.mode.
Add it back in to fix this removal as we currently are leaking information
from the stack.
Detected by CoverityScan, CID#1449374 ("Unitialized scalar variable")
Fixes:
Hi all,
The purpose of this patch is to add support for the Orise Tech
otm8009a 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode).
This LCD panel is used in several STM32 boards.
Version 1:
- Initial commit
Best regards,
Philippe
Philippe CORNU (3):
dt-bindings: Add vendor prefix for Orise
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 boards.
Signed-off-by: Philippe CORNU
---
drivers/gpu/drm/panel/Kconfig
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| 20
1 file
Orise Technology is headquartered in Taiwan and specializes
in manufacture of Flat Panel Display Driver IC and Flat Panel
Display Controller IC.
Signed-off-by: Philippe CORNU
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
On Tue, Jul 4, 2017 at 5:40 PM, Ville Syrjälä
wrote:
>> + mutex_lock(_helper->dev->mode_config.mutex);
>> drm_enable_connectors(fb_helper, enabled);
>> + if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
>
> This changes the order
On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
> 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
On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote:
> This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
> structure. While handling the EDID from HDMI 2.0 sinks, its important to
> know if the source is capable of handling YCBCR 420 outputs or not, so that
> a
On Tue, Jul 04, 2017 at 05:18:28PM +0200, Daniel Vetter wrote:
> Those are now all protected using fb_helper->lock.
>
> v2: We still need to hold mode_config.mutex right around calling
> connector->fill_modes.
>
> v3: I forgot to hold mode_config.mutex while looking at
> connector->status and
On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote:
> HDMI displays can support various output types, based on
> the color space and subsampling type. The possible
> outputs from a HDMI 2.0 monitor could be:
> - RGB
> - YCBCR 444
> - YCBCR 422
> - YCBCR 420
>
> This patch adds a
On Tue, Jul 04, 2017 at 05:18:30PM +0200, Daniel Vetter wrote:
> 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
On Tue, Jul 04, 2017 at 05:00:46PM +0200, Noralf Trønnes wrote:
>
> Den 28.06.2017 19.12, skrev Daniel Vetter:
> > On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote:
> > > Den 26.06.2017 11.43, skrev Daniel Vetter:
> > > > On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes
On Tue, Jul 04, 2017 at 05:09:36PM +0200, Andrzej Hajda wrote:
> On 04.07.2017 16:25, Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote:
> >> On 04.07.2017 14:44, Ville Syrjälä wrote:
> >>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
>
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
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
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
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
Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
Those are now all protected using fb_helper->lock.
v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.
v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to
Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.
This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for
That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
On Tue, Jun 27, 2017 at 11:42:53AM -0400, Harry Wentland wrote:
> On 2017-06-27 10:59 AM, Daniel Vetter wrote:
> > Too jarring.
> >
> > Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic
> > helpers (v2)")
> > Cc: Andrey Grodzovsky
> > Cc: Alex
Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.
Cc: John Stultz
Hi all,
Here's the locking patches respun with Maarten's review. I think that part is
ready for merging. The deferred setup itself needs more thought, since both
Maarten and Liviu are still unhappy with what happens between the deferred setup
and fbcon.
Cheers, Daniel
Daniel Vetter (9):
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
This patch just adds the new lock everywhere we currently grab
mode_config->mutex
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
v2: Also handle intel_connector_add_to_fbdev.
v3: Prevent race in intel_dp_mst with ->detect (Maarten)
Cc: Maarten Lankhorst
Cc: Alex Deucher
Since
commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae
Author: Archit Taneja
Date: Wed Aug 5 12:28:57 2015 +0530
drm: Add top level Kconfig option for DRM fbdev emulation
this is properly handled using dummy functions. This essentially
undoes
commit
Hi!
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check?
> >>>
> >>> It appears the reason was that I didn't have
> >>> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> >>>
> >>> I think that's wrong. I don't own an analog TV, so why should I enable
> >>> such
On 04.07.2017 16:25, Ville Syrjälä wrote:
> On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote:
>> On 04.07.2017 14:44, Ville Syrjälä wrote:
>>> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> From:
Den 28.06.2017 19.12, skrev Daniel Vetter:
On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote:
Den 26.06.2017 11.43, skrev Daniel Vetter:
On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes wrote:
Drm has no monochrome or greyscale support so add a conversion
from the common
On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote:
> On 04.07.2017 14:44, Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> >> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä
>
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
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
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
V4: Added r-b from
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
Cc: Ville Syrjala
Cc: Ander
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 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
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
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference,
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
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,
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
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
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr
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
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.
V5: Introduced the patch in series.
Cc: Ville Syrjala
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
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches,
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
On 04.07.2017 14:44, Ville Syrjälä wrote:
> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
>> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch
Looks good. Thanks.
I've queued this for my next pull request.
On Sun, Jul 02, 2017 at 01:26:55PM +0530, Arvind Yadav wrote:
> ttm_place are not supposed to change at runtime. All functions
> working with ttm_place provided by work
> with const ttm_place. So mark the non-const structs as
On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> > 3D to 2D mode in a timely fashion if
On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> 3D to 2D mode in a timely fashion if the source simply stops sending the
> HDMI infoframe. The suggested
On Mon, Jul 03, 2017 at 10:19:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> 3D to 2D mode in a timely fashion if the source simply stops sending the
> HDMI
1 - 100 of 110 matches
Mail list logo