- 07 Mar, 2018 14 commits
-
-
Linus Walleij authored
We want to cut down the default bpp to 16 on the RealView so we can have a 1024x768 framebuffer console by default. The memory bandwidth limitations makes this not work with the PL111 default of 32bpp. This builds on top of the earlier patches making the framebuffer default bpp a per-variant variable. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180302090948.6399-4-linus.walleij@linaro.org
-
Linus Walleij authored
The PL110, Integrator and Versatile boards strongly prefer to use 16 BPP even if other modes are supported, both to keep down memory consumption and also to easier find a good match to supported resolutions with consideration taken to the memory bandwidth of the platforms. Reviewed-by:
-
Linus Walleij authored
This fixes up the .mode_valid() vtable entry documentation by copyediting the documentation from the .mode_valid() documentation in the drm_modeset_helper_vtables.h file. Fixes: 40275dc4 ("drm: simple_kms_helper: Add mode_valid() callback support") Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Linus Walleij authored
It's better if we explain a bit that this pertains to non-programmable VGA DAC bridges. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Shirish S authored
Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the for_each_oldnew_plane_in_state way or reading plane states. The plane states are required to be read in reverse order for amd drivers, cause the z order convention followed in linux is opposite to how the planes are supposed to be presented to DC engine, which is in common to both windows and linux. V2: fix compile time errors due to -Werror flag. Signed-off-by:
Shirish S <shirish.s@amd.com> Signed-off-by:
Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520392203-6885-1-git-send-email-shirish.s@amd.com
-
Ville Syrjälä authored
Pimp drm_property_type_valid() to check for more fails with the property flags. Also make the check before adding the property, and bail out if things look bad. Since we're now chekcing for more than the type let's also change the function name to drm_property_flags_valid(). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-6-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
The property flags are part of the uabi and we have 32 bits for them. Pass them around as u32 internally as well, instead of a signed int. Signed-off-by:
-
Ville Syrjälä authored
DRM_MODE_PROP_PENDING is not used anywhere (except printed out by libdrm proptest/modetest). This seems to be yet another thing blindly copied from xrandr. Quoting from the protocol spec: "If 'pending' is TRUE, changes made to property values with RRChangeOutputProperty will be saved in the pending property value and be automatically copied to the current value on the next RRSetCrtcConfig request involving the named output. If 'pending' is FALSE, changes are copied immediately." So it was some kind of early idea for atomic property updates. Signed-off-by:
-
Ville Syrjälä authored
Enum values >63 with a bitmask property is a programmer error. WARN when someone is attempting this. Signed-off-by:
-
Ville Syrjälä authored
Trying to add enum values to non-enum/bitmask properties is a programmer mistake. WARN to make sure the developers notice their mistake. Signed-off-by:
-
Ville Syrjälä authored
If the property already has the enum value WARN and bail. Replacing enum values doesn't make sense to me. Throw out the pointless list_empty() while at it. Cc: Daniel Vetter <daniel@ffwll.ch> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Marek Szyprowski authored
If there is another bridge after analogix_dp, then the connector object should not be created. This fixes following timeouts on Exynos5420-based Chromebook2 Peach-PIT board during boot: exynos-dp 145b0000.dp-controller: AUX CH cmd reply timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-4-m.szyprowski@samsung.com
-
Marek Szyprowski authored
Enabling runtime power management early in analogix_dp_bind() causes following kernel NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 000007d8 pgd = 28ffa2e4 [000007d8] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 6 PID: 69 Comm: kworker/6:1 Not tainted 4.16.0-rc1-00062-ge25751974ba8 #3622 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) Workqueue: events deferred_probe_work_func PC is at analogix_dp_resume+0x8/0xc0 LR is at pm_generic_runtime_resume+0x2c/0x38 pc : [<c0531b98>] lr : [<c0543fec>] psr: a0000113 sp : ee13fbd8 ip : 0000001a fp : 00000001 r10: ee0eb080 r9 : c0552bd8 r8 : c0fb1d98 r7 : eebb1010 r6 : eeae9808 r5 : 00000000 r4 : d4850415 r3 : ee0ed010 r2 : b2d05e00 r1 : 00000000 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 2000406a DAC: 00000051 Process kworker/6:1 (pid: 69, stack limit = 0x913205b4) Stack: (0xee13fbd8 to 0xee140000) ... [<c0531b98>] (analogix_dp_resume) from [<c0543fec>] (pm_generic_runtime_resume+0x2c/0x38) [<c0543fec>] (pm_generic_runtime_resume) from [<c054ffb4>] (__genpd_runtime_resume+0x2c/0x8c) [<c054ffb4>] (__genpd_runtime_resume) from [<c0552d24>] (genpd_runtime_resume+0x14c/0x258) [<c0552d24>] (genpd_runtime_resume) from [<c0547798>] (__rpm_callback+0x134/0x214) [<c0547798>] (__rpm_callback) from [<c0547898>] (rpm_callback+0x20/0x80) [<c0547898>] (rpm_callback) from [<c0546ff4>] (rpm_resume+0x3a0/0x734) [<c0546ff4>] (rpm_resume) from [<c05475ec>] (__pm_runtime_resume+0x64/0x9c) [<c05475ec>] (__pm_runtime_resume) from [<c053b95c>] (__device_attach+0x8c/0x134) [<c053b95c>] (__device_attach) from [<c053ad08>] (bus_probe_device+0x88/0x90) [<c053ad08>] (bus_probe_device) from [<c05390d0>] (device_add+0x3a8/0x580) [<c05390d0>] (device_add) from [<c06764c4>] (i2c_register_adapter+0xd4/0x3ec) [<c06764c4>] (i2c_register_adapter) from [<c05321c8>] (analogix_dp_bind+0x2a0/0x410) [<c05321c8>] (analogix_dp_bind) from [<c0528e90>] (exynos_dp_bind+0x9c/0x12c) [<c0528e90>] (exynos_dp_bind) from [<c0535bc4>] (component_bind_all+0xfc/0x258) [<c0535bc4>] (component_bind_all) from [<c0522ee8>] (exynos_drm_bind+0x15c/0x28c) [<c0522ee8>] (exynos_drm_bind) from [<c0536378>] (try_to_bring_up_master+0x1b8/0x29c) [<c0536378>] (try_to_bring_up_master) from [<c05364fc>] (component_add+0xa0/0x170) [<c05364fc>] (component_add) from [<c0528fe4>] (exynos_dp_probe+0x64/0xb8) [<c0528fe4>] (exynos_dp_probe) from [<c053debc>] (platform_drv_probe+0x50/0xb0) [<c053debc>] (platform_drv_probe) from [<c053bd18>] (driver_probe_device+0x2b8/0x4a0) [<c053bd18>] (driver_probe_device) from [<c0539e4c>] (bus_for_each_drv+0x44/0x8c) [<c0539e4c>] (bus_for_each_drv) from [<c053b970>] (__device_attach+0xa0/0x134) [<c053b970>] (__device_attach) from [<c053ad08>] (bus_probe_device+0x88/0x90) [<c053ad08>] (bus_probe_device) from [<c053b258>] (deferred_probe_work_func+0x3c/0x168) [<c053b258>] (deferred_probe_work_func) from [<c014352c>] (process_one_work+0x1d0/0x7bc) [<c014352c>] (process_one_work) from [<c0143b84>] (worker_thread+0x34/0x4dc) [<c0143b84>] (worker_thread) from [<c014a30c>] (kthread+0x128/0x164) [<c014a30c>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20) Exception stack(0xee13ffb0 to 0xee13fff8) ffa0: 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e2800e37 eafee601 e92d4070 e1a05000 (e59067d8) ---[ end trace bf6046013df7cab2 ]--- This oops happens, because analogix_dp_bind() calls drm_dp_aux_register() which registers i2c adapter. I2C core tries to runtime get i2c host device during registration. This ends in analogix_dp_resume(), but dp context is NULL there. dp context is set in exynos_dp_bind() after executing analogix_dp_bind(). Fix this issue by postponing enabling runtime power management after drm_dp_aux_register(). Signed-off-by:
-
zain wang authored
The bridge does not need to be powered in analogix_dp_bind(), so remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp() as well as their power-off counterparts. Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
zain wang <wzz@rock-chips.com> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> [the patch originally just removed the power_on portion, seanpaul removed the power off code as well as improved the commit message] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Signed-off-by:
-
- 06 Mar, 2018 8 commits
-
-
Christian König authored
Most of the time we only need the dma addresses. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Roger He <Hongbo.He@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-2-christian.koenig@amd.com Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-3-christian.koenig@amd.com Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-4-christian.koenig@amd.com Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-5-christian.koenig@amd.com Link: https://patchwork.freedesktop.org/patch/msgid/BN6PR12MB18262C0DE9B5F07B9A42EAE7F2C60@BN6PR12MB1826.namprd12.prod.outlook.com
-
Christian König authored
Unpin the GEM object only after freeing the sg table. Signed-off-by:
-
Ville Syrjälä authored
Reject requests to add properties/enums with an overly long name. Previously we would have just silently truncated the string and exposed it userspace. v2: drm_property_create() returns a pointer Signed-off-by:
-
Ville Syrjälä authored
Creating a property that doesn't have a name makes no sense to me. Don't allow it. Signed-off-by:
-
Neil Armstrong authored
The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also identified needing this workaround. This patch adds the corresponding version to enable a single iteration for this specific version. Fixes: be41fc55 ("drm: bridge: dw-hdmi: Handle overflow workaround based on device version") Acked-by:
Archit Taneja <architt@codeaurora.org> [narmstrong: s/identifies/identified and rebased against Jernej's change] Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1519386277-25902-1-git-send-email-narmstrong@baylibre.com
-
Baruch Siach authored
Use positive logic for better readability. This also eliminates one of_node_put() call, making the code shorter. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Tested-by:
Archit Taneja <archit@cradlewise.com> Link: https://patchwork.freedesktop.org/patch/msgid/61c56895d44117d80e7d82f04e729e29c60fadbd.1519327370.git.baruch@tkos.co.il
-
Joe Moriarty authored
The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer dereference problem. - drivers/gpu/drm/drm_drv.c Any calls to drm_minor_get_slot() could result in the return of a NULL pointer when an invalid DRM device type is encountered. The return of NULL was removed with BUG() from drm_minor_get_slot(). Signed-off-by:
Joe Moriarty <joe.moriarty@oracle.com> Reviewed-by:
Steven Sistare <steven.sistare@oracle.com> Signed-off-by:
-
Joe Moriarty authored
The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem. - drivers/gpu/drm/drm_vblank.c Null pointer checks were added to return values from calls to drm_crtc_from_index(). There is a possibility, however minute, that crtc->index may not be found when trying to find the struct crtc from it's assigned index given in drm_crtc_init_with_planes(). 3 return checks for NULL where added with a call to WARN_ON(!crtc). Signed-off-by:
-
- 05 Mar, 2018 7 commits
-
-
Ville Syrjälä authored
Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well v3: Resolve simple_kms_helper conflict Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Russell King <rmk+kernel@armlinux.org.uk> Suggested-by:
Thierry Reding <treding@nvidia.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk Reviewed-by:
-
Ville Syrjälä authored
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Since armada isn't atomic we'll use crtc->enabled and crtc->mode instead of the stuff under crtc_state. Once everyone agrees on how the clip rectangle gets set up we can move the code into drm_atomic_helper_check_plane_state(). Cc: Dave Airlie <airlied@redhat.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
As armada isn't an atomic driver trying to pass a non-populated crtc->state to drm_atomic_helper_check_plane_state() will end in tears. Construct a temporary crtc state a la drm_plane_helper_check_update() and pass that instead. For now we just really need crtc_state->enable to be there. Cc: Dave Airlie <airlied@redhat.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Stefan Wahren authored
Since we aren't in atomic context replace this long udelay with a usleep_range. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Daniel Stone authored
The IN_FORMATS blob allows the kernel to advertise to userspace which format/modifier combinations are supported, per plane. Use this to advertise that we support both T_TILED and linear. v2: - Only advertise T_TILED for RGB (Eric) - Actually turn on allow_fb_modifiers (Eric) Signed-off-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Philippe CORNU authored
The readl_poll_timeout() return value is 0 in case of success so it is better to detect errors without taking care of the return value sign. Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Reviewed-by:
-
Maarten Lankhorst authored
After we acquired all generic modeset locks in drm_modeset_lock_all, it's unsafe acquire any other so just mark acquisition as done. Atomic drivers shouldn't use drm_modeset_lock_all. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221152331.9212-1-maarten.lankhorst@linux.intel.comReviewed-by:
-
- 02 Mar, 2018 11 commits
-
-
Ville Syrjälä authored
Add support for the COLOR_RANGE property on planes. This property selects whether the input YCbCr data is to treated as limited range or full range. On most platforms this is a matter of setting the "YUV range correction disable" bit, and on VLV/CHV we'll just have to program the color correction logic to pass the data through unmodified. v2: Rebase Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Bring us forward from the stone age and switch our default YCbCr->RGB conversion matrix to BT.709 from BT.601. I would expect most matrial to be BT.709 these days. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Acked-by:
-
Ville Syrjälä authored
Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites have a fully programmable matrix, so in theory we could handle anything, but it doesn't seem all that useful to expose anything beyond BT.601 and BT.709 at this time. GLK can supposedly do BT.2020, but let's leave enabling that for the future as well. v2: Rename bit defines to match the spec more closely (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by:
-
Ville Syrjälä authored
On GLK the plane CSC controls moved into the COLOR_CTL register. Update the code to progam the YCbCr->RGB CSC mode correctly when faced with an YCbCr framebuffer. The spec is rather confusing as it calls the mode "YUV601 to RGB709". I'm going to assume that just means it's going to use the YCbCr->RGB matrix as specified in BT.601 and doesn't actually change the gamut. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and saturation). On CHV pipe B we were actually doing the right thing already because we progammed the custom CSC matrix to do expect limited range input. Now that well pre-expand the data out with the color correction unit, we need to change the CSC matrix to operate with full range input instead. This should make the sprite output of the other pipes match the sprite output of pipe B reasonably well. Looking at the resulting pipe CRCs, there can be a slight difference in the output, but as I don't know the formula used by the fixed function CSC of the other pipes, I don't think it's worth the effort to try to match the output exactly. It might not even be possible due to difference in internal precision etc. One slight caveat here is that the color correction registers are single bufferred, so we should really be updating them during vblank, but we still don't have a mechanism for that, so just toss in another FIXME. v2: Rebase v3: s/bri/brightness/ s/con/contrast/ (Shashank) v4: Clarify the constants and math (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Tang, Jun" <jun.tang@intel.com> Reported-by:
"Tang, Jun" <jun.tang@intel.com> Cc: stable@vger.kernel.org Fixes: 7f1f3851 ("drm/i915: sprite support for ValleyView v4") Reviewed-by:
-
Ville Syrjälä authored
Include color_enconding and color_range in the plane state dump. v2: Add kerneldoc (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Jyri Sarha authored
Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. v2: Add/fix kerneldocs, verify bitmasks (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] Signed-off-by:
-
Jernej Skrabec authored
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which is compatible to 32-bit SoCs, so allow building DRM driver for arm64 architecture. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-14-jernej.skrabec@siol.net
-
Jernej Skrabec authored
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3 HDMI PHY is completely custom PHY. However, they still have many things in common like clock and reset setup, setting sync polarity and more. Add support for H3 HDMI PHY variant. While documentation exists for this PHY variant, it doesn't go in great details. Because of that, almost all settings are copied from BSP linux 4.4. Interestingly, those settings are slightly different to those found in a older BSP with Linux 3.4. For now, no user visible difference was found between them. Signed-off-by:
-
Jernej Skrabec authored
DW HDMI PHY macros are moved to header file and expanded with the registers present on newer SoCs like H3 and H5. Signed-off-by:
-
Jernej Skrabec authored
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While some things like clock and reset setup are the same, PHY configuration differs a lot. Split out code which is PHY specific to separate functions and create a structure which holds pointers to those functions. Signed-off-by:
-
