- 18 Oct, 2016 9 commits
-
-
Laurent Pinchart authored
The driver uses drm_fb_get_bpp_depth() to check whether it can support the format requested by userspace when creating a framebuffer. This isn't the right API, as it doesn't differentiate between RGB formats other than on a depth and bpp basis. Fixing this requires non trivial changes to the drivers internals. As a first step, replace usage of the drm_fb_get_bpp_depth() function with an equivalent check based on drm_format_info(). This is part of a wider effort to remove usage of the drm_fb_get_bpp_depth() function in drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-9-git-send-email-laurent.pinchart@ideasonboard.com
-
Laurent Pinchart authored
The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. In the tilcdc_crtc_mode_set() function compute the hardware register value directly from the pixel format instead of computing the number of bits per pixels first. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Laurent Pinchart authored
The format helpers have historically treated unsupported formats as part of the default case, returning values that are likely wrong. We can't change this behaviour now without risking breaking drivers in difficult to detect ways, but we can WARN on unsupported formats to catch faulty callers. The only exception is the framebuffer_check() function that calls drm_format_info() to validate the format passed from userspace. This is a valid use case that shouldn't generate a warning. Signed-off-by:
-
Laurent Pinchart authored
Replace calls to the drm_format_*() helper functions with direct use of the drm_format_info structure. This improves efficiency by removing duplicate lookups. Signed-off-by:
Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by:
-
Laurent Pinchart authored
Turn the drm_format_*() helpers into wrappers around the drm_format_info lookup function to centralize all format information in a single place. Signed-off-by:
-
Laurent Pinchart authored
Various pieces of information about DRM formats (number of planes, color depth, chroma subsampling, ...) are scattered across different helper functions in the DRM core. Callers of those functions often need to access more than a single parameter of the format, leading to inefficiencies due to multiple lookups. Centralize all format information in a data structure and create a function to look up information based on the format 4CC. Signed-off-by:
-
Arnd Bergmann authored
gcc warns about the timestamp in drm_wait_vblank being possibly used without an initialization: drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event': drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized] This can happen if drm_vblank_count_and_time() returns 0 in its error path. To sanitize the error case, I'm changing that function to return a zero timestamp when it fails. Fixes: e6ae8687 ("drm: idiot-proof vblank") Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
- 17 Oct, 2016 12 commits
-
-
Tomeu Vizoso authored
Adds files and directories to debugfs for controlling and reading frame CRCs, per CRTC: dri/0/crtc-0/crc dri/0/crtc-0/crc/control dri/0/crtc-0/crc/data Drivers can implement the set_crc_source callback() in drm_crtc_funcs to start and stop generating frame CRCs and can add entries to the output by calling drm_crtc_add_crc_entry. v2: - Lots of good fixes suggested by Thierry. - Added documentation. - Changed the debugfs layout. - Moved to allocate the entries circular queue once when frame generation gets enabled for the first time. v3: - Use the control file just to select the source, and start and stop capture when the data file is opened and closed, respectively. - Make variable the number of CRC values per entry, per source. - Allocate entries queue each time we start capturing as now there isn't a fixed number of CRC values per entry. - Store the frame counter in the data file as a 8-digit hex number. - For sources that cannot provide useful frame numbers, place XXXXXXXX in the frame field. v4: - Build only if CONFIG_DEBUG_FS is enabled. - Use memdup_user_nul. - Consolidate calculation of the size of an entry in a helper. - Add 0x prefix to hex numbers in the data file. - Remove unnecessary snprintf and strlen usage in read callback. v5: - Made the crcs array in drm_crtc_crc_entry fixed-size - Lots of other smaller improvements suggested by Emil Velikov v7: - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h v8: - Call debugfs_remove_recursive when we fail to create the minor device v9: - Register the debugfs directory for a crtc from drm_crtc_register_all() v10: - Don't let debugfs failures interrupt CRTC registration (Emil Velikov) v11: - Remove extra brace that broke compilation. Sorry! Signed-off-by:Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Stefan Agner authored
The current fbdev emulation does not allow to push back changes in width, height or depth to KMS, hence reject any changes with an error. This makes sure that fbdev ioctl's fail properly and user space does not assume that changes succeeded. Signed-off-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
-
Chris Wilson authored
Now that we have the name "block" free once more, we can use it to point to the start of a block within the edid. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
The "block" variable points to the entire edid, not individual blocks despite it being named such. Signed-off-by:
-
Shashank Sharma authored
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. V2: Rebase V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride) V4: Added r-b from Jose. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Shashank Sharma authored
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds enumeration for the new aspect ratios in the existing aspect ratio list. V2: rebase V3: rebase V4: Added r-b from Jose, Ack by Tomi Signed-off-by:
-
Shashank Sharma authored
Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). V2: Addressed review comments from Sean: - Fix spellings/typo - No need to handle aspect ratio none - Add a break, for default case too V3: Rebase V4: Added r-b from Jose Signed-off-by:
Lin, Jia <lin.a.jia@intel.com> Signed-off-by:
Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
-
Shashank Sharma authored
This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. V2: Addressed review comments from Sean - Changed PAR-> PIC_AR V3: Rebase V3: Added r-b by Jose Signed-off-by:
-
Dmitry Vyukov authored
Size of kmalloc() in vga_arb_write() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Allocate the buffer on stack to avoid the WARNING. The string must be small (e.g "target PCI:domain:bus:dev.fn"). Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: syzkaller@googlegroups.com Signed-off-by:
-
Chris Wilson authored
drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more beneficial when the lifetime of the state becomes more convoluted than being passed to a single worker thread for the commit. v2: Double check !intel atomic_commit functions for missing gets v3: Update kerneldocs Signed-off-by:
-
Maarten Lankhorst authored
Now that drm_crtc_index takes a const, the same can be done for drm_crtc_mask. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Brian Starkey authored
Add some additional comments to more explicitly describe the meaning and usage of the three CRTC modeset detection booleans: mode_changed, connectors_changed and active_changed. Suggested-by:
Brian Starkey <brian.starkey@arm.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 13 Oct, 2016 4 commits
-
-
Dan Carpenter authored
A recent cleanup changed the kmalloc() + copy_from_user() to memdup_user() but the error handling wasn't updated so we might call kfree(-EFAULT) and crash. Fixes: a6e3918b ('GPU-DRM-Savage: Use memdup_user() rather than duplicating') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jiang Biao authored
Added comments for new parameters. Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
-
Jiang Biao authored
Remove useless comment in framebuffer.c. Signed-off-by:
-
Shyam Saini authored
Replace explicit computation of vma page count by a call to vma_pages() Signed-off-by:
Shyam Saini <mayhs11saini@gmail.com> Signed-off-by:
-
- 12 Oct, 2016 8 commits
-
-
Chris Wilson authored
In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical section does not prevent this reallocation, instead we have to inspect the reservation's seqlock to double check if the fences have been reassigned as we were acquiring our reference. Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/20160829070834.22296-9-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical section does not prevent this reallocation, instead we have to inspect the reservation's seqlock to double check if the fences have been reassigned as we were acquiring our reference. Signed-off-by:
-
Chris Wilson authored
In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical section does not prevent this reallocation, instead we have to inspect the reservation's seqlock to double check if the fences have been reassigned as we were acquiring our reference. Signed-off-by:
-
Chris Wilson authored
This variant of fence_get_rcu() takes an RCU protected pointer to a fence and carefully returns a reference to the fence ensuring that it is not reallocated as it does. This is required when mixing fences and SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm Signed-off-by:
-
Chris Wilson authored
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
-
Chris Wilson authored
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by:
-
Chris Wilson authored
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Chris Wilson authored
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by:
-
- 10 Oct, 2016 7 commits
-
-
Jani Nikula authored
Signed-off-by:
-
Grazvydas Ignotas authored
There is no late_unregister(), it looks like the comment meant late_register(). Also fix a typo while at it. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing resources allocated with 'ida_simple_get()'. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Chris Wilson authored
I hit send before completing a make htmldoc, and lo I forgot to fix up the cut'n'paste. Fixes: a4fce9cb ("drm/prime: Take a ref on the drm_dev when exporting...") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Marek Vasut authored
Drop unneeded drm_connector_unregister() and remove the unnecessary wrapper functions around drm_connector_cleanup(). Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Stefan Christ authored
Fix invalid sphinx markup in the comment for the newly added DRM_FB_HELPER_DEFAULT_OPS. Signed-off-by:
Stefan Christ <contact@stefanchrist.eu> Signed-off-by:
-
Maxime Ripard authored
Some boards have an entirely passive RGB to VGA bridge, based on DACs implemented by resistor ladders. Those might or might not have an i2c bus routed to the VGA connector in order to access the screen EDIDs. Add a bridge that doesn't do anything but expose the modes available on the screen, either based on the EDIDs if available, or based on the XGA standards. Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
