On 12/13/2022 5:54 AM, Konrad Dybcio wrote:
> Add support for matching QFPROM fuse values to get the correct speed bin
> on A640 (SM8150) GPUs.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
msm_hdmi_dev_probe()")
Signed-off-by: Christophe JAILLET
Reviewed-by:
On Tue, Dec 13, 2022 at 10:51:19AM +0800, Jiasheng Jiang wrote:
> Add the check for the return value of dma_alloc_coherent
> in order to avoid NULL pointer dereference.
>
> Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
> Signed-off-by: Jiasheng Jiang
> ---
>
Thanks for this, Harry!
I tested your series with https://github.com/Themaister/Granite +
test-hdr with my KHR_display + HDR Mesa branch and it works great.
The code also looks good -- I was already fairly familiar with it when I
rebased it and debugged things previously. (Hence where my
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://bugzilla.openanolis.cn/show_bug.cgi?id=3414
Reported-by: Abaci Robot
These functions are defined in the ksz884x.c file, but not called
elsewhere, so delete these unused functions.
drivers/net/ethernet/micrel/ksz884x.c:2212:20: warning: unused function
'port_cfg_force_flow_ctrl'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3418
Reported-by: Abaci Robot
Add the check for the return value of dma_alloc_coherent
in order to avoid NULL pointer dereference.
Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
Signed-off-by: Jiasheng Jiang
---
drivers/usb/gadget/udc/aspeed_udc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Tue, Nov 29, 2022 at 01:12:53PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
does (due to unknwon reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system
On Tue, Nov 29, 2022 at 01:12:52PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not
On 12/12/2022 5:34 PM, Abhinav Kumar wrote:
On 12/10/2022 10:50 PM, Christophe JAILLET wrote:
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi:
On 12/10/2022 10:50 PM, Christophe JAILLET wrote:
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
On 13 December 2022 02:41:55 GMT+03:00, Abhinav Kumar
wrote:
>Hi Dmitry
>
>On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
>> 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:
>
Add support for matching QFPROM fuse values to get the correct speed bin
on A650 (SM8250) GPUs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
Add support for matching QFPROM fuse values to get the correct speed bin
on A640 (SM8150) GPUs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/video/fbdev/Kconfig
between commit:
c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers")
from the drm tree and commit:
225e095bbd3a ("fbdev: offb: make offb driver tristate")
from the fbdev
Hi Dmitry
On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
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
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: Niranjana Vishwanathapura
---
Update i915 documentation to include VM_BIND changes
and render all VM_BIND related documentation.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/i915.rst | 78 --
1 file changed, 59 insertions(+), 19 deletions(-)
Only support vm_bind mode with non-recoverable contexts.
With new vm_bind mode with eb3 submission path, we need not
support older recoverable contexts.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
1 file
Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.
v2: update kernel-doc
v3: create vm->root_obj only upon I915_VM_CREATE_FLAGS_USE_VM_BIND
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
Reviewed-by: Matthew
Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.
v2: add documentation
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 8 +---
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.
v2: Fix fence leak
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
v2: Do not double add vma to vm->userptr_invalidated_list
v3: Initialize vma->userptr_invalidated_link
Reviewed-by: Matthew Auld
Signed-off-by:
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
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
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
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
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,
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
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
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
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
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,
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
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 +-
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
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
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
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 |
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
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
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
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
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
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
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
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:
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:
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
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
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:
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 ++-
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
---
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 -
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:
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:
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:
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 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
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:
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
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
---
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
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.
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
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
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 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:
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
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
>
>
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:
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
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
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
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
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
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
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
>
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
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
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
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
---
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
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:
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()
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
>
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
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
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 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.
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,
>-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;
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
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
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
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.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
>> ---
>>
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
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
> ---
>
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
1 - 100 of 123 matches
Mail list logo
