- 19 Dec, 2019 2 commits
-
-
Gurchetan Singh authored
Not used anywhere else. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-2-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
Not used anywhere else. Signed-off-by:
-
- 18 Dec, 2019 11 commits
-
-
Fabrizio Castro authored
At this point in time, compatible string "thine,thc63lvdm83d" is backed by the lvds-codec driver, and the documentation contained in thine,thc63lvdm83d.txt is basically the same as the one contained in lvds-codec.yaml (generic fallback compatible string aside), therefore absorb thine,thc63lvdm83d.txt. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <1573660292-10629-14-git-send-email-fabrizio.castro@bp.renesas.com
-
Fabrizio Castro authored
The DS90CF384A from TI is a transparent LVDS receiver (decoder), and therefore it is compatible with the lvds-codec driver and bindings. Document the ti,ds90cf384a compatible string with the dt-bindings. No driver change required. Signed-off-by:
-
Fabrizio Castro authored
In an effort to repurpose lvds-encoder.c to also serve the function of LVDS decoders, we ended up defining a new "generic" compatible string ("lvds-decoder"), therefore adapt the dt schema to allow for the new compatible string. Signed-off-by: -
Fabrizio Castro authored
The probe function needs to get ahold of the panel device tree node, and it achieves that by using a combination of of_graph_get_port_by_id, of_get_child_by_name, and of_graph_get_remote_port_parent. We can achieve the same goal by replacing those calls with a call to of_graph_get_remote_node these days. Signed-off-by:
-
Fabrizio Castro authored
Add support for transparent LVDS decoders by adding a new compatible string ("lvds-decoder") to the driver. This patch also adds member connector_type to struct lvds_codec, and that's because LVDS decoders have a different connector type from LVDS encoders. We fill this new member up with the data matching the compatible string. Signed-off-by:Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Fabrizio Castro authored
lvds-encoder.c implementation is also suitable for LVDS decoders, not just LVDS encoders. Instead of creating a new driver for addressing support for transparent LVDS decoders, repurpose lvds-encoder.c for the greater good with this patch. This patch only "rebrands" the lvds-encoder.c driver, to make it suitable for hosting LVDS decoders support. The actual support for LVDS decoders will come with a later patch. Signed-off-by:
-
Fabrizio Castro authored
Compatible string "ti,sn75lvds83" is being used by device tree rk3188-bqedison2qc.dts, but it's not documented anywhere, therefore document it within lvds-transmitter.yaml. Signed-off-by:
-
Fabrizio Castro authored
ti,ds90c185.txt documents LVDS encoders using the same driver as the one documented by lvds-transmitter.yaml. Since the properties listed in ti,ds90c185.txt are the same as the ones listed in lvds-transmitter.yaml, absorb the dt-binding into lvds-transmitter.yaml. Signed-off-by:
-
Fabrizio Castro authored
Add documentation for property powerdown-gpios. The property is optional. Signed-off-by:
-
Fabrizio Castro authored
Convert the lvds-transmitter binding to DT schema format using json-schema. Signed-off-by:
-
Gurchetan Singh authored
I'm just going to put Chia's review comment here since it sums the issue rather nicely: "(1) Semantically, a dma-buf is in DMA domain. CPU access from the importer must be surrounded by {begin,end}_cpu_access. This gives the exporter a chance to move the buffer to the CPU domain temporarily. (2) When the exporter itself has other means to do CPU access, it is only reasonable for the exporter to move the buffer to the CPU domain before access, and to the DMA domain after access. The exporter can potentially reuse {begin,end}_cpu_access for that purpose. Because of (1), udmabuf does need to implement the {begin,end}_cpu_access hooks. But "begin" should mean dma_sync_sg_for_cpu and "end" should mean dma_sync_sg_for_device. Because of (2), if userspace wants to continuing accessing through the memfd mapping, it should call udmabuf's {begin,end}_cpu_access to avoid cache issues." Reported-by:Chia-I Wu <olvaffe@gmail.com> Suggested-by:
-
- 17 Dec, 2019 13 commits
-
-
Linus Walleij authored
The video DSI mode had not really been tested. These fixes makes it more likely to work on real hardware: - Put the active width (x width) in the right bits and the VSA (vertical sync active) in the right bits (those were swapped). - Calculate the packet sizes in bytes as in the vendor driver, rather than in bits. Test the calculations agains a spreadsheet and confirmed by debug prints to be reasonable. - Also verified the register values with relative confidence to register dumps from the Samsung GT-I8190 boot loader graphics. We are not identical but not off by far either. - Error out if the current mode and refresh frequency doesn't work out. (In the future we may simply want to scale down the vrefresh.) - Handle negative result in front/back/sync packages and fall back to zero like in the vendor driver. - Put in lots of clarifying comments and references to the documentation where the code is hard to understand. - Set the DSI_VID_VCA_SETTING2 field DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT to blkline_pck - 6 as in the vendor driver and mask the field properly. - Set the DSI_VID_VCA_SETTING1 field DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT to blkeol_pck - 6 to blkeol_duration - 6 as in the vendor driver. Cc: Stephan Gerhold <stephan@gerhold.net> Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE") Link: https://patchwork.freedesktop.org/patch/msgid/20191217150959.17215-1-linus.walleij@linaro.orgReviewed-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Andy Shevchenko authored
The initial commit followed by the fix didn't take into consideration the case: CONFIG_DRM_PANEL=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_DRM_I915=y where symbol devm_of_find_backlight() is not reachable from DRM subsystem. Quick fix is to avoid drm_panel_of_backlight() from exporting in such case. Fixes: 907aa265 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191217140721.42432-1-andriy.shevchenko@linux.intel.com
-
zhong jiang authored
Fix the following sparse warning. drivers/dma-buf/dma-heap.c:109:14: warning: symbol 'dma_heap_ioctl_cmds' was not declared. Should it be static? Acked-by:
Andrew F. Davis <afd@ti.com> Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> [sumits: rebased over IOCTL rename patches] Link: https://patchwork.freedesktop.org/patch/msgid/20191217190822.1969-1-sumit.semwal@linaro.org
-
Colin Ian King authored
The -ENOTTY error return path does not free the allocated kdata as it returns directly. Fix this by returning via the error handling label err. Addresses-Coverity: ("Resource leak") Fixes: c02a81fb ("dma-buf: Add dma-buf heaps framework") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
-
Aditya Pakki authored
In drm_dev_init, parent is checked for NULL via assert after checked in devm_drm_dev_init(). The patch removes the duplicate check and replaces the assertion with WARN_ON. Further, it returns -EINVAL consistent with the usage in devm_drm_dev_init. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191215194345.4679-1-pakki001@umn.edu
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Acked-by:
CK Hu <ck.hu@mediatek.com> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20191213172612.1514842-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Acked-by:
-
Daniel Vetter authored
I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. v2: Fix the lost _interruptible (Michael) Acked-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. Reviewed-by:
Eric Anholt <eric@anholt.net> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. Reviewed-by:
-
Andrew F. Davis authored
The heaps are already in a directory of heaps, adding _heap to a heap name is redundant. This patch is only a name change, no logic is changed. Signed-off-by:
-
Andrew F. Davis authored
This is more consistent with the DMA and DRM frameworks convention. This patch is only a name change, no logic is changed. Signed-off-by:
-
Jani Nikula authored
Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Sean Paul <sean@poorly.run> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
-
- 16 Dec, 2019 14 commits
-
-
Ville Syrjälä authored
We depend on a specific relationship between the VIC number and the index in the CEA mode arrays. Assert that the arrays have the expected size to make sure we've not accidentally left holes in them. v2: Pimp the BUILD_BUG_ON()s v3: Fix typos (Manasi) Cc: Hans Verkuil <hansverk@cisco.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Thomas Anderson <thomasanderson@google.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the cea mode handling is not 100% tied to the single array the dummy VIC 0 mode is pretty much pointles. Throw it out. v2: Rebase Cc: Tom Anderson <thomasanderson@google.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add a second table to the cea modes with VIC >= 193. v2: Improve the comment for cea_modes_*[] to indicate that one should always use cea_mode_for_vic() (Tom) Cc: Hans Verkuil <hansverk@cisco.com> Reviewed-by: -
Ville Syrjälä authored
We're going to need two cea mode tables (one for VICs < 128, another one for VICs >= 193). To that end replace the direct edid_cea_modes[] lookups with a function call. And we'll rename the array to edid_cea_modes_0[] to indicate how it's to be indexed. v2: Fix typos (Tom) Drop the pointless NULL checks in the loops (Tom) Assign when declaring (Tom) Improve the comment for cea_modes_*[] to indicate that one should always use cea_mode_for_vic() (Tom) Cc: Tom Anderson <thomasanderson@google.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: -
Gerd Hoffmann authored
v2: remove shift by src_{x,y}, drm_atomic_helper_damage_merged() handles that for us (Chia-I Wu). Signed-off-by: -
Gerd Hoffmann authored
When the driver submits multiple commands in a row it makes sense to notify the host only after submitting the last one, so the host can process them all at once, with a single vmexit. Add functions to enable/disable notifications to allow that. Use the new functions for primary plane updates. Signed-off-by:
-
Gerd Hoffmann authored
v2: also check src rect (Chia-I Wu). Signed-off-by:
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Signed-off-by:
-
zhengbin authored
Fixes coccicheck warning: drivers/gpu/drm/bochs/bochs_hw.c:258:2-3: Unneeded semicolon Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/1576468459-67216-1-git-send-email-zhengbin13@huawei.comSigned-off-by:
-
Hans de Goede authored
Instead of only setting mode->specified on false on an early exit and leaving e.g. mode->bpp_specified and mode->refresh_specified as is, lets be consistent and just zero out the entire passed in struct at the top of drm_mode_parse_command_line_for_connector() Changes in v3: -Drop "mode->specified = false;" line instead of the "return false;" (oops) This crasher was reported-by: kernel test robot <lkp@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118155134.30468-11-hdegoede@redhat.com
-
Hans de Goede authored
fb_get_options() will return fb_mode_option if no video=<connector-name> argument is present on the kernel commandline, so there is no need to also do this in drm_mode_parse_command_line_for_connector() as our only caller uses fb_get_options() to get the mode_option argument. Changes in v2: -Split out the changes dealing with the initialization of the mode struct into a separate patch Acked-by:
-
Hans de Goede authored
Sometimes we want to override a connector's panel_orientation from the kernel commandline. Either for testing and for special cases, e.g. a kiosk like setup which uses a TV mounted in portrait mode. Users can already specify a "rotate" option through a video= kernel cmdline option. But that only supports 0/180 degrees (see drm_client_modeset TODO) and only works for in kernel modeset clients, not for userspace kms users. The "panel-orientation" connector property OTOH does support 90/270 degrees as it leaves dealing with the rotation up to userspace and this does work for userspace kms clients (at least those which support this property). Changes in v2: -Add missing ':' after @panel_orientation (reported by kbuild test robot) BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83Acked-by:
-
Hans de Goede authored
Some options which can be specified on the commandline, such as margin_right=..., margin_left=..., etc. are applied not only to the specified mode, but to all modes. As such it would be nice if the user can simply say e.g. video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42 This commit refactors drm_mode_parse_command_line_for_connector() to add support for this, and as a nice side effect also cleans up the function a bit. Acked-by:
-
Hans de Goede authored
drm_connector_get_cmdline_mode() calls drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode as mode argument, so anything which we store in the mode arguments gets kept even if we return false. Avoid storing a possibly false-postive bpp/refresh_specified setting in connector->cmdline_mode by moving the setting of these to after successful parsing of the bpp/refresh parts of the video= argument. Acked-by:
-
