Hi Lucas,
Thanks your comments,
> -Original Message-
> From: Lucas Stach
> Sent: 2022年12月9日 19:30
> To: Sandor Yu ; andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; robert.f...@linaro.org;
> laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> jernej.skra...@gmail.com; airl...@gmai
Hi Jagan,
On 09.12.2022 16:23, Jagan Teki wrote:
> The existing drm panels and bridges in Exynos required host
> initialization during the first DSI command transfer even though
> the initialization was done before.
>
> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
> flag and
On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 09.12.2022 16:23, Jagan Teki wrote:
> > The existing drm panels and bridges in Exynos required host
> > initialization during the first DSI command transfer even though
> > the initialization was done before.
> >
> > This
On Mon, Dec 12, 2022 at 12:16:04AM +0200, david.keisars...@mail.huji.ac.il
wrote:
> From: David
>
> Since the two functions
> prandom_byte_state and prandom_u32_state
> use the weak prng prandom_u32,
> we added the prefix predictable_rng,
> to their signatures so it is clear they are weak.
2022년 12월 12일 (월) 오전 3:18, Fabio Estevam 님이 작성:
>
> On Sun, Dec 11, 2022 at 3:02 PM Kang Minchul wrote:
> >
> > Function dev_err() is redundant because platform_get_irq()
> > already prints an error.
> >
> > Signed-off-by: Kang Minchul
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 1 -
> >
Function dev_err() is redundant because platform_get_irq()
already prints an error.
Signed-off-by: Kang Minchul
---
Changes in v2:
- Removed unnecessary braces.
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv
From: David
Since the two functions
prandom_byte_state and prandom_u32_state
use the weak prng prandom_u32,
we added the prefix predictable_rng,
to their signatures so it is clear they are weak.
Signed-off-by: David
---
arch/x86/mm/kaslr.c | 2 +-
.../gpu/drm/i91
On Mon, Dec 12, 2022 at 11:53:09AM +0800, Jiapeng Chong wrote:
> The function port_cfg_force_flow_ctrl() is defined in the ksz884x.c file,
> but not called elsewhere, so remove this unused function.
>
> drivers/net/ethernet/micrel/ksz884x.c:2212:20: warning: unused function
> 'port_cfg_force_flow
On 12.12.2022 09:32, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
> wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> The existing drm panels and bridges in Exynos required host
>>> initialization during the first DSI command transfer even though
>>> th
Hi Jagan,
On 09.12.2022 16:23, Jagan Teki wrote:
> 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.
>
> Fix the MIPI_DSI*_NO_* mode flags handling.
>
> F
On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 09.12.2022 16:23, Jagan Teki wrote:
> > 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_*
On 09.12.22 15:49, Marek Vasut wrote:
> On 12/9/22 14:38, Alexander Stein wrote:
>> Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut:
>>> On 12/9/22 13:21, Alexander Stein wrote:
Hi Marek,
Am Freitag, 9. Dezember 2022, 13:02:10 CET schrieb Marek Vasut:
> On 12/9/22
Add the check for the return value of kmalloc in order to avoid
NULL pointer dereference in copy_from_user.
Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/msm/msm_gem_submit.c | 4
1 file changed, 4 insertio
> -Original Message-
> From: Intel-gfx On Behalf Of
> Andrzej Hajda
> Sent: Friday, December 9, 2022 9:19 PM
> To: linux-ker...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: Hajda, Andrzej ; Arnd Bergmann
> ; Vivi, Rodrigo ; Andrew Morton
> ;
On Sat, 10 Dec 2022, Alexey Lukyanchuk wrote:
> Dell wyse 3040 cat't poweroff aftet kernel 5.11.
> It happens because i915_driver_shutdown function.
> Disabling of this function mitigate this problem.
>
> Fixes: 440b354f3 ("drivers/gpu/drm:power off troubles on dell wyse 3040")
Fixes: is suppos
On 12/12/2022 10:09, Frieder Schrempf wrote:
This does seem like a hardware bug right there, can you double-check
this with the hardware engineer ?
>>>
>>> Yep, checked with hardware engineer. An 470nF is attached, together
>>> with an
>>> open drain output and only the internal pull-up.
On 12.12.2022 10:14, Upadhyay, Tejas wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Andrzej Hajda
Sent: Friday, December 9, 2022 9:19 PM
To: linux-ker...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
de...@lists.freedesktop.org
Cc: Hajda, Andrzej ; Arnd Bergmann
; V
On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote:
> On 09.12.22 15:49, Marek Vasut wrote:
> > On 12/9/22 14:38, Alexander Stein wrote:
> >> Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut:
> >>> On 12/9/22 13:21, Alexander Stein wrote:
> Am Freitag, 9. Dezember 2
Add bindings for the display hardware on SM8150.
Signed-off-by: Konrad Dybcio
---
.../bindings/display/msm/qcom,sm8150-dpu.yaml | 92 +
.../display/msm/qcom,sm8150-mdss.yaml | 330 ++
2 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bi
Years after the SoC support has been added, it's high time for it to
get dispcc going. Add the node to ensure that.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm815
Add required nodes for MDSS and hook up provided clocks in DISPCC.
This setup is almost identical to 8[23]50.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 271 ++-
1 file changed, 267 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/d
On Sun, Dec 11, 2022 at 11:36 PM Marek Vasut wrote:
>
> On 12/11/22 06:42, Jagan Teki wrote:
> > On Sun, Dec 11, 2022 at 7:58 AM Marek Vasut wrote:
> >>
> >> On 12/9/22 16:23, Jagan Teki wrote:
> >>> The child devices in MIPI DSI can be binding with OF-graph
> >>> and also via child nodes.
> >>>
From: Andrzej Hajda
> Sent: 09 December 2022 15:49
>
> The pattern of setting variable with new value and returning old
> one is very common in kernel. Usually atomicity of the operation
> is not required, so xchg seems to be suboptimal and confusing in
> such cases. Since name xchg is already in
On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
wrote:
>Years after the SoC support has been added, it's high time for it to
>get dispcc going. Add the node to ensure that.
>
>Signed-off-by: Konrad Dybcio
>---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
> 1 fi
On 2022-12-12 10:33:13, Konrad Dybcio wrote:
> Years after the SoC support has been added, it's high time for it to
> get dispcc going. Add the node to ensure that.
>
> Signed-off-by: Konrad Dybcio
On Sony Xperia 5:
Tested-by: Marijn Suijten
Reviewed-by: Marijn Suijten
> ---
> arch/arm64/boo
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm
On 12.12.2022 11:18, Dmitry Baryshkov wrote:
>
>
> On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
> wrote:
>> Years after the SoC support has been added, it's high time for it to
>> get dispcc going. Add the node to ensure that.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> arch/arm64
On 2022-12-12 10:33:14, Konrad Dybcio wrote:
> Add required nodes for MDSS and hook up provided clocks in DISPCC.
> This setup is almost identical to 8[23]50.
>
> Signed-off-by: Konrad Dybcio
Reviewed-by: Marijn Suijten
On Sony Xperia 5:
Tested-by: Marijn Suijten
Note that this device uses
On 12 December 2022 13:23:50 GMT+03:00, Konrad Dybcio
wrote:
>
>
>On 12.12.2022 11:18, Dmitry Baryshkov wrote:
>>
>>
>> On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
>> wrote:
>>> Years after the SoC support has been added, it's high time for it to
>>> get dispcc going. Add the nod
Am 12.12.22 um 04:00 schrieb Tomasz Figa:
[SNIP]
What we could do is to force all exporters to use begin/end_cpu_access()
even on it's own buffers and look at all the importers when the access
is completed. But that would increase the complexity of the handling in
the exporter.
I feel like they
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
> On 12/6/22 06:30, Rijo Thomas wrote:
>> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
>> ring buffer address sent by host to ASP must be a real physical
>> address and the pages must be physically contiguous.
>>
>> In a virtual
>-Original Message-
>From: Marijn Suijten
>Sent: Wednesday, December 7, 2022 7:39 PM
>To: Kalyan Thota (QUIC)
>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org; robdcl...@chr
On 12.12.22 10:32, Laurent Pinchart wrote:
> On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote:
>> On 09.12.22 15:49, Marek Vasut wrote:
>>> On 12/9/22 14:38, Alexander Stein wrote:
Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut:
> On 12/9/22 13:21, Alexander
On Mon, Dec 12, 2022 at 12:49:26PM +0100, Frieder Schrempf wrote:
> On 12.12.22 10:32, Laurent Pinchart wrote:
> > On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote:
> >> On 09.12.22 15:49, Marek Vasut wrote:
> >>> On 12/9/22 14:38, Alexander Stein wrote:
> Am Freitag, 9. Dezemb
On 12.12.22 10:23, Krzysztof Kozlowski wrote:
> On 12/12/2022 10:09, Frieder Schrempf wrote:
> This does seem like a hardware bug right there, can you double-check
> this with the hardware engineer ?
Yep, checked with hardware engineer. An 470nF is attached, together
with an
On 12/12/22 13:29, Frieder Schrempf wrote:
On 12.12.22 10:23, Krzysztof Kozlowski wrote:
On 12/12/2022 10:09, Frieder Schrempf wrote:
This does seem like a hardware bug right there, can you double-check
this with the hardware engineer ?
Yep, checked with hardware engineer. An 470nF is attache
On 12.12.2022 10:03, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
> wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
>>> 0 = Enable and 1 = Disable.
>>>
>>> The logic for checking these mode fla
On Mon, Dec 12, 2022 at 7:51 PM Marek Szyprowski
wrote:
>
> On 12.12.2022 10:03, Jagan Teki wrote:
> > On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
> > wrote:
> >> Hi Jagan,
> >>
> >> On 09.12.2022 16:23, Jagan Teki wrote:
> >>> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> >>
Please CC me on future revisions.
As of 6.2, the prandom namespace is *only* for predictable randomness.
There's no need to rename anything. So nack on this patch 1/5.
With regards to the remaining patches in this series, if you want to
move prandom_u32_state callers over to get_random_bytes() an
Split the Exynos DSI bridge chain update patches from Samsung DSIM
bridge driver for easy to apply.
Changes for v10:
- collect Marek.V Review tag
Any inputs?
Jagan.
Jagan Teki (1):
drm: panel: Enable prepare_prev_first flag for samsung-s6e panels
Marek Szyprowski (2):
drm/bridge: tc358764:
Enable the drm panel prepare_prev_first flag so-that the previous
controller should be prepared first before the prepare for the
panel is called.
samsung-s6e3ha2, samsung-s6e63j0x03 and samsung-s6e8aa0 are the
effected samsung-s6e panels for this change.
This makes sure that the previous co
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
Reviewed-by: Marek Vasut
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Change
From: Marek Szyprowski
Enable the drm bridge pre_enable_prev_first flag so that the
previous bridge pre_enable should be called first before the
pre_enable for the tc358764 bridge is called.
This makes sure that the previous bridge should be initialized
properly before the tc358764 bridge is pow
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 i
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
definitio
On 09.12.2022 16:23, Jagan Teki wrote:
> From: Marek Szyprowski
>
> Restore the proper bridge chain by finding the previous bridge
> in the chain instead of passing NULL.
>
> This establishes a proper bridge chain while attaching downstream
> bridges.
>
> v9, v4:
> * none
>
> v3:
> * new patch
>
>
On 12.12.2022 09:43, Marek Szyprowski wrote:
> On 12.12.2022 09:32, Jagan Teki wrote:
>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>> wrote:
>>> Hi Jagan,
>>>
>>> On 09.12.2022 16:23, Jagan Teki wrote:
The existing drm panels and bridges in Exynos required host
initialization duri
Hi Jagan,
On 09.12.2022 16:23, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
Well, I think I've managed to fix the remaining bits to keep it
On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
wrote:
>
> On 12.12.2022 09:43, Marek Szyprowski wrote:
> > On 12.12.2022 09:32, Jagan Teki wrote:
> >> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
> >> wrote:
> >>> Hi Jagan,
> >>>
> >>> On 09.12.2022 16:23, Jagan Teki wrote:
> The exist
On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote:
>
> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote:
> >
> > On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
> > > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote:
> > > >
> > > > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Han
On 12/12/22 05:21, Rijo Thomas wrote:
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
On 12/6/22 06:30, Rijo Thomas wrote:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically co
From: Chris Wilson
After applying an engine reset, on some platforms like Jasperlake, we
occasionally detect that the engine state is not cleared until shortly
after the resume. As we try to resume the engine with volatile internal
state, the first request fails with a spurious CS event (it looks
On Mon, Dec 12, 2022 at 11:20:12AM +0800, Jiapeng Chong wrote:
> No functional modification involved.
>
> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning: expecting
> prototype for intel_guc_hwconfig_init(). Prototype was for
> guc_hwconfig_init() instead.
>
> Link: https://bugzill
On 12/9/22 17:00, Sung Joon Kim wrote:
> The missing DPCD defintions from DP2.0 spec is as follows:
>
> DOWNSPREAD_CTRL (107h):
> FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (bit 6)
> For sink devices that support Adaptive-Sync operation
> and Panel Replay
>
> DPRX_FE
On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> From: Chris Wilson
>
> After applying an engine reset, on some platforms like Jasperlake, we
> occasionally detect that the engine state is not cleared until shortly
> after the resume. As we try to resume the engine with volatile inte
On Fri, 9 Dec 2022 11:04:18 +0800, Xin Ji wrote:
> Sometimes kernel may resume back quickly after suspend,
> and DRM not call .mode_set() to re-config
> display timing before calling .atomic_enable(), bridge
> driver with this patch to keep last configure timing.
>
>
Applied, thanks!
Repo: http
On 12/12/2022 9:09 PM, Ulf Hansson wrote:
> On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote:
>> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote:
>>> On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote:
> On Wed, Dec 07, 2022
On 12/9/2022 2:39 AM, Bjorn Andersson wrote:
> On Thu, Dec 08, 2022 at 08:54:39PM +0530, Akhil P Oommen wrote:
>> On 12/7/2022 9:16 PM, Ulf Hansson wrote:
>>> On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen
>>> wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framew
On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
On 09/12/2022 02:22, Kuogee Hsieh wrote:
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and lin
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.
Signed-off-by:
This patchset enables the DP and HDMI infoframe properties
in amdgpu.
The first two patches are not completely related to the rest. The
first patch allows for HDR_OUTPUT_METADATA with EOTFs that are
unknown in the kernel.
The second one prints a connector's max_bpc as part of the atomic
state deb
This is useful to understand the bpc defaults and
support of a driver.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
The EDID of an HDR display defines EOTFs that are supported
by the display and can be set in the HDR metadata infoframe.
Userspace is expected to read the EDID and set an appropriate
HDR_OUTPUT_METADATA.
In drm_parse_hdr_metadata_block the kernel reads the supported
EOTFs from the EDID and stores
The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
makes sense for the infopacket but it's meaningless for the
connector colorspace. or, in otherwise, just means to go with
driver default.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
Signed-off-by: Harry Wen
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c| 1 +
drivers/gpu/drm/drm_connector.c
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc:
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@am
Now that we have the HDMI colorimetry fill the corresponding
AVI infoframe info. Also signal "mode_changed" if colorimetry
changed.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c | 54 -
This allows us to use strongly typed arguments.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
include/drm/display/dr
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dr
This will let us pass kms_hdr.bpc_switch.
I don't see any good reasons why we still need to
limit bpc to 8 bpc and doing so is problematic when
we enable HDR.
If I remember correctly there might have been some
displays out there where the advertised link bandwidth
was not large enough to drive th
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syr
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Seba
We use this by default but if userspace passes this explicitly
we should respect it.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freede
Split the Exynos DSI bridge chain update patches from Samsung DSIM
bridge driver for easy to apply.
Changes for v11:
- enable bridge.pre_enable_prev_first
Changes for v10:
- collect Marek.V Review tag
Any inputs?
Jagan.
Jagan Teki (2):
drm: panel: Enable prepare_prev_first flag for samsung-s6e
Enable the drm panel prepare_prev_first flag so-that the previous
controller should be prepared first before the prepare for the
panel is called.
samsung-s6e3ha2, samsung-s6e63j0x03 and samsung-s6e8aa0 are the
effected samsung-s6e panels for this change.
This makes sure that the previous co
From: Marek Szyprowski
Enable the drm bridge pre_enable_prev_first flag so that the
previous bridge pre_enable should be called first before the
pre_enable for the tc358764 bridge is called.
This makes sure that the previous bridge should be initialized
properly before the tc358764 bridge is pow
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
Reviewed-by: Marek Vasut
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v11:
- add bridge.p
On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh wrote:
>
>
> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
> > On 09/12/2022 02:22, Kuogee Hsieh wrote:
> >>
> >> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
> >>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>
> On 12/8/2022 3:33 PM, Dmitry Barys
Hi Rodrigo,
On Mon, Dec 12, 2022 at 11:55:10AM -0500, Rodrigo Vivi wrote:
> On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> > From: Chris Wilson
> >
> > After applying an engine reset, on some platforms like Jasperlake, we
> > occasionally detect that the engine state is not cleare
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs at specified GPU virtual
addresses on a specified address space (VM). Multiple mappings can map
to the same physical pages of an object (aliasing). These mappings (also
referred to as persiste
Make i915_gem_vm_lookup() function non-static as it will be
used by the vm_bind feature.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h |
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
v4: Return error if I915_TIMELINE_FENCE_WAIT fence flag is set.
Wait for bind to complete iff I915_T
As persistent vmas can be partialled mapped to an object,
remove restriction which require vma resource sg table to
be just pointer to object's sg table.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 3 +--
1 file changed, 1 insertion(+
Do not use i915_vma activeness tracking for persistent vmas.
As persistent vmas are part of working set for each execbuf
submission on that address space (VM), a persistent vma is
active if the VM active. As vm->root_obj->base.resv will be
updated for each submission on that VM, it correctly
repre
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 18 +-
drivers/gpu/drm/i915/gem/i9
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace befor
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
v2: On older platforms ctx->vm is not set, check for it.
In vm_bind call,
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_sw_fence.c | 28 +++
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.
v2: Remove unused I915_VMA_PURGED definition.
v3: Properly handle __i915_vma_unbind_async() case.
Reviewed-by: Matthew Auld
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.
VM private BOs can be o
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling, thus not adding any
additional latency to the submission path.
A list of persistent vmas requiring capture is maintained
instead of
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to dma_resv obj.
v4: Fix bind completion check, use PIN_NOEVICT,
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Abstract out the common execbuf functionalities into a
separate file where possible, thus allowing code sharing.
v2: Use drm_dbg instead of DRM_DEBUG
Reviewed-by: Andi Shyti
Reviewed-by: Matthew Auld
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing. ie., multiple
mappings (at different VA) point to the same
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 513 ++
1 file changed, 39 insertions(+), 474 d
1 - 100 of 123 matches
Mail list logo
