summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-30drm/i915: Make utility pin asserts more accurateVille Syrjälä
Only the PWM output mode of the utility pin is incompatible with DC6/LCPLL disable. Check for that specifically. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6609 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328164938.8193-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-03-30dt-bindings: display: seiko,43wvf1g: Change the maintainer's contactFabio Estevam
Marco's NXP email is no longer valid. Marco told me offline that he has no interest to be listed as the maintainer contact for this binding, so add my contact. Signed-off-by: Fabio Estevam <festevam@denx.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230329201150.741106-1-festevam@gmail.com
2023-03-30Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst
Backmerge to get rc4. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2023-03-29dt-bindings: display: boe,tv101wum-nl6: document rotationKrzysztof Kozlowski
Allow 'rotation' property (coming from panel-common.yaml) already used in DTS: sc7180-trogdor-quackingstick-r0.dtb: panel@0: 'rotation' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-6-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29dt-bindings: display: visionox,rm69299: document regKrzysztof Kozlowski
Panels are supposed to have one reg. This fixes dtbs_check warnings like: sc7180-idp.dtb: panel@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-5-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29dt-bindings: display: panel-simple-dsi: document portKrzysztof Kozlowski
Panels are supposed to have one port (coming from panel-common.yaml binding): msm8916-samsung-a3u-eur.dtb: panel@0: 'port' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-4-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29dt-bindings: display: panel-simple-dsi: allow vddio variantKrzysztof Kozlowski
Few panels like Samsung s6e3fc2x01 and sofef00 use vddio-supply instead of power-supply (in DTS and Linux driver), so allow it to fix: sdm845-oneplus-enchilada.dtb: panel@0: 'power-supply' is a required property Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-3-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29dt-bindings: display: novatek,nt36672a: correct VDDIO supplyKrzysztof Kozlowski
The nt36672a bindings were added with a mistake on VDDIO supply calling it in one place vddio and in other vddi0. Typical name is rather vddio which is also now used by DTS (sdm845-xiaomi-beryllium-common.dtsi) and Linux driver. Fixes: c2abcf30efb8 ("dt-bindings: display: novatek,nt36672a: Fix unevaluated properties warning") Fixes: 9528a02430df ("dt-bindings: display: panel: Add bindings for Novatek nt36672a") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-2-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29dt-bindings: display: panel-simple: merge Innolux p120zdg-bf1Krzysztof Kozlowski
There is nothing special in Innolux p120zdg-bf1 panel, so just like other Innolux panels it can be made part of panel-simple. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-29Merge v6.3-rc4 into drm-nextDaniel Vetter
I just landed the fence deadline PR from Rob that a bunch of drivers want/need to apply driver-specific patches. Backmerge -rc4 so that they don't have to be stuck on -rc2 for no reason at all. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-03-29Merge tag 'dma-fence-deadline' of https://gitlab.freedesktop.org/drm/msm ↵Daniel Vetter
into drm-next This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers See https://patchwork.freedesktop.org/series/93035/ This does not yet add any UAPI, although this will be needed in a number of cases: 1) Workloads "ping-ponging" between CPU and GPU, where we don't want the GPU freq governor to interpret time stalled waiting for GPU as "idle" time 2) Cases where the compositor is waiting for fences to be signaled before issuing the atomic ioctl, for example to maintain 60fps cursor updates even when the GPU is not able to maintain that framerate. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGt5nDQpa6J86V1oFKPA30YcJzPhAVpmF7N1K1g2N3c=Zg@mail.gmail.com
2023-03-29drm/i915: fix race condition UAF in i915_perf_add_config_ioctlMin Li
Userspace can guess the id value and try to race oa_config object creation with config remove, resulting in a use-after-free if we dereference the object after unlocking the metrics_lock. For that reason, unlocking the metrics_lock must be done after we are done dereferencing the object. Signed-off-by: Min Li <lm0963hack@gmail.com> Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG interface") Cc: <stable@vger.kernel.org> # v4.14+ Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328093627.5067-1-lm0963hack@gmail.com [tursulin: Manually added stable tag.]
2023-03-29drm/i915: Use compressed bpp when calculating m/n value for DP MST DSCStanislav Lisovskiy
For obvious reasons, we use compressed bpp instead of pipe bpp for DSC DP SST case. Lets be consistent and use compressed bpp instead of pipe bpp, also in DP MST DSC case. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path") Link: https://patchwork.freedesktop.org/patch/msgid/20230327064217.24033-1-stanislav.lisovskiy@intel.com
2023-03-28drm/atomic-helper: Set fence deadline for vblankRob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate the next vblank time, and inform the fence(s) of that deadline. v2: Comment typo fix (danvet) v3: If there are multiple CRTCs, consider the time of the soonest vblank Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-03-28drm/vblank: Add helper to get next vblank timeRob Clark
Will be used in the next commit to set a deadline on fences that an atomic update is waiting on. v2: Calculate time at *start* of vblank period, not end v3: Fix kbuild complaints Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
2023-03-28drm/scheduler: Add fence deadline supportRob Clark
As the finished fence is the one that is exposed to userspace, and therefore the one that other operations, like atomic update, would block on, we need to propagate the deadline from from the finished fence to the actual hw fence. v2: Split into drm_sched_fence_set_parent() (ckoenig) v3: Ensure a thread calling drm_sched_fence_set_deadline_finished() sees fence->parent set before drm_sched_fence_set_parent() does this test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT). Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Luben Tuikov <luben.tuikov@amd.com>
2023-03-28dma-buf/sync_file: Surface sync-file uABIRob Clark
We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as otherwise the comments for the ioctl nr defines would not show up. v2: Fix docs build warning coming from newly including the uabi header in the docs build Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2023-03-28dma-buf/dma-resv: Add a way to set fence deadlineRob Clark
Add a way to set a deadline on remaining resv fences according to the requested usage. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com>
2023-03-28dma-buf/fence-chain: Add fence deadline supportRob Clark
Propagate the deadline to all the fences in the chain. v2: Use dma_fence_chain_contained [Tvrtko] Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com>
2023-03-28drm: Use of_property_present() for testing DT property presenceRob Herring
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Liu Ying <victor.liu@nxp.com> # i.MX bridge Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230310144705.1542207-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-03-28drm/i915/gsc: implement wa 14015076503Daniele Ceraolo Spurio
The WA states that we need to alert the GSC FW before doing a GSC engine reset and then wait for 200ms. The GuC owns engine reset, so on the i915 side we only need to apply this for full GT reset. Given that we do full GT resets in the resume paths to cleanup the HW state and that a long wait in those scenarios would not be acceptable, a faster path has been introduced where, if the GSC is idle, we try first to individually reset the GuC and all engines except the GSC and only fall back to full reset if that fails. Note: according to the WA specs, if the GSC is idle it should be possible to only wait for the uC wakeup time (~15ms) instead of the whole 200ms. However, the GSC FW team have mentioned that the wakeup time can change based on other things going on in the HW and pcode, so a good security margin would be required. Given that when the GSC is idle we already skip the wait & reset entirely and that this reduced wait would still likely be too long to use in resume paths, it's not worth adding support for this reduced wait. v2: add comment to explain why it is safe to skip the GSC reset (John) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323231857.2194435-2-daniele.ceraolospurio@intel.com
2023-03-28drm/i915: limit double GT reset to pre-MTLDaniele Ceraolo Spurio
Commit 3db9d590557d ("drm/i915/gt: Reset twice") modified the code to always hit the GDRST register twice when doing a reset, with the reported aim to fix invalid post-reset engine state on some platforms (Jasperlake being the only one actually mentioned). This is a problem on MTL, due to the fact that we have to apply a time consuming WA (coming in the next patch) every time we hit the GDRST register in a way that can include the GSC engine. Even post MTL, the expectation is that we'll have some work to do before and after hitting the GDRST if the GSC is involved. Since the issue requiring the double reset seems to be limited to older platforms, instead of trying to handle the double-reset on MTL and future platforms it is just easier to turn it off. The default on MTL is also for GuC to own engine reset, with i915 only covering full-GT reset. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323231857.2194435-1-daniele.ceraolospurio@intel.com
2023-03-28drm/i915/huc: Cancel HuC delayed load timer on reset.Daniele Ceraolo Spurio
In the rare case where we do a full GT reset after starting the HuC load and before it completes (which basically boils down to i915 hanging during init), we need to cancel the delayed load fence, as it will be re-initialized in the post-reset recovery. Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230313205556.1174503-1-daniele.ceraolospurio@intel.com
2023-03-28Merge tag 'exynos-drm-next-for-v6.4' of ↵Daniel Vetter
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next A patch series for moving MIPI-DSI driver for Exynos DRM to drm/bridge directory so that I.MX SoC family can also share the same device driver. Samsung MIPI DSIM device is a common IP that can be used by Exynos and I.MX8M Mini/Nano/Plus SoC. Regarding this, this patch series has added several things below to existing MIPI DSI driver, - Add exynos_dsi_type enum type to provide controller data from different platforms. - Add two pipeline detection ways support - existing Exynos DSI child node and I.MX family of-graph port or ports. - Consider component and bridged based DRM drivers. - Add device tree binding support of I.MX family. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328040524.49278-1-inki.dae@samsung.com
2023-03-28drm/i915: remove unused config DRM_I915_UNSTABLEJani Nikula
Essentially this is a revert of commit d9d54a530a70 ("drm/i915: Put future HW and their uAPIs under STAGING & BROKEN"). We currently have no users for this config option. The last one was removed in commit 8c26491f5853 ("drm/i915: Kill the fake lmem support"). Drop it altogether; it's easy enough to resurrect if need arises. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327105330.312131-2-jani.nikula@intel.com
2023-03-28Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Catch up with 6.3-rc cycle... Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-03-28drm/i915: Check for unreliable MMIO during forcewakeMatt Roper
Although we now sanitycheck MMIO access during driver load to make sure the MMIO BAR isn't returning all 0xFFFFFFFF, there have been a few cases where (temporarily?) unreliable MMIO access has happened after GPU resets or power events. We'll often notice this on our next GT register access since forcewake handling will fail; let's change our handling slightly so that when this happens we print a more meaningful message clarifying that the problem is the MMIO access, not forcewake specifically. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327195547.356584-3-andi.shyti@linux.intel.com
2023-03-28drm/i915: Sanitycheck MMIO access early in driver loadMatt Roper
We occasionally see the PCI device in a non-accessible state at the point the driver is loaded. When this happens, all BAR accesses will read back as 0xFFFFFFFF. Rather than reading registers and misinterpreting their (invalid) values, let's specifically check for 0xFFFFFFFF in a register that cannot have that value to see if the device is accessible. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327195547.356584-2-andi.shyti@linux.intel.com
2023-03-28drm/i915/ips: Add i915_ips_false_color debugfs fileVille Syrjälä
Similar to FBC let's expose an debugfs file to control IPS false color. Enabling this provides an immediate visual feedback on whether IPS is working or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327133942.22063-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-03-28drm/i915/ips: Make IPS debugfs per-crtcVille Syrjälä
IPS is a per-pipe feature, so let's move the debugfs stuff under the crtc directory, and only register it when IPS is actually available. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327133942.22063-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-03-28drm: bridge: samsung-dsim: Add i.MX8M Plus supportMarek Vasut
Add extras to support i.MX8M Plus. The main change is the removal of HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise the implementation of this IP in i.MX8M Plus is very much compatible with the i.MX8M Mini/Nano one. Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <m.szyprowski@samsung.com>
2023-03-28dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus supportJagan Teki
Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC. Add dt-bingings for it. Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano supportJagan Teki
Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC. Add compatible and associated driver_data for it. Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Adam Ford <aford173@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano supportJagan Teki
Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC. Add dt-bingings for it. Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridgeJagan Teki
Samsung MIPI DSIM controller is common DSI IP that can be used in various SoCs like Exynos, i.MX8M Mini/Nano. In order to access this DSI controller between various platform SoCs, the ideal way to incorporate this in the drm stack is via the drm bridge driver. We already have a consolidated code for supporting component and bridge based DRM drivers, so keep the exynos component based code in existing exynos_drm_dsi.c and move generic bridge code as part of samsung-dsim.c Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Add host helper for te_irq_handlerJagan Teki
IRQ handler for te-gpio seems to be common across DSIM host. However, Exynos is handling this via CRTC drivers but there is no clear evidence on how the same has been handled in i.MX8MM. Keeping the handler as-it-is can be a viable option but adding DSIM bridge core in upcoming patches is not possible to call Exynos CRTC handler as DSIM bridge has to be common across DRM bridge core instead of platform specific DRM drivers like Exynos here. So, this patch handles the handler via platform host helper, so-that handling platform specific hook across Exynos and generic can be reasonable till it makes it generic across all platforms. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Consolidate component and bridgeJagan Teki
DSI host registration, attach and detach operations are quite different for the component and bridge-based DRM drivers. Supporting generic bridge driver to use both component and bridge based DRM drivers can be tricky and would require additional host related operation hooks. Add host operation hooks for registering and unregistering Exynos and generic drivers, where Exynos hooks are used in existing Exynos component based DRM drivers and generic hooks are used in i.MX8M bridge based DRM drivers. Add host attach and detach operation hooks for Exynos component DRM drivers and those get invoked while DSI core host attach and detach gets called. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Add atomic_get_input_bus_fmtsJagan Teki
Finding the right input bus format throughout the pipeline is hard so add atomic_get_input_bus_fmts callback and initialize with the proper input format from list of supported output formats. This format can be used in pipeline for negotiating bus format between the DSI-end of this bridge and the other component closer to pipeline components. List of Pixel formats are taken from, AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 3.7.4 Pixel formats Table 14. DSI pixel packing formats Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Add input_bus_flagsJagan Teki
LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting the i.MX8M Mini/Nano DSI host to add additional Data Enable signal active low (DE_LOW). This makes the valid data transfer on each horizontal line. So, add additional bus flags DE_LOW setting via input_bus_flags for i.MX8M Mini/Nano platforms. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Suggested-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Add atomic checkJagan Teki
Look like an explicit fixing up of mode_flags is required for DSIM IP present in i.MX8M Mini/Nano SoCs. At least the LCDIF + DSIM needs active low sync polarities in order to correlate the correct sync flags of the surrounding components in the chain to make sure the whole pipeline can work properly. On the other hand the i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 says. "13.6.3.5.2 RGB interface Vsync, Hsync, and VDEN are active high signals." i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020 3.6.3.5.2 RGB interface i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022 13.6.2.7.2 RGB interface both claim "Vsync, Hsync, and VDEN are active high signals.", the LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW. No clear evidence about whether it can be documentation issues or something, so added proper comments on the code. Comments are suggested by Marek Vasut. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Handle proper host initializationMarek Szyprowski
Host transfer() in the DSI master will invoke only when the DSI commands are sent from DSI devices like DSI Panel or DSI bridges and this host the transfer wouldn't invoke for I2C-based-DSI bridge drivers. Handling DSI host initialization in transfer calls misses the controller setup for I2C configured DSI bridges. This patch updates the DSI host initialization by calling host to init from bridge pre_enable as the bridge pre_enable API is invoked by core as it is common across all classes of DSI device drivers. The host init during pre_enable is conditional and not invoked for Exynos as existing downstream drm panels and bridges in Exynos are expecting the host initialization during DSI transfer. Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Introduce hw_type platform dataJagan Teki
Samsung MIPI DSIM controller is common DSI IP that can be used in various SoCs like Exynos, i.MX8M Mini/Nano/Plus. Add hw_type enum via platform_data so that accessing the different controller data between various platforms becomes easy and meaningful. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Add platform PLL_P (PMS_P) offsetJagan Teki
Look like PLL PMS_P offset value varies between platforms that have Samsung DSIM IP. However, there is no clear evidence for it as both Exynos and i.MX 8M Mini Application Processor Reference Manual is still referring the PMS_P offset as 13. The offset 13 is not working for i.MX8M Mini SoCs but the downstream NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms [1] [2]. PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P() with offset 13 and then an additional offset of one bit added in sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS(). Not sure whether it is reference manual documentation or something else but this patch trusts the downstream code and handle PLL_P offset via platform driver data so-that imx8mm driver data shall use pll_p_offset to 14. Similar to Mini the i.MX8M Nano/Plus also has P=14, unlike Exynos. [1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210 [2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211 Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Mark PHY as optionalJagan Teki
The same Samsung MIPI DSIM master can also be used in NXP's i.MX8M Mini/Nano/Plus SoC. In i.MX8M Mini/Nano/Plus SoC the DSI Phy requires a MIPI DPHY bit to reset in order to activate the PHY and that can be done via upstream i.MX8M blk-ctrl driver. So, mark the phy get as optional. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Lookup OF-graph or Child node devicesJagan Teki
In general, for MIPI DSI there are three ways to represent the pipeline for an upstream bridge to find the connected downstream panel or bridge. 1. Child panel or bridge as a conventional device tree child node. 2. Child panel or bridge as an OF-graph port node. 3. Child panel or bridge as an OF-graph ports node. There are three different downstream panels or bridges that are possible to connect an upstream DSI host bridge - DSI Panel, DSI Bridge, and I2C-Configured DSI bridge. An example of the downstream panel represented as a child node, &dsi { compatible = "samsung,exynos5433-mipi-dsi"; ports { port@0 { reg = <0>; dsi_to_mic: endpoint { remote-endpoint = <&mic_to_dsi>; }; }; }; panel@0 { reg = <0>; }; }; An example of the downstream bridge represented as a port node, &i2c4 { bridge@2c { compatible = "ti,sn65dsi84"; ports { port@0 { reg = <0>; bridge_in_dsi: endpoint { remote-endpoint = <&dsi_out_bridge>; data-lanes = <1 2>; }; }; port@2 { reg = <2>; bridge_out_panel: endpoint { remote-endpoint = <&panel_out_bridge>; }; }; }; }; }; &dsi { compatible = "fsl,imx8mm-mipi-dsim"; port { dsi_in_lcdif: endpoint@0 { reg = <0>; remote-endpoint = <&lcdif_out_dsi>; }; dsi_out_bridge: endpoint@1 { reg = <1>; remote-endpoint = <&bridge_in_dsi>; }; }; }; An example of the downstream bridge represented as a ports node, &dsi { compatible = "fsl,imx8mm-mipi-dsim"; ports { port@0 { reg = <0>; dsi_in_lcdif: endpoint@0 { reg = <0>; remote-endpoint = <&lcdif_out_dsi>; }; }; port@1 { reg = <1>; dsi_out_bridge: endpoint { remote-endpoint = <&bridge_in_dsi>; }; }; }; In, summary it is possible to represent all three downstream slaves devices using OF-graph port or ports node however only DSI Panel and DSI Bridge are possible but not possible to represent I2C-Configured DSI bridge child nodes since I2C-Configure bridges are child of I2C node, not upstream DSI host bridge and it is must represent them endpoint port linking. This indeed means, the OF-graph port or ports representation is mandatory for I2C-Configured DSI bridges. This patch tries to add an OF-graph port or ports representation detection code on top of existing child node detection. It is possible to replace the entire detection code using existing drm_of helper drm_of_find_panel_or_bridge but it will break the Exynos DSI since the pipeline doesn't support OF-graph port or ports node. Overall, this patch has a combination of child and OF-graph pipeline detections in order to support the backward compatibility of Exynos DSI child node and i.MX8M Mini/Nano/Plus OF-graph port or ports node pipelines. This is the first common DSI host bridge driver that needs to support all possible downstream connection pipeline combinations. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-28drm: exynos: dsi: Drop explicit call to bridge detachJagan Teki
Exynos DSI already converted into a bridge driver, so bridge detach will suppose happened during bridge chain removal done by the bridge core. Drop the explicit call chain to detach the bridge. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-03-27drm/panel-edp: Add B133UAN01.0 edp panel entryBjorn Andersson
This panel is found in Lenovo Flex 5G laptop, so add the entry for it Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230324165909.131831-1-vkoul@kernel.org
2023-03-27drm/amd/display: Slightly optimize dm_dmub_outbox1_low_irq()Christophe JAILLET
A kzalloc()+memcpy() can be optimized in a single kmemdup(). This saves a few cycles because some memory doesn't need to be zeroed. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-27drm/amd/display: Remove the unused variable dppclk_delay_subtotalJiapeng Chong
Variable dppclk_delay_subtotal is not effectively used, so delete it. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:1004:15: warning: variable 'dppclk_delay_subtotal' set but not used. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4584 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-27drm/amd/display: Clean up some inconsistent indentingJiapeng Chong
No functional modification involved. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4585 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-11 16:54:16 +0000