- 22 Dec, 2019 1 commit
-
-
Thierry Reding authored
These are just a couple of things that I came across as I was reading through the code and comments. v2: added one more hunk that ended up in the wrong patch Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206135336.2084564-1-thierry.reding@gmail.com
-
- 20 Dec, 2019 1 commit
-
-
Yannick Fertré authored
The pin control must be set to default as soon as possible to establish a good video link between tv & bridge hdmi (encoder mode set is call before encoder enable). Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1574850218-13257-1-git-send-email-yannick.fertre@st.com
-
- 19 Dec, 2019 11 commits
-
-
Daniel Vetter authored
Jani has merged a new set of logging functions, which we hope to be the One True solution now, pinky promises: commit fb6c7ab8 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Dec 10 14:30:43 2019 +0200 drm/print: introduce new struct drm_device based logging macros Update the todo entry to match the new preference. v2: Fix spelling issue Sam noticed. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sean Paul <sean@poorly.run> Cc: Wambui Karuga <wambui.karugax@gmail.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191219161722.2779994-1-daniel.vetter@ffwll.ch
-
Colin Ian King authored
Pointer fb is being dereferenced when assigning dev before it is null checked. Fix this by only dereferencing dev after the null check. Fixes: 6b7ce2c4 ("drm/gma500: Remove struct psb_fbdev") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216162136.270114-1-colin.king@canonical.com
-
Jani Nikula authored
Prefer drm_dbg_kms() and drm_err() over all other logging. Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms(), drm_info(), and drm_err() over all other logging. This is about KMS so switch to the KMS category while at it. Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms() and drm_err() over DRM_DEV_DEBUG_KMS() and DRM_DEV_ERROR(). Reviewed-by:
-
Gurchetan Singh authored
That's the only file that uses it. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-6-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
That's the only file that uses it. Signed-off-by:
-
Gurchetan Singh authored
This is a little simpler. Signed-off-by:
-
Gurchetan Singh authored
Not used anywhere. Signed-off-by:
-
Gurchetan Singh authored
Not used anywhere else. Signed-off-by:
-
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:
-
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: -
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 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:
-
- 16 Dec, 2019 3 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:
-
