This commit fixes logic error in function 'amdgpu_hw_ip_info':
- value 'uvd' might be 'vcn'.
Signed-off-by: Konstantin Meskhidze
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
This patch fixes potential memory leakage and seg fault
in _gpuvm_import_dmabuf() function
Signed-off-by: Konstantin Meskhidze
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
+ .shutdown = mtk_drm_shutdown,
.driver = {
.name = "mediatek-drm",
.pm = _drm_pm_ops,
---
base-commit: 4312098baf37ee17a8350725e6e0d0e8590252d4
change-id: 20221128-mtk-drm-ca6c5ac6b3
From: Stefan Eichenberger
Enable hot plug detection when it is available on the HDMI port.
Without this connecting to a different monitor with incompatible timing
before the 10 seconds poll period will lead to a broken display output.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to
Support dump capture of persistent mappings upon user request.
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h
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
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(-)
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
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
---
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
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,
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
---
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
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
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 +---
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 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
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:
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 +-
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
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
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
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,
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 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
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
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
On 29/11/2022 02:43, Laurent Pinchart wrote:
On Tue, Nov 22, 2022 at 10:50:30AM +0200, Tomi Valkeinen wrote:
On 17/11/2022 17:46, Kieran Bingham wrote:
Quoting Tomi Valkeinen (2022-11-17 12:25:46)
From: Tomi Valkeinen
Add DSI support for r8a779g0. The main differences to r8a779a0 are in
the
On Tue, Nov 29, 2022 at 11:33:15AM +0530, Iddamsetty, Aravind wrote:
On 29-11-2022 11:24, Lucas De Marchi wrote:
On Wed, Nov 23, 2022 at 09:47:03AM +0530, Iddamsetty, Aravind wrote:
On 23-11-2022 05:29, Matt Roper wrote:
On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
On 29-11-2022 11:24, Lucas De Marchi wrote:
> On Wed, Nov 23, 2022 at 09:47:03AM +0530, Iddamsetty, Aravind wrote:
>>
>>
>> On 23-11-2022 05:29, Matt Roper wrote:
>>> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
On XE_LPM+ platforms the media engines are carved out
On Wed, Nov 23, 2022 at 09:47:03AM +0530, Iddamsetty, Aravind wrote:
On 23-11-2022 05:29, Matt Roper wrote:
On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range
Am 2022-11-28 um 22:47 schrieb Konstantin Meskhidze:
This patch fixes potential memory leakage and seg fault
in _gpuvm_import_dmabuf() function
Signed-off-by: Konstantin Meskhidze
Thank you for the patch. I'm adding a Fixes tag and pushing the patch to
amd-staging-drm-next.
Fixes:
On Mon, Nov 28, 2022 at 11:18:00AM -0500, Alex Deucher wrote:
> On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
> wrote:
> >
> > Dear Christian:
> >
> > What is the status of the AMDGPU work for Xen dom0? That was mentioned in
> >
[AMD Official Use Only - General]
Hi Arun,
Thanks for your reply. comments are inline.
发件人: Paneer Selvam, Arunpravin
发送时间: 2022年11月29日 1:09
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
Hi Tomi,
On Wed, Nov 23, 2022 at 08:59:39AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Hi,
>
> These add support for DSI on V4H SoC (r8a779g0) and DP for Whitehawk
> board.
>
> Changes in v2:
> - A few cosmetic changes
> - Increase vspd address range in dts to 0x7000
> - Arrange
Hi Tomi,
Thank you for the patch.
On Wed, Nov 23, 2022 at 08:59:46AM +0200, Tomi Valkeinen wrote:
> Add DSI support for r8a779g0. The main differences to r8a779a0 are in
> the PLL and PHTW setups.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 484
Hi,
On Fri, Nov 25, 2022 at 2:54 AM Qiqi Zhang wrote:
>
> According to the description in ti-sn65dsi86's datasheet:
>
> CHA_HSYNC_POLARITY:
> 0 = Active High Pulse. Synchronization signal is high for the sync
> pulse width. (default)
> 1 = Active Low Pulse. Synchronization signal is low for the
On Tue, Nov 22, 2022 at 10:50:30AM +0200, Tomi Valkeinen wrote:
> On 17/11/2022 17:46, Kieran Bingham wrote:
> > Quoting Tomi Valkeinen (2022-11-17 12:25:46)
> >> From: Tomi Valkeinen
> >>
> >> Add DSI support for r8a779g0. The main differences to r8a779a0 are in
> >> the PLL and PHTW setups.
>
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents. The hardware provides a
dedicated locking mechanism to support this via the MTL_STEER_SEMAPHORE
register.
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
PPAT setup involves a series of multicast writes. This can be optimized
slightly be acquiring forcewake and the steering lock just once for the
entire sequence.
Suggested-by: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 27
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR
register")
Reported-by: kernel test robot
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
1
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
following patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
1 file changed, 10 insertions(+), 8
On Tue, Nov 22, 2022 at 12:16 PM Christian König
wrote:
>
> Ah, thanks a lot for this. I've already pushed the patches into our
> internal branch, but getting this confirmation is still great!
>
> This was quite some fundamental bug in the handling and I hope to get
> this completely reworked at
On Mon, 28 Nov 2022 09:18:47 +0100 David Hildenbrand wrote:
> > Less chances of things going wrong that way.
> >
> > Just mention in the v2 cover letter that the first patch was added to
> > make it easy to backport that fix without being hampered by merge
> > conflicts if it was added after
On 11/28/22 11:53, Maxime Ripard wrote:
> Hi,
>
> This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
> have been doing so far in KMS, it actually tests the atomic modesetting code.
>
> In order to do so, I've had to improve a fair bit on the Kunit helpers already
> found
On 11/28/22 11:53, Maxime Ripard wrote:
> The name doesn't really fit the conventions for the other helpers in
> DRM/KMS, so let's rename it to make it obvious that we allocate a new
> DRM device.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Maíra Canal
Best Regards,
- Maíra Canal
> ---
>
On 11/28/22 11:53, Maxime Ripard wrote:
> In order to test the current atomic_check hooks we need to have a DRM
> device that has roughly the same capabilities and layout that the actual
> hardware. We'll also need a bunch of functions to create arbitrary
> atomic states.
>
> Let's create some
On 11/28/22 11:53, Maxime Ripard wrote:
> We'll need a function that looks up an encoder by its vc4_encoder_type.
> Such a function is already present in the CRTC code, so let's make it
> public so that we can reuse it in the unit tests.
>
> Reviewed-by: Javier Martinez Canillas
> Signed-off-by:
On 11/28/22 11:53, Maxime Ripard wrote:
> The current vc4_crtc_init() helper assumes that we will be using
> hardware planes and calls vc4_plane_init().
>
> While it's a reasonable assumption, we'll want to mock the plane and
> thus provide our own. Let's create a helper that will take the plane
Applied. Thanks!
Alex
On Fri, Nov 25, 2022 at 4:01 PM Randy Dunlap wrote:
>
> Fix documentation build errors for amdgpu: correct the filename.
>
> Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> Error:
On 11/28/22 11:53, Maxime Ripard wrote:
> In order to introduce unit tests for the HVS state computation, we'll
> need access to the vc4_hvs_state struct definition and its associated
> helpers.
>
> Let's move them in our driver header.
>
> Reviewed-by: Javier Martinez Canillas
> Signed-off-by:
On 11/28/22 11:53, Maxime Ripard wrote:
> DRM-managed actions are supposed to be ran whenever the device is
> released. Let's introduce a basic unit test to make sure it happens.
>
> Reviewed-by: Javier Martinez Canillas
> Signed-off-by: Maxime Ripard
Reviewed-by: Maíra Canal
Best Regards,
-
On 11/28/22 11:53, Maxime Ripard wrote:
> The device managed resources are freed when the device is detached, so
> it has to be bound in the first place.
>
> Let's create a fake driver that we will bind to our fake device to
> benefit from the device managed cleanups in our tests.
>
>
On 11/28/22 11:53, Maxime Ripard wrote:
> The device managed resources are ran if the device has bus, which is not
> the case of a root_device.
>
> Let's use a platform_device instead.
>
> Reviewed-by: Javier Martinez Canillas
> Signed-off-by: Maxime Ripard
Reviewed-by: Maíra Canal
Best
On 11/28/22 11:53, Maxime Ripard wrote:
> We'll need in some tests to control when the device needs to be added
> and removed, so let's split the device creation from the DRM device
> creation function.
>
> Signed-off-by: Maxime Ripard
Just a small nit below,
Reviewed-by: Maíra Canal
>
>
On 11/28/22 11:53, Maxime Ripard wrote:
> The device name isn't really useful, we can just define it instead of
> exposing it in the API.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Maíra Canal
Best Regards
- Maíra Canal
> ---
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 +--
>
On 11/28/22 11:53, Maxime Ripard wrote:
> Commit 44a3928324e9 ("drm/tests: Add Kunit Helpers") introduced the
> drm_kunit_device_init() function but didn't document it properly. Add
> that documentation.
>
> Signed-off-by: Maxime Ripard
Just a minor nit on naming, besides that:
Reviewed-by:
On 11/23/2022 15:54, Daniele Ceraolo Spurio wrote:
The fence is only tracking if the HuC load is in progress or not and
doesn't distinguish between already loaded, not supported or disabled,
so we can always initialize it to completed, no matter the actual
support. We already do that for most
Hi
Am 12.09.22 um 11:15 schrieb Uwe Kleine-König:
While working on a drm driver that doesn't need the i2c algobit stuff I
noticed that DRM selects this code even tough only 8 drivers actually use
it. While also only some drivers use i2c, keep the select for I2C for the
next cleanup patch. Still
Hello Javier,
On Mon, Nov 28, 2022 at 05:54:32PM +0100, Javier Martinez Canillas wrote:
> On 9/12/22 11:15, Uwe Kleine-König wrote:
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 198ba846d34b..593d7335b10a 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112
On Thu, Nov 17, 2022 at 06:49:02PM +0100, Krzysztof Kozlowski wrote:
> On 16/11/2022 18:49, Philipp Zabel wrote:
> > On Thu, Nov 10, 2022 at 10:49:45AM +0100, Uwe Kleine-König wrote:
> > [...]
> >> new file mode 100644
> >> index ..c3cf6f92a766
> >> --- /dev/null
> >> +++
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112
From: Dillon Varone
[ Upstream commit e667ee3b0c049bf0c69426879586a2572bb28d26 ]
[WHY?]
When calculating watermark and dlg values, the max mclk level index and
associated speed are needed to find the correlated dummy latency value.
Currently the incorrect index is given due to a clock manager
From: "Stanley.Yang"
[ Upstream commit 3cb93f390453cde4d6afda1587aaa00e75e09617 ]
[Why]
[ 754.862560] refcount_t: underflow; use-after-free.
[ 754.862898] Call Trace:
[ 754.862903]
[ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]
[ 754.863543]
From: Taimur Hassan
[ Upstream commit 2a5dd86a69ea5435f1a837bdb7fafcda609a7c91 ]
[Why]
Pixel rate divider values should never be set to N/A (0xF) as the K1/K2
field is only 1/2 bits wide.
[How]
Set valid divider values for virtual and FRL/DP2 cases.
Reviewed-by: Nicholas Kazlauskas
Acked-by:
From: Dillon Varone
[ Upstream commit dd2c028c1395d622df7ddd6837f8ab2dc94008ee ]
[WHY?]
MALL allocation size depends on the viewport height, not the addressable
vertical lines, which will not match when scaling.
[HOW?]
Base MALL allocation size calculations off viewport height.
Reviewed-by:
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 15f2f20ccbf2d04cb14e3e7635aa0447208c71e7 Add linux-next specific
files for 20221128
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
Hello,
On Wed, Nov 16, 2022 at 11:21:31AM -0600, Rob Herring wrote:
> On Thu, Nov 10, 2022 at 10:49:45AM +0100, Uwe Kleine-König wrote:
> > This is a straight forward conversion. Note that fsl,imx-lcdc was picked
> > as the new name as this is the compatible that should supersede the
> > legacy
Hi Xinhui,
On 11/28/2022 12:04 PM, xinhui pan wrote:
Currently drm-buddy does not have full knowledge of continuous memory.
Lets consider scenario below.
order 1:L R
order 0: LL LR RL RR
for order 1 allocation, it can offer L or R or LR+RL.
For now, we only
Hello Uwe,
Thanks for your patch.
On 9/12/22 11:15, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the select for I2C
On Mon, Sep 12, 2022 at 11:15:05AM +0200, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the select for I2C for the
> next
Hi Dave & Daniel,
Here are the gpu/gem bits for v6.2. Dmitry already sent a separate
pull request[1] for the display bits. Summary below and in tag.
[1]
https://patchwork.kernel.org/project/dri-devel/patch/20221126102141.721353-1-dmitry.barysh...@linaro.org/
The following changes since
On 11/28/2022 5:08 AM, Ville Syrjälä wrote:
On Mon, Nov 28, 2022 at 01:10:58AM -0800, Ceraolo Spurio, Daniele wrote:
On 11/25/2022 5:54 AM, Ville Syrjälä wrote:
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
The fence is always initialized in huc_init_early, but
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
Hello,
These patches add support for the JDI LPM102A188A display panel,
found in the Google Pixel C.
Patch 1 adds the DT bindings for the panel (omitted in RESEND).
Patch 2 adds a register clear to the Tegra DSI driver, needed for the
panel initialization commands to be properly sent.
Patch 3
In cases where the DSI module is left on by the bootloader
some panels may fail to initialize if the enable register is not cleared
before the panel's initialization sequence is sent, so clear it if that
is the case.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- detect if the DSI module is on
The Google Pixel C has a JDI LPM102A188A display panel. Add a
DT node for it. Tested on Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- renamed backlight node to a generic name
- removed underscores
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++
1 file
On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
wrote:
>
> Dear Christian:
>
> What is the status of the AMDGPU work for Xen dom0? That was mentioned in
> https://lore.kernel.org/dri-devel/b2dec9b3-03a7-e7ac-306e-1da024af8...@amd.com/
> and there have been bug reports to Qubes OS about
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 0ae41323a83233610e64e926eefb4d132ecb9028
commit: 1e4a91db109f623d0e3ef7d8bfae3c88b4d2fa87 [12/19] drm/probe-helper:
Provide a TV get_modes helper
config: hexagon-randconfig-r041-20221128
compiler: clang version 16.0.0 (https
tegra_vi_channels_alloc() can primarily fail for two reasons:
1. "ports" node not found
2. port_num > vi->soc->vi_max_channels
Case 1 prints nothing, case 2 has a dev_err(). The caller [tegra_vi_init()]
has a generic dev_err() on any failure. This mean that in case 2 we print
two messages, and
In preparation to implement Tegra20 parallel video capture, add variables
to hold the required syncpt.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
There is only a pointer reference to struct tegra_vi in video.h, thus vi.h
is not needed.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/video.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/tegra-video/video.h
The staging tegra-video driver currently implements MIPI CSI-2 video
capture for Tegra210. Add support for parallel video capture (VIP) on
Tegra20. With the generalizations added to the VI driver in previous
commits, this is only a matter of adding the tegra20.c implementation and
registering it.
The CSI module does not handle all the MIPI lane calibration procedure,
leaving a small part of it to the VI module. In doing this,
tegra_channel_enable_stream() (vi.c) manipulates the private data of the
upstream subdev casting it to struct 'tegra_csi_channel', which will be
wrong after
The tegra_default_format in vi.c is specific to Tegra210 CSI.
In preparation for adding Tegra20 VIP support, move the default format to a
new field in the soc-specific `struct tegra_vi_soc`. Instead of an entire
format struct, only store a pointer to an item in the existing format
array.
No
Tegra20 can do horizontal and vertical image flip, but Tegra210 cannot
(either the hardware, or this driver).
In preparation to adding Tegra20 support, add a flag in struct tegra_vi_soc
so the generic vi.c code knows whether the flip controls should be added or
not.
Also provide a generic
We are about to add support for the Tegra20 parallel video capture, which
has no TPG. In preparation for that, limit the VIDEO_TEGRA_TPG option to
Tegra210 which is the only implementation currently provided by this
driver.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
tegra_channel_host1x_syncpt_init() gets the host1x syncpts needed for the
Tegra210 implementation, and tegra_channel_host1x_syncpts_free() puts
them.
Tegra20 needs to get and put a different syncpt. In preparation for adding
Tegra20 support, move these functions to new ops in the soc-specific
The VI peripheral of Tegra supports capturing from MIPI CSI-2 or parallel
video (called VIP in the docs). MIPI CSI-2 is already implemented. Add a
VIP implementation.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
MAINTAINERS| 1 +
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 7 +++
drivers/staging/media/tegra-video/vi.h | 4
2 files changed, 11 insertions(+)
diff --git
Tegra20 supports planar YUV422 capture, which can be implemented by writing
U and V base address registers in addition to the "main" base buffer
address register.
It also supports H and V flip, which among others requires to write the
start address (i.e. the 1st offset to write, at the end of the
struct tegra_vi_graph_entity is an internal implementation detail of the VI
module. Move its declaration from vi.h to vi.c.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 13 +
drivers/staging/media/tegra-video/vi.h | 13
of_node_put(node) does nothing if node == NULL, so it can be moved to the
cleanup section at the bottom.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
1 - 100 of 169 matches
Mail list logo
