aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-07drm/i915/display: Use external dependency loop for port syncJosé Roberto de Souza1-52/+17
This loop was added directly to intel_atomic_check() to be used by all other features that have external pipe dependencies, so using it and removing intel_atomic_check_synced_crtcs(). After this changes is_trans_port_sync_master() it not used anywhere, so removing it. Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Cc: Manasi Navare <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915: fix an error code in intel_modeset_all_tiles()Dan Carpenter1-1/+1
There is a cut and paste bug so we return the wrong error code. Fixes: a603f5bd1691 ("drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915: Add missing include file <linux/math64.h>YueHaibing1-0/+1
Fix build error: ./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state: ./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error: implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration] return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro)); Reported-by: Hulk Robot <[email protected]> Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result") Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media ↵Dhinakaran Pandiyan5-51/+188
engine Detect the modifier corresponding to media compression to enable display decompression for YUV and xRGB packed formats. A new modifier is added so that the driver can distinguish between media and render compressed buffers. Unlike render decompression, plane 6 and plane 7 do not support media decompression. v2: Fix checkpatch warnings on code style (Lucas) From DK: Separate modifier array for planes that cannot decompress media (Ville) v3: Support planar formats v4: Switch plane order v5: - Use format block descriptors to get CCS subsampling calculation right everywhere. - Extend the plane state normal view array to accommodate 4 color planes. - Use helpers to convert between main and CCS planes. v6: Add missing packed YUV formats to the MC format list. (Yang) v7: Align UV planes to tile-row size. Cc: Nanley G Chery <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Cc: Yang A Shi <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/fb: Extend format_info member arrays to handle four planesDhinakaran Pandiyan1-4/+4
addfb() uAPI has supported four planes for a while now, make format_info compatible with that. Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Cc: Mika Kahola <[email protected]> Cc: [email protected] Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/framebuffer: Format modifier for Intel Gen-12 media compressionDhinakaran Pandiyan1-0/+13
Gen-12 display can decompress surfaces compressed by the media engine, add a new modifier as the driver needs to know the surface was compressed by the media or render engine. v2: Update code comment describing the color plane order for YUV semiplanar formats. Cc: Nanley G Chery <[email protected]> Cc: Matt Roper <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Mika Kahola <[email protected]> Cc: [email protected] Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915: Make sure plane dims are correct for UV CCS planesImre Deak1-2/+6
As intel_fb_plane_get_subsampling() returns the subsampling factor wrt. its main plane, for a CCS plane we need to apply both the main and the CCS plane's subsampling factor on the FB's dimensions to get the CCS plane's dimensions. Cc: Dhinakaran Pandiyan <[email protected]> Cc: Mika Kahola <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915: Add debug message for FB plane[0].offset!=0 errorImre Deak1-1/+4
Print a debug message if the FB plane[0] offset is not 0 as expected, to help understainding an add FB IOCTL fail. Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Mika Kahola <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/tgl: Make sure a semiplanar UV plane is tile row size alignedImre Deak1-3/+33
Currently the GGTT offset of a UV plane in a semiplanar YUV FB is tile size (4kB) aligned. I noticed, that enforcing only this alignment leads oddly to random memory corruptions on TGL while scanning out Y-tiled FBs. This issue can be easily reproduced with a UV plane offset that is not aligned to the plane's tile row size. Some experiments showed the correct alignment to be tile row size indeed. This also makes sense, since the de-tiling fence created for the object - with its own stride and so "left" and "right" edge - applies to all the planes in the FB, so each tile row of all planes should be tile row aligned. In fact BSpec requires this alignment since SKL. On SKL we may enforce this due to the AUX plane x,y coords check, but on ICL and TGL we don't. For now enforce this only on TGL; I can follow up with any necessary change for ICL after more tests. BSpec requires a stricter alignment for linear UV planes too (kind of a tile row alignment), but it's unclear whether that's really needed (couldn't be explained with the de-tiling fence as above) and enforcing that could break existing user space; so avoid that too for now until more tests. v2: - Clarify the commit log wrt. the address space the alignment applies to. (Chris) Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Acked-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915: Add support for non-power-of-2 FB plane alignmentImre Deak1-8/+16
At least one framebuffer plane on TGL - the UV plane of YUV semiplanar FBs - requires a non-power-of-2 alignment, so add support for this. This new alignment restriction applies only to an offset within an FB, so the GEM buffer itself containing the FB must still be power-of-2 aligned. Add a check for this (in practice plane 0, since the plane 0 offset must be 0). v2: - Fix WARN check for alignment=0. v3: - Return error for alignment programming bugs. (Chris) Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/mgag200: Add module parameter to pin all buffers at offset 0Thomas Zimmermann1-0/+14
For hardware that does not interpret the startadd field correctly, add the module parameter 'hw_bug_no_startadd', which enables the workaround. v3: * style and typo fixes v2: * ask user for feedback if the option is active Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: John Donnelly <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/vram-helper: Support struct drm_driver.gem_create_objectThomas Zimmermann1-3/+12
Drivers that what to allocate VRAM GEM objects with additional fields can now do this by implementing struct drm_driver.gem_create_object. v3: * separately check allocation failure in if/else branches before upcast to gbo v2: * only cast to gbo within if branch; set gbo directly in else branch Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/vram-helper: Remove BO device from public interfaceThomas Zimmermann6-19/+13
TTM is an implementation detail of the VRAM helpers and therefore shouldn't be exposed to the callers. There's only one correct value for the BO device anyway, which is the one stored in the DRM device. So remove struct ttm_bo_device from the VRAM-helper interface and use the device's VRAM manager unconditionally. The GEM initializer function fails if the VRAM manager has not been initialized. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/vram-helper: Remove interruptible flag from public interfaceThomas Zimmermann6-18/+11
The flag 'interruptible', which is passed to various functions, is always set to be false. Remove it and hard-code the value. Signed-off-by: Thomas Zimmermann <[email protected]> Suggested-by: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/bridge: Add the necessary bits to support bus format negotiationBoris Brezillon2-1/+390
drm_bridge_state is extended to describe the input and output bus configurations. These bus configurations are exposed through the drm_bus_cfg struct which encodes the configuration of a physical bus between two components in an output pipeline, usually between two bridges, an encoder and a bridge, or a bridge and a connector. The bus configuration is stored in drm_bridge_state separately for the input and output buses, as seen from the point of view of each bridge. The bus configuration of a bridge output is usually identical to the configuration of the next bridge's input, but may differ if the signals are modified between the two bridges, for instance by an inverter on the board. The input and output configurations of a bridge may differ if the bridge modifies the signals internally, for instance by performing format conversion, or*modifying signals polarities. Bus format negotiation is automated by the core, drivers just have to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they want to take part to this negotiation. Negotiation happens in reverse order, starting from the last element of the chain (the one directly connected to the display) up to the first element of the chain (the one connected to the encoder). During this negotiation all supported formats are tested until we find one that works, meaning that the formats array should be in decreasing preference order (assuming the driver has a preference order). Note that the bus format negotiation works even if some elements in the chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks. In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets the previous bridge element decide what to do (most of the time, bridge drivers will pick a default bus format or extract this piece of information from somewhere else, like a FW property). Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed by: Jernej Skrabec <[email protected]> Tested-by: Jonas Karlman <[email protected]> [narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/bridge: Add an ->atomic_check() hookBoris Brezillon3-7/+96
So that bridge drivers have a way to check/reject an atomic operation. The drm_atomic_bridge_chain_check() (which is just a wrapper around the ->atomic_check() hook) is called in place of drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented, the core falls back on ->mode_fixup(), so the behavior should stay the same for existing bridge drivers). Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed by: Jernej Skrabec <[email protected]> Tested-by: Jonas Karlman <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/bridge: Patch atomic hooks to take a drm_bridge_stateBoris Brezillon4-36/+82
This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The only driver implementing those hooks (analogix DP) is patched too. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed by: Jernej Skrabec <[email protected]> Tested-by: Jonas Karlman <[email protected]> [narmstrong: renamed state as old_bridge_state in rcar_lvds_atomic_disable] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/bridge: Add a drm_bridge_state objectBoris Brezillon5-6/+309
One of the last remaining objects to not have its atomic state. This is being motivated by our attempt to support runtime bus-format negotiation between elements of the bridge chain. This patch just paves the road for such a feature by adding a new drm_bridge_state object inheriting from drm_private_obj so we can re-use some of the existing state initialization/tracking logic. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed by: Jernej Skrabec <[email protected]> Tested-by: Jonas Karlman <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06Revert "drm: atmel-hlcdc: enable sys_clk during initalization."Claudiu Beznea1-18/+1
This reverts commit d2c755e66617620b729041c625a6396c81d1231c ("drm: atmel-hlcdc: enable sys_clk during initalization."). With commit "drm: atmel-hlcdc: enable clock before configuring timing engine" there is no need for this patch. Code is also simpler. Cc: Sandeep Sheriker Mallikarjun <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: atmel-hlcdc: prefer a lower pixel-clock than requestedPeter Rosin1-2/+2
The intention was to only select a higher pixel-clock rate than the requested, if a slight overclocking would result in a rate significantly closer to the requested rate than if the conservative lower pixel-clock rate is selected. The fixed patch has the logic the other way around and actually prefers the higher frequency. Fix that. Signed-off-by: Peter Rosin <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Fixes: 9946a3a9dbed ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested") Reported-by: Claudiu Beznea <[email protected]> Tested-by: Claudiu Beznea <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: <[email protected]> # v4.20+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: atmel-hlcdc: enable clock before configuring timing engineClaudiu Beznea1-1/+7
Changing pixel clock source without having this clock source enabled will block the timing engine and the next operations after (in this case setting ATMEL_HLCDC_CFG(5) settings in atmel_hlcdc_crtc_mode_set_nofb() will fail). It is recomended (although in datasheet this is not present) to actually enabled pixel clock source before doing any changes on timing enginge (only SAM9X60 datasheet specifies that the peripheral clock and pixel clock must be enabled before using LCD controller). Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support") Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: <[email protected]> # v4.0+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: atmel-hlcdc: use double rate for pixel clock only if supportedClaudiu Beznea1-3/+3
Doubled system clock should be used as pixel cock source only if this is supported. This is emphasized by the value of atmel_hlcdc_crtc::dc::desc::fixed_clksrc. Fixes: a6eca2abdd42 ("drm: atmel-hlcdc: add config option for clock selection") Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: <[email protected]> # v5.3+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06dt-bindings: fix warnings in xinpeng,xpp055c272.yamlSam Ravnborg1-0/+2
The reg property in the example caused following warnings: xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format): /example-0/dsi@ff450000/panel@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) xinpeng,xpp055c272.example.dt.yaml: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dt.yaml: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dt.yaml: Warning (spi_bus_reg): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dts:18.21-24.15: Warning (avoid_default_addr_size): /example-0/dsi@ff450000/panel@0: Relying on default #address-cells value xinpeng,xpp055c272.example.dts:18.21-24.15: Warning (avoid_default_addr_size): /example-0/dsi@ff450000/panel@0: Relying on default #size-cells value Added #address-cells and #size-cells to silence the warning. Signed-off-by: Sam Ravnborg <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Rob Herring <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK onlyKai Vehmanen1-2/+2
Revert changes done in commit f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms"). Audio drivers communicate with i915 over HDA bus multiple times during system boot-up and each of these transactions result in matching get_power/put_power calls to i915, and depending on the platform, a modeset change causing visible flicker. GLK is the only platform with minimum CDCLK significantly lower than BCLK, and thus for GLK setting a higher CDCLK is mandatory. For other platforms, minimum CDCLK is close but below 2*BCLK (e.g. on ICL, CDCLK=176.4kHz with BCLK=96kHz). Spec-wise the constraint should be set, but in practise no communication errors have been reported and the downside if set is the flicker observed at boot-time. Revert to old behaviour until better mechanism to manage probe-time clocks is available. The full CDCLK>=2*BCLK constraint is still enforced at pipe enable time in intel_crtc_compute_min_cdclk(). Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/913 Fixes: f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms") Signed-off-by: Kai Vehmanen <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/bridge: cdns: remove set but not used variable 'nlanes'yu kuai1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_mode2cfg’: drivers/gpu/drm/bridge/cdns-dsi.c:515:11: warning: variable ‘nlanes’ set but not used [-Wunused-but-set-variable] It is never used, and so can be removed. Signed-off-by: yu kuai <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/bridge: cdns: remove set but not used variable 'bpp'yu kuai1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_bridge_enable’: drivers/gpu/drm/bridge/cdns-dsi.c:788:6: warning: variable ‘bpp’ set but not used [-Wunused-but-set-variable] It is never used, and so can be removed. Signed-off-by: yu kuai <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: meson: Remove unneeded semicolonzhengbin2-2/+2
Fixes coccicheck warning: drivers/gpu/drm/meson/meson_crtc.c:360:3-4: Unneeded semicolon drivers/gpu/drm/meson/meson_plane.c:181:2-3: Unneeded semicolon Reported-by: Hulk Robot <[email protected]> Signed-off-by: zhengbin <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/gt: Mark up virtual engine uabi_instanceChris Wilson1-0/+2
Be sure to initialise the uabi_instance on the virtual engine to the special invalid value, just in case we ever peek at it from the uAPI. Reported-by: Tvrtko Ursulin <[email protected]> Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.4+ Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: bridge: dw-hdmi: constify copied structureJulia Lawall1-1/+1
The dw_hdmi_hw structure is only copied into another structure, so make it const. The opportunity for this change was found using Coccinelle. Fixes: 7ed6c665e19d ("drm: bridge/dw_hdmi-ahb-audio: add audio driver") Signed-off-by: Julia Lawall <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/gt: Use memset_p to clear the portsChris Wilson1-5/+10
Put memset_p to use to clear the array of pointers used for tracking the ELSP. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/gt: Drop mutex serialisation between context pin/unpinChris Wilson2-17/+26
The last remaining reason for serialising the pin/unpin of the intel_context is to ensure that our preallocated wakerefs are not consumed too early (i.e. the unpin of the previous phase does not emit the idle barriers for this phase before we even submit). All of the other operations within the context pin/unpin are supposed to be atomic... Therefore, we can reduce the serialisation to being just on the i915_active.preallocated_barriers itself and drop the nested pin_mutex from intel_context_unpin(). Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/gt: Convert the final GEM_TRACE to GT_TRACE and coChris Wilson2-13/+10
Convert the few remaining GEM_TRACE() used for debugging over to the appropriate GT_TRACE or RQ_TRACE. References: 639f2f24895f ("drm/i915: Introduce new macros for tracing") Signed-off-by: Chris Wilson <[email protected]> Cc: Venkata Sandeep Dhanalakota <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915: Merge i915_request.flags with i915_request.fence.flagsChris Wilson7-15/+41
As we already have a flags field buried within i915_request, reuse it! Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/selftests: Impose a timeout for request submissionChris Wilson1-5/+21
Avoid spinning indefinitely waiting for the request to be submitted, and instead apply a timeout. A secondary benefit is that the error message will show which suspect is blocked. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/i915/selftests: Fixup sparse __user annotation on local varChris Wilson1-1/+2
The local var does not need the __user as it exists on the kernel stack and not a pointer into the __user address space. drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:989:9: warning: dereference of noderef expression drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:990:13: warning: dereference of noderef expression Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/hisilicon/hibmc: Export VRAM MM information to debugfsThomas Zimmermann1-0/+1
This change makes information about VRAM consumption available on debugfs. See /sys/kernel/debug/dri/0/vram-mm for an overview of how VRAM is being used. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/hisilicon/hibmc: Implement hibmc_dumb_create() with generic helpersThomas Zimmermann2-50/+2
The hibmc driver aligns scanlines to 16 bytes. By using the new pitch_align argument of drm_gem_vram_fill_create_dumb(), convert hibmc over. v2: * move changes to VRAM helpers into separate patch Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/vram: Support scanline alignment for dumb buffersThomas Zimmermann3-4/+12
Adding the pitch alignment as an argument to drm_gem_vram_fill_create_dumb() allows to align scanlines to certain offsets. A value of 0 disables scanline pitches. v3: * only do power-of-2 test if pitch_align given; fails otherwise * mgag200: call drm_gem_vram_fill_create_dumb() with pitch_align v2: * split of patch from related hibmc changes * test if scanline pitch is power of 2 Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/hisilicon/hibmc: Replace struct hibmc_framebuffer with generic codeThomas Zimmermann3-81/+3
The hibmc driver's struct hibmc_framebuffer stores a DRM framebuffer with an associated GEM object. This functionality is also provided by generic code. Switch hibmc over. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/hisilicon/hibmc: Switch to generic fbdev emulationThomas Zimmermann4-255/+3
There's nothing special about hibmc's fbdev emulation that is not provided by the generic implementation. Switch over and remove the driver's code. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm: rockchip: rk3066_hdmi: set edid fifo addressNickey Yang1-0/+3
Fix edid reading error when edid's block > 2. Signed-off-by: Nickey Yang <[email protected]> Signed-off-by: Johan Jonker <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06drm/rockchip: lvds: Add PX30 supportMiquel Raynal2-0/+157
Introduce PX30 LVDS support. This means adding the relevant helper functions, a specific probe and also the initialization of a specific PHY. Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-06Merge drm/drm-next into drm-misc-nextMaarten Lankhorst11321-237418/+558548
Requested, and we need v5.5-rc1 backported as our current branch is still based on v5.4. Signed-off-by: Maarten Lankhorst <[email protected]>
2020-01-05drm/rockchip: lvds: move hardware-specific functions togetherMiquel Raynal1-45/+45
Reorganize a bit the functions order to clarify the driver and separate hardware independent and specific functions a bit. This change only moves functions around, there is no functional change. Signed-off-by: Miquel Raynal <[email protected]> [adapted to recent drm_panel_get_modes() param change ] Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05drm/rockchip: lvds: improve error handling in helper functionsMiquel Raynal1-8/+23
Return errors instead of returning void from internal helpers. When these helpers are called, check the returned value and print an error message in this case and not blindly continue. Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05drm/rockchip: lvds: Create an RK3288 specific probe functionMiquel Raynal1-37/+57
The probe function is highly adapted to the RK3288 specificities, move all specific bits into an "rk3288_probe" function, also part of the platform data. The goal is to ease the addition of new flavors of Rockchip LVDS IPs. Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05drm/rockchip: lvds: Change platform data to hold helper_funcs pointerMiquel Raynal2-21/+14
Prepare the introduction of PX30 support by using drm_encoder_helper_funcs as platform data instead of multiple register names which are specific to rk3288 and not generic to all Rockchip IPs. This way adding support for a new flavor of a similar IP will be a matter of adding the relevant helper funcs. Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05drm/rockchip: lvds: Harmonize function namesMiquel Raynal1-66/+74
Prepare the introduction of PX30 support by clarifying the function prefixes. We continue to prefix with 'rockchip_lvds_' generic functions that are not specific to a single hardware. Functions implying hardware modifications are now prefixed with 'rk3288_lvds_'. Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05drm/rockchip: lvds: Fix indentation of a #defineMiquel Raynal1-1/+1
Fix a #define indentation before adding more lines. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-05dt-bindings: display: rockchip-lvds: Document PX30 PHYMiquel Raynal1-0/+3
PX30 SoCs use a single PHY shared by two display pipelines: MIPI DSI and LVDS. In the case of the LVDS IP, document the possibility to fill a PHY handle. Signed-off-by: Miquel Raynal <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.