- 23 Jan, 2023 7 commits
-
-
Thierry Reding authored
In order to support framebuffers residing in system memory, allow the memory-region property to override the framebuffer memory specification in the "reg" property. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-2-thierry.reding@gmail.com
-
Jani Nikula authored
Realize that drm_edid_connector_update() and _drm_connector_update_edid_property() are now the same thing. Drop the latter. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/712cc299afe33d8f6279a15d5b0117aeeab88bb4.1674144945.git.jani.nikula@intel.com
-
Jani Nikula authored
The original goal with drm_edid_connector_update() was to have a single call for updating the connector and adding probed modes, in this order, but that turned out to be problematic. Drivers that need to update the connector in the .detect() callback would end up updating the probed modes as well. Turns out the callback may be called so many times that the probed mode list fills up without bounds, and this is amplified by add_alternate_cea_modes() duplicating the CEA modes on every call, actually running out of memory on some machines. Kudos to Imre Deak <imre.deak@intel.com> for explaining this to me. Go back to having separate drm_edid_connector_update() and drm_edid_connector_add_modes() calls. The former may be called from .detect(), .force(), or .get_modes(), but the latter only from .get_modes(). Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update the probed modes from the EDID property instead of the passed in EDID. This is mainly to enforce two things: 1) drm_edid_connector_update() must be called before drm_edid_connector_add_modes(). Display info and quirks are needed for parsing the modes, and we don't want to call update_display_info() again to ensure the info is available, like drm_add_edid_modes() does. 2) The same EDID is used for both updating the connector and adding the probed modes. Fortunately, the change is easy, because no driver has actually adopted drm_edid_connector_update(). Not even i915, and that's mainly because of the problem described above. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
By moving update_display_info() out of _drm_edid_connector_update() we make the function purely about adding modes. Rename accordingly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Separate the parsing of display info and modes from the HDMI VSDB. This is prerequisite work for overall better separation of the two parsing steps. The info parsing is about figuring out whether the sink supports HDMI infoframes. Since they were added in HDMI 1.4, assume the sink supports HDMI infoframes if it has the HDMI_Video_present bit set (introduced in HDMI 1.4). For details, see commit f1781e9b ("drm/edid: Allow HDMI infoframe without VIC or S3D"). The logic is not exactly the same, but since it was somewhat heuristic to begin with, assume this is close enough. v2: - Simplify to only check HDMI_Video_present bit (Ville) - Drop cea_db_raw_size() helper (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Liu Ying authored
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through LDB_CTRL and LVDS_CTRL registers. i.MX93 LDB supports only one LVDS channel(channel 0) and it's LVDS_CTRL register bit1 is used as LVDS_EN instead of CH1_EN. Add i.MX93 LDB support in the existing i.MX8mp LDB bridge driver by adding i.MX93 LDB compatible string and device data(to reflect different register offsets and LVDS_CTRL register bit1 definition). Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230123021449.969243-3-victor.liu@nxp.com
-
Liu Ying authored
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through 'ldb' register and 'lvds' register. Also, the 'ldb' clock is required. i.MX93 LDB supports only one LVDS channel(channel 0, a.k.a, LVDS Channel-A in the device tree binding documentation), while i.MX8mp LDB supports at most two. Add i.MX93 LDB device tree binding in the existing i.MX8mp LDB device tree binding documentation. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 22 Jan, 2023 2 commits
-
-
Christophe Branchereau authored
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by:
Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230121162419.284523-3-cbranchereau@gmail.com
-
Paul Cercueil authored
Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by:
-
- 20 Jan, 2023 3 commits
-
-
Jagan Teki authored
HSA/HBP/HFP/HSE mode bits in Processor Reference Manuals specify a naming conversion as 'disable mode bit' due to its bit definition, 0 = Enable and 1 = Disable. For HSE bit, the i.MX 8M Mini/Nano/Plus Applications Processor Reference Manual named this bit as 'HseDisableMode' but the bit definition is quite opposite like 0 = Disables transfer 1 = Enables transfer which clearly states that HSE is not a disable bit. HSE is named as per the manual even though it is not a disable bit however the driver logic for handling HSE is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself. Cc: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by:
-
Jagan Teki authored
HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies 0 = Enable and 1 = Disable. The logic for checking these mode flags was correct before the MIPI_DSI*_NO_* mode flag conversion. This patch is trying to fix this MIPI_DSI*_NO_* mode flags handling Exynos DSI host and update the mode_flags in relevant panel drivers. Fixes: 0f3b68b6 ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features") Reviewed-by:
Nicolas Boichat <drinkcat@chromium.org> Reported-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by:
-
John Stultz authored
I no longer have access to the HiKey boards, so while I'm happy to review code, I wanted to add Sumit and Yongqin to the reviewers list so they would get CC'ed on future changes and would be able to have a chance to validate and provide Tested-by: tags Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Yongqin Liu <yongqin.liu@linaro.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: kernel-team@android.com Cc: dri-devel@lists.freedesktop.org Signed-off-by:
John Stultz <jstultz@google.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230120060956.1244187-1-jstultz@google.com
-
- 19 Jan, 2023 28 commits
-
-
Neil Armstrong authored
Fix the following warning: panel-visionox-vtdr6130.c:249:12: warning: 'ret' is used uninitialized [-Wuninitialized] Fixes: 9402cde9 ("drm/panel: vtdr6130: Use 16-bit brightness function") Reported-by:
Daniel Vetter <daniel@ffwll.ch> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Jani Nikula authored
The BPC quirks are closer to home in update_display_info(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Simplify display info update by merging ELD handling as well as clearing of the data in update_display_info(). The connector->eld really should be moved under display_info altogether, but that's for another time. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Now that quirks are stored in display info, we can just look them up using the connector instead of having to pass them around. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Although the quirks are internal to EDID parsing, it'll be helpful to store them in display info to avoid having to pass them around. This will also help separate adding probed modes (which needs the quirks) from updating display info. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jacek Lawrynowicz authored
- Implement cold and warm firmware boot flows - Add hang recovery support - Add runtime power management support Co-developed-by:
Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230117092723.60441-8-jacek.lawrynowicz@linux.intel.com
-
Jacek Lawrynowicz authored
Each of the user contexts has two command queues, one for compute engine and one for the copy engine. Command queues are allocated and registered in the device when the first job (command buffer) is submitted from the user space to the VPU device. The userspace provides a list of GEM buffer object handles to submit to the VPU, the driver resolves buffer handles, pins physical memory if needed, increments ref count for each buffer and stores pointers to buffer objects in the ivpu_job objects that track jobs submitted to the device. The VPU signals job completion with an asynchronous message that contains the job id passed to firmware when the job was submitted. Currently, the driver supports simple scheduling logic where jobs submitted from user space are immediately pushed to the VPU device command queues. In the future, it will be extended to use hardware base scheduling and/or drm_sched. Co-developed-by:
Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by:
Oded Gabbay <ogabbay@kernel.org> Reviewed-by:
-
Jacek Lawrynowicz authored
Read, parse and boot VPU firmware image. Co-developed-by:
-
Jacek Lawrynowicz authored
The IPC driver is used to send and receive messages to/from firmware running on the VPU. The only supported IPC message format is Job Submission Model (JSM) defined in vpu_jsm_api.h header. Co-developed-by:
-
Jacek Lawrynowicz authored
Adds four types of GEM-based BOs for the VPU: - shmem - internal - prime All types are implemented as struct ivpu_bo, based on struct drm_gem_object. VPU address is allocated when buffer is created except for imported prime buffers that allocate it in BO_INFO IOCTL due to missing file_priv arg in gem_prime_import callback. Internal buffers are pinned on creation, the rest of buffers types can be pinned on demand (in SUBMIT IOCTL). Buffer VPU address, allocated pages and mappings are released when the buffer is destroyed. Eviction mechanism is planned for future versions. Add two new IOCTLs: BO_CREATE, BO_INFO Signed-off-by:
-
Jacek Lawrynowicz authored
VPU Memory Management Unit is based on ARM MMU-600. It allows the creation of multiple virtual address spaces for the device and map noncontinuous host memory (there is no dedicated memory on the VPU). Address space is implemented as a struct ivpu_mmu_context, it has an ID, drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that holds actual 3-level, 4KB page table. Context with ID 0 (global context) is created upon driver initialization and it's mainly used for mapping memory required to execute the firmware. Contexts with non-zero IDs are user contexts allocated each time the devices is open()-ed and they map command buffers and other workload-related memory. Workloads executing in a given contexts have access only to the memory mapped in this context. This patch is has two main files: - ivpu_mmu_context.c handles MMU page tables and memory mapping - ivpu_mmu.c implements a driver that programs the MMU device Co-developed-by:
Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by:
-
Jacek Lawrynowicz authored
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following components: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/accel/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Co-developed-by: -
Thomas Zimmermann authored
Backmerging into drm-misc-next to get DRM accelerator infrastructure, which is required by ipuv driver. Signed-off-by: -
Jani Nikula authored
Add a helper for skipping the HDMI VSDB audio latency fields. There's a functional change for HDMI VSDB blocks that do not respect the spec: "I_Latency_Fields_Present shall be zero if Latency_Fields_Present is zero". We assume this to hold when skipping the latency fields, and ignore non-zero I_Latency_Fields_Present if Latency_Fields_Present is zero. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add helpers for Latency_Fields_Present and I_Latency_Fields_Present bits, and fix the parsing: - Respect specification regarding "I_Latency_Fields_Present shall be zero if Latency_Fields_Present is zero". - Don't claim latency fields are present if the data block isn't big enough to hold them. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Separate the parsing of display info and modes from the CTA Y420VDB. This is prerequisite work for overall better separation of the two parsing steps. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Now that we have pre-parsed CTA VDB VICs stored in info->vics, leverage that to simplify CTA Y420CMDB parsing. Move updating the y420_cmdb_modes bitmap to the display info parsing stage, instead of updating it during add modes. This allows us to drop the intermediate y420_cmdb_map from display info, and replace it with a local variable. This is prerequisite work for overall better separation of the two parsing steps (updating display info and adding modes). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Rename the local variable to info for consistency. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Apparently there are HDMI 1.4 compatible displays out there that support VICs from specs later than CTA-861-D, i.e. VIC > 64, although HDMI 1.4 references CTA-861-D only. We try to avoid using VICs from the later specs in the AVI infoframes to avoid upsetting sinks that conform to earlier specs. However, it seems reasonable to do this when the sink claims it supports the VIC. With the pre-parsed list of VICs handy, this is now trivial. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6153 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
-
Jani Nikula authored
Now that we have all the VICs in info->vics, use them to simplify access based on VIC index, i.e. on the order of VICs in the EDID, and avoid passing CTA VDB pointers around. This also fixes the highly unlikely scenarios of a) multiple HDMI VSDBs, and b) HDMI VSDB 3D modes using VIC indexes that span across multiple CTA VDBs, and the combination of the two. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
A number of places need access to the VICs. Just parse them early for easy access. Gracefully handle multiple CTA VDBs. It's unlikely to have more than one, but the CTA-861 references "Video Data Block(s)", so err on the safe side. Start parsing them now, convert users in follow-up to have fewer moving parts in one go. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Commit 537d9ed2 ("drm/edid: convert add_cea_modes() to use cea db iter") inadvertently moved the do_hdmi_vsdb_modes() call within the db iteration loop, always passing NULL as the CTA VDB to do_hdmi_vsdb_modes(), skipping a lot of stereo modes. Move the call back outside of the loop. This does mean only one CTA VDB and HDMI VSDB combination will be handled, but it's an unlikely scenario to have more than one of either block, and it was not accounted for before the regression either. Fixes: 537d9ed2 ("drm/edid: convert add_cea_modes() to use cea db iter") Cc: <stable@vger.kernel.org> # v6.0+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
We try to avoid sending VICs defined in the later specs in AVI infoframes to sinks that conform to the earlier specs, to not upset them, and use 0 for the VIC instead. However, we do this detection and conversion to 0 too early, as we'll need the actual VIC to figure out the aspect ratio. In particular, for a mode with 64:27 aspect ratio, 0 for VIC fails the AVI infoframe generation altogether with -EINVAL. Separate the VIC lookup from the "filtering", and postpone the filtering, to use the proper VIC for aspect ratio handling, and the 0 VIC for the infoframe video code as needed. Reported-by:
William Tseng <william.tseng@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153 References: https://lore.kernel.org/r/20220920062316.43162-1-william.tseng@intel.com Cc: <stable@vger.kernel.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
The bridge->of_node field is defined inside of an #ifdef, which results in a build failure when compile-testing the vc4_dsi driver without CONFIG_OF: drivers/gpu/drm/vc4/vc4_dsi.c: In function 'vc4_dsi_dev_probe': drivers/gpu/drm/vc4/vc4_dsi.c:1822:20: error: 'struct drm_bridge' has no member named 'of_node' 1822 | dsi->bridge.of_node = dev->of_node; Add another #ifdef in the place it is used in. Alternatively we could consider dropping the #ifdef in the struct definition and all other users. Fixes: 78df6403 ("drm/vc4: dsi: Convert to using a bridge instead of encoder") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230117165258.1979922-1-arnd@kernel.org
-
Randy Dunlap authored
Building the kernel documentation causes this warning 7 times. Fix it by adding a " *" line instead of a blank line. drivers/gpu/drm/drm_connector.c:1849: warning: bad line: Fixes: 7d63cd85 ("drm/connector: Add TV standard property") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> CC: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Randy Dunlap authored
Fix a kernel-doc warning and other kernel-doc formatting for drm_atomic_helper_connect_tv_check(). drivers/gpu/drm/drm_atomic_state_helper.c:560: warning: Cannot understand * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state on line 560 - I thought it was a doc line Fixes: 5a28cefd ("drm/atomic-helper: Add an analog TV atomic_check implementation") Signed-off-by:
-
Alexander Stein authored
The LDB clock needs to be exactly 7-times the pixel clock used by the display. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
-
Biju Das authored
Document RZ/V2L DSI bindings. RZ/V2L MIPI DSI is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-mipi-dsi" will be used as a fallback. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
