To avoid false positives in error injection cases.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
index
Hey Linus,
pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about
what I'd expect for rc6.
Regards,
Dave.
drm-fixes-2022-05-06:
drm fixes for 5.18-rc6
fbdev:
- hotunplugging fix
amdgpu:
- Fix a xen dom0 regression on APUs
- Fix a potential array overflow if a receiver were to
Fixes coccicheck warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1476:2-3: Unneeded semicolon
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
Return boolean values ("true" or "false") instead of 1 or 0 from bool
functions.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
Linus wrote:
>
> On Wed, May 4, 2022 at 1:19 AM Byungchul Park wrote:
> >
> > Hi Linus and folks,
> >
> > I've been developing a tool for detecting deadlock possibilities by
> > tracking wait/event rather than lock(?) acquisition order to try to
> > cover all synchonization machanisms.
>
> So
On 5/5/22 4:16 AM, Juergen Gross wrote:
Many Xen PV frontends share similar code for setting up a ring page
(allocating and granting access for the backend) and for tearing it
down.
Create new service functions doing all needed steps in one go.
This requires all frontends to use a common
On 5/5/22 11:34, Thomas Zimmermann wrote:
> Hi
>
> Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
>> Introduce a common DRM SHMEM shrinker. It allows to reduce code
>> duplication among DRM drivers that implement theirs own shrinkers.
>> This is initial version of the shrinker that covers basic
Prior series have transformed other parts of VFIO from working on struct
device or struct vfio_group into working directly on struct
vfio_device. Based on that work we now have vfio_device's readily
available in all the drivers.
Update the rest of the driver facing API to use vfio_device as an
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. Change vfio_dma_rw() to take in the
struct vfio_device and move the container users that would have been held
by vfio_group_get_external_user_from_dev() to vfio_dma_rw() directly, like
Now that callers have been updated to use the vfio_device APIs the driver
facing group interface is no longer used, delete it:
- vfio_group_get_external_user_from_dev()
- vfio_group_pin_pages()
- vfio_group_unpin_pages()
- vfio_group_iommu_domain()
Reviewed-by: Christoph Hellwig
Reviewed-by:
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 47 -
When the open_device() op is called the container_users is incremented and
held incremented until close_device(). Thus, so long as drivers call
functions within their open_device()/close_device() region they do not
need to worry about the container_users.
These functions can all only be called
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
Acked-by: Eric Farman
Reviewed-by: Jason J. Herne
Reviewed-by: Tony Krowiak
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason
Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
reason to use a group interface here, kvmgt has easy access to a
vfio_device.
Delete kvmgt_vdev::vfio_group since these calls were the last users.
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by:
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Reviewed-by: Christoph Hellwig
Acked-by:
On 5/5/22 23:08, Mark Brown wrote:
On Thu, May 05, 2022 at 07:32:23PM +0200, Marek Vasut wrote:
On 5/5/22 17:12, Mark Brown wrote:
On Sat, 30 Apr 2022 04:51:44 +0200, Marek Vasut wrote:
Currently the regmap_config structure only allows the user to implement
single element register
Return boolean values ("true" or "false") instead of 1 or 0 from bool
functions. This fixes the following warnings from coccicheck:
./drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c:244:9-10: WARNING:
return of 0/1 in function 'event_interrupt_isr_v11' with return type
bool
Reported-by: Abaci
Eliminate the following coccicheck warning:
./drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1476:2-3: Unneeded
semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Eliminate the following coccicheck warning:
./drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:1222:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
"Sierra Guiza, Alejandro (Alex)" writes:
> @apop...@nvidia.com Could you please check this patch? It's somehow related to
> migrate_device_page() for long term device coherent pages.
Sure thing. This whole series is in my queue of things to review once I make it
home from LSF/MM.
- Alistair
On 5/5/22 11:12, Daniel Vetter wrote:
> On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote:
>> On 5/4/22 11:21, Daniel Vetter wrote:
>> ...
> - Maybe also do what you suggest and keep a separate lock for this, but
> the fundamental issue is that this doesn't really work - if
Hi,
On Thu, May 5, 2022 at 3:15 PM Dmitry Baryshkov
wrote:
>
> On 06/05/2022 00:24, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, May 5, 2022 at
On Tue, Apr 26, 2022 at 06:08:27PM +0800, Yunfei Dong wrote:
> Add support for VP9 decoding using the stateless API,
> as supported by MT8192. And the drivers is lat and core architecture.
>
> Signed-off-by: Yunfei Dong
> Signed-off-by: George Sun
> Reviewed-by: AngeloGioacchino Del Regno
>
>
On 06/05/2022 00:24, Doug Anderson wrote:
Hi,
On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
wrote:
On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
Hi,
On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
wrote:
On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
Hi,
On Thu, May 5,
On 04/22, Harry Wentland wrote:
>
>
> On 2022-04-22 10:28, Melissa Wen wrote:
> > On 04/21, Harry Wentland wrote:
> > >
> > >
> > > On 2022-04-21 15:20, Melissa Wen wrote:
> > > > On 04/21, Harry Wentland wrote:
> > > > >
> > > > >
> > > > > On 2022-04-21 10:37, Melissa Wen wrote:
> > > > >
The driver is calling framebuffer_release() in its .remove callback, but
this will cause the struct fb_info to be freed too early. Since it could
be that a reference is still hold to it if user-space opened the fbdev.
This would lead to a use-after-free error if the framebuffer device was
The driver is calling framebuffer_release() in its .remove callback, but
this will cause the struct fb_info to be freed too early. Since it could
be that a reference is still hold to it if user-space opened the fbdev.
This would lead to a use-after-free error if the framebuffer device was
The driver is calling framebuffer_release() in its .remove callback, but
this will cause the struct fb_info to be freed too early. Since it could
be that a reference is still hold to it if user-space opened the fbdev.
This would lead to a use-after-free error if the framebuffer device was
From: Daniel Vetter
Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their driver's .remove callback, rather than
doing from fbops.fb_destroy callback.
Doing that will destroy the fb_info too early, while references to it may
still exist,
On Thu, May 5, 2022 at 2:41 PM Jessica Zhang wrote:
>
> There is a possibility for mdp5_get_global_state to return
> -EDEADLK when acquiring the modeset lock, but currently global_state in
> mdp5_mixer_release doesn't check for if an error is returned.
>
> To avoid a NULL dereference error, let's
On Thu, May 5, 2022 at 2:41 PM Jessica Zhang wrote:
>
> mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
> the modeset lock, but currently mdp5_pipe_release doesn't check for if
> an error is returned. Because of this, there is a possibility of
> mdp5_pipe_release hitting
Hello,
This series contains patches suggested by Daniel Vetter to fix a use-after-free
error in the fb_release() function, due a fb_info associated with a fbdev being
freed too early while a user-space process still has the fbdev dev node opened.
That is caused by a wrong management of the
The "ret" variable is ambiguously returning something that
could be zero in the tve200_modeset_init() function, assign
it an explicit error return code to make this unambiguous.
Reported-by: Dan Carpenter
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/tve200/tve200_drv.c | 3 ++-
1 file
There is a possibility for mdp5_get_global_state to return
-EDEADLK when acquiring the modeset lock, but currently global_state in
mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release
check if an error is returned and
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
an error is returned. Because of this, there is a possibility of
mdp5_pipe_release hitting a NULL dereference error.
To avoid this, let's have
From: John Harrison
PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too large' compile warning. This patch takes
Let's reorganize some of the forcewake/shadow handling in intel_uncore.c
and consolidate the cargo-cult comments on each table into more general
comments that apply to all tables.
We'll probably move forcewake handling to its own dedicated file in the
near future and further enhance this with
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
compute-focused platform, PVC has compute engines and enhanced copy
engines, but no render engine (there is no geometry pipeline) and no
display.
This is just a handful of early enablement patches, including some
initial
Add the interrupt handler support for new copy engines.
Bspec: 54030
Original-author: CQ Tang
Signed-off-by: Matt Roper
Reviewed-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 16
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
2 files changed, 20
From: Lucas De Marchi
The new Link Copy engines in PVC may be fused off according to the
mslice_mask. Each bit of the MEML3_EN_MASK we read from the
GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
v2 (Tvrtko):
- Minor cosmetic changes: s/u8/unsigned long/, use instance local
Add the reset support for new copy engines in PVC.
Bspec: 52549
Original-author: CQ Tang
Signed-off-by: Matt Roper
Reviewed-by: José Roberto de Souza
Reviewed-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44
From: Lucas De Marchi
As we have more copy engines now, mask all of them from aux table
invalidate.
v2 (MattR):
- Use I915_MAX_BCS to determine mask rather than hardcoding BCS8.
(Prathap)
Cc: Prathap Kumar Valsan
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
Reviewed-by: José
This patch adds the basic definitions needed to support
new copy engines. Also updating the cmd_info to accommodate
new engines, as the engine id's of legacy engines have been
changed.
v2:
- Add _BCS(n) definition, similar to other engines. (Tvrtko)
- Add I915_MAX_BCS definition, similar to
From: Stuart Summers
Although we already strip 3D-specific flags from PIPE_CONTROL
instructions when submitting to a compute engine, there are some
additional flags that need to be removed when the platform as a whole
lacks a 3D pipeline. Add those restrictions here.
Bspec: 47112
When i915 adds additional PVC blitter instances (in an upcoming patch),
the definition of VECS0 will change from bit(10) to bit(18), causing
GVT's R_ALL mask to overflow the u16 storage that's currently used.
Let's replace the u16 with an intel_engine_mask_t to ensure we avoid
this.
Cc: Tvrtko
From: Ayaz A Siddiqui
v2 (MattR):
- Clarify comment above RING_CMD_CCTL programming.
- Remove bspec reference from field definition. (Lucas)
- Add WARN if we try to use a (presumably uninitialized) wb_index of 0.
On most platforms 0 is an invalid MOCS entry and even on the ones
where
The SoC registers, including RP_STATE_CAP, have moved to a new location
in GTTMMADR on Ponte Vecchio. We need to update the register offset
accordingly.
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++-
Add PVC's forcewake ranges.
v2:
- Drop replicated comment completely; move general cleanup of the
documentation to a separate patch.
Bspec: 67609
Cc: Daniele Ceraolo Spurio
Cc: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_uncore.c | 142
@apop...@nvidia.com Could you please check this patch? It's somehow related to
migrate_device_page() for long term device coherent pages.
Regards,
Alex Sierra
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Sierra
> Sent: Thursday, May 5, 2022 4:34 PM
> To: j...@nvidia.com
>
Hi Mauro,
[...]
> +static int ref_module_dependency(struct module *mod, struct module *this)
> +{
> + int ret;
> +
> + if (!this || !this->name)
> + return -EINVAL;
> +
> + if (mod == this)
> + return 0;
> +
> + mutex_lock(_mutex);
> +
> + ret =
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/hmm-tests.c | 104
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP.
We also introduced a FOLL_LRU flag
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair
The objective is to test device migration mechanism in pages marked
as COW, for private and coherent device type. In case of writing to
COW private page(s), a page fault will migrate pages back to system
memory first. Then, these pages will be duplicated. In case of COW
device coherent type, pages
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
Acked-by: Felix
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only
Coherent device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Coherent type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_COHERENT.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by:
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
lib/test_hmm.c | 23 +--
During remove_migration_pte(), entries for device coherent type pages
that were not created through special migration ptes, ignore _PAGE_RW
flag. This path can be found at migrate_device_page(), where valid
vma is not required. In this case, migrate_vma_collect_pmd() is not
called and special
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
From: Alistair Popple
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these
From: Alistair Popple
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
for current 5.18-rc5.
Changes since the last version:
- Fixed problems with migration during long-term pinning in
get_user_pages
- Open coded vm_normal_lru_pages as suggested in previous code review
- Update hmm_gup_test with
Hi,
On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
wrote:
>
> On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> > > >
> > > > Hi,
> > > >
> > > > On
On Thu, May 05, 2022 at 07:32:23PM +0200, Marek Vasut wrote:
> On 5/5/22 17:12, Mark Brown wrote:
> > On Sat, 30 Apr 2022 04:51:44 +0200, Marek Vasut wrote:
> > > Currently the regmap_config structure only allows the user to implement
> > > single element register read/write using
Hi Thomas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-tip/drm-tip tegra-drm/drm/tegra/for-next v5.18-rc5 next-20220505]
[cannot apply to airlied/drm-next]
[If your
On Tue, May 03, 2022 at 09:05:43AM +0100, Tvrtko Ursulin wrote:
>
> On 02/05/2022 17:34, Matt Roper wrote:
> > This patch adds the basic definitions needed to support
> > new copy engines. Also updating the cmd_info to accommodate
> > new engines, as the engine id's of legacy engines have been
>
On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
>
> Hi,
>
> On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
> wrote:
> >
> > On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Thu, May 05,
Hi,
On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
wrote:
>
> On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > wrote:
> > >
> > > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On
On Tue, 26 Apr 2022 at 21:47, Douglas Anderson wrote:
>
> As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
> that all detachable sinks shall support 640x480 @60Hz as a fail safe
> mode.
>
> A DP compliance test expected us to utilize the above fact when all
> modes it
Hi,
On Thu, May 5, 2022 at 12:19 PM Ville Syrjälä
wrote:
>
> On Thu, May 05, 2022 at 08:53:12AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > wrote:
> > >
> > > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> >
On Thu, 5 May 2022 at 20:30, Kuogee Hsieh wrote:
>
>
> On 5/5/2022 10:20 AM, Abhinav Kumar wrote:
> > Hi Doug
> >
> > On 5/5/2022 8:44 AM, Doug Anderson wrote:
> >> Ville,
> >>
> >> On Tue, Apr 26, 2022 at 11:47 AM Douglas Anderson
> >> wrote:
> >>>
> >>> As per Displayport spec section 5.2.1.2
On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
>
> Hi,
>
> On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> wrote:
> >
> > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Wed, May
On Thu, May 5, 2022 at 5:04 PM Mark Brown wrote:
> On Thu, May 05, 2022 at 04:59:35PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 4:39 PM Mark Brown wrote:
> > > On Thu, May 05, 2022 at 04:33:06PM +0200, Linus Walleij wrote:
> > > > On Thu, May 5, 2022 at 8:04 AM Arnd Bergmann wrote:
Hmm, I think we might just need to move the drm_kms_helper_poll_enable() call
to the end here instead of all of nouveau_display_init(). I realized this
because in nouveau_display_init() it seems that we actually rely on
nouveau_display_init() to setup hotplug interrupts - which we do actually need
Because i reviewed this already and the only new change is the relocation
of the function "huc_is_authenticated()" from Patch 1 to this patch while
maintaining the same logic as rev-1, thus:
Acked-by: Alan Previn
On Wed, 2022-05-04 at 13:48 -0700, Daniele Ceraolo Spurio wrote:
> HuC loading
Reviewed-by: Alan Previn
On Wed, 2022-05-04 at 13:48 -0700, Daniele Ceraolo Spurio wrote:
> The fuction name is confusing, because it doesn't check the actual auth
> status in HW but the SW status. Given that there is only one user (the
> huc_auth function itself), just get rid of it and use the
So I think if Ville is OK with it (an ack at least) I'm fine with this
documentation change. I think it's worth me noting for other reviewers I made
this decision based on the fact that the documentation is for the transfer()
function - which I agree shouldn't need to be responsible for powering
Hi,
On Thu, May 5, 2022 at 11:34 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 26.04.22 um 20:46 schrieb Douglas Anderson:
> > The drm_helper_probe_single_connector_modes() is a bit long. Let's
> > break a chunk off to update and validate modes. This helps avoid one
> > goto and also will allow us
On Thu, May 05, 2022 at 08:53:12AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> wrote:
> >
> > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> > > wrote:
> > > >
> > > >
Thanks!
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Thu, 2022-05-05 at 16:13 +0800, Jiapeng Chong wrote:
> Eliminate the follow smatch warning:
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1925
> gf100_gr_oneinit_tiles() warn: inconsistent indenting.
>
> Reported-by:
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #69 from Danil (s48g...@gmail.com) ---
Edit - got freeze after using PC for 4 hours, before it was 20 min longest time
I could use integrated GPU, so it not fixed completely look like, just some
improvement(or I just got lucky)... im
Quoting Sankeerth Billakanti (QUIC) (2022-05-05 11:47:20)
> >Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
> >>
> >> Our internal power grid documents list the regulators as VDD_A_*_1P2
> >> and VDD_A_*_0P9 for all the platforms.
> >
> >Do your internal power grid documents indicate what
On 5/4/2022 16:46, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
In GuC submission mode the EU priority must be updated by the GuC rather
than the driver as the GuC owns the programming of the context descriptor.
Given that the GuC code uses the GuC priorities, we can't use a generic
>We're supposed to list the supplies in the dt bindings but there are none in
>the eDP PHY bindings.
>
>Looking at the driver in Linux, I can see that there seem to be two relevant
>supplies: "vdda-phy" and "vdda-pll". Let's add those to the bindings.
>
>NOTE: from looking at the Qualcomm
>Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
>> >>
>> >> Quoting Douglas Anderson (2022-04-25 14:06:42)
>> >>
>> >> Having 'a' in 'vdda' typically means 'analog' for 'analog'
>> >> circuits, so I'd expect this to only matter for the phy that
>> >> contains the analog circuitry. It would be
On 5/5/2022 10:21, Belgaumkar, Vinay wrote:
On 5/5/2022 5:13 AM, Tvrtko Ursulin wrote:
On 05/05/2022 06:40, Vinay Belgaumkar wrote:
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing
Hi
Am 26.04.22 um 20:46 schrieb Douglas Anderson:
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding
Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
> >>
> >> Quoting Douglas Anderson (2022-04-25 14:06:42)
> >>
> >> Having 'a' in 'vdda' typically means 'analog' for 'analog' circuits,
> >> so I'd expect this to only matter for the phy that contains the analog
> >> circuitry. It would be great
Am 05.05.22 um 19:26 schrieb Javier Martinez Canillas:
Thomas asked me to serve as co-maintainer for the simpledrm driver.
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Thanks for all the work you're doing, Javier.
---
MAINTAINERS | 1 +
1 file changed, 1
Hi Doug,
>>
>> Quoting Douglas Anderson (2022-04-25 14:06:42)
>> > We're supposed to list the supplies in the dt bindings but there are
>> > none in the DP controller bindings. Looking at the Linux driver and
>> > existing device trees, we can see that two supplies are expected:
>> > -
Am 05.05.22 um 15:29 schrieb Daniel Vetter:
On Wed, May 04, 2022 at 02:22:52PM +0200, Christian König wrote:
The selftests, fix the error handling, remove unused functions and stop
leaking memory in failed tests.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-fence-unwrap.c | 40
On 5/4/22 09:59, Raphael Gallais-Pou wrote:
Hi Marek,
Hi,
[...]
@@ -499,8 +512,16 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
}
dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
+
+ ret = dw_mipi_dsi_phy_regulator_on(dsi);
On Thu, 05 May 2022, Ville Syrjälä wrote:
> On Tue, May 03, 2022 at 12:23:45PM +0300, Jani Nikula wrote:
>> I've kind of lost track of the version numbers on some of the iterator
>> patches, but this is the next version (or mostly a resend) of
>> [1]. There's an additional rename patch for SCDS.
On 5/5/2022 1:48 AM, Dmitry Baryshkov wrote:
On Thu, 5 May 2022 at 05:06, Rob Clark wrote:
On Wed, May 4, 2022 at 6:55 PM Jessica Zhang wrote:
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
On 5/5/22 17:12, Mark Brown wrote:
On Sat, 30 Apr 2022 04:51:44 +0200, Marek Vasut wrote:
Currently the regmap_config structure only allows the user to implement
single element register read/write using .reg_read/.reg_write callbacks.
The regmap_bus already implements bulk counterparts of both,
On 5/5/2022 10:20 AM, Abhinav Kumar wrote:
Hi Doug
On 5/5/2022 8:44 AM, Doug Anderson wrote:
Ville,
On Tue, Apr 26, 2022 at 11:47 AM Douglas Anderson
wrote:
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a
1 - 100 of 204 matches
Mail list logo
