Add support for ACPI based device registration so that the driver
can be also enabled through ACPI table.
Signed-off-by: Akhil R
---
drivers/i2c/busses/i2c-tegra.c | 52 --
1 file changed, 40 insertions(+), 12 deletions(-)
diff --git
On Tuesday, 23 November 2021 4:16:55 AM AEDT Felix Kuehling wrote:
[...]
> > Right, so long as my fix goes in I don't think there is anything wrong with
> > pinning device public pages. Agree that we should avoid FOLL_LONGTERM pins
> > for
> > device memory though. I think the way to do that is
Le 22/11/2021 à 22:44, Felix Kuehling a écrit :
Am 2021-11-21 um 12:41 p.m. schrieb Christophe JAILLET:
The 'doorbell_bitmap' bitmap has just been allocated. So we can use the
non-atomic '__set_bit()' function to save a few cycles as no concurrent
access can happen.
Signed-off-by: Christophe
Correct kernel-doc warnings in i915_drm_object.c:
i915_gem_object.c:103: warning: expecting prototype for i915_gem_object_fini().
Prototype was for __i915_gem_object_fini() instead
i915_gem_object.c:110: warning: This comment starts with '/**', but isn't a
kernel-doc comment. Refer
From: Gurchetan Singh
With the use of dummy events, we can drop virtgpu specific
behavior.
Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add
virtio_gpu_fence_event")
Reported-by: Daniel Vetter
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 42
From: Gurchetan Singh
The current virtgpu implementation of poll(..) drops events
when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is enabled (otherwise
it's like a normal DRM driver).
This is because paravirtualized userspaces receives responses in a
buffer of type BLOB_MEM_GUEST, not by read(..).
From: Gurchetan Singh
There was a desire to not have a virtgpu-specific implementation of
poll(..), but there wasn't any real event to return either.
Solution: Dummy event with just event code
Context:
https://lists.freedesktop.org/archives/dri-devel/2021-November/330950.html
Userspace:
This series:
1. Supports the roll out of an upcoming GuC feature to
enable error-state-capture that allows the driver to
register lists of MMIO registers that GuC will report
during a GuC triggered engine-reset event.
2. Updates the ADS blob creation to register lists
of
On Mon, Nov 22, 2021 at 11:21:52PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> I recently came across some new uses of the 'slave_id' field that
> I had (almost) removed a few years ago. There are no legitimate
> uses of this field in the kernel, only a few stale references and
> two
On Mon, Nov 22, 2021 at 2:02 AM Pekka Paalanen wrote:
>
> On Fri, 19 Nov 2021 11:21:36 -0500
> Jason Baron wrote:
>
> > On 11/18/21 10:24 AM, Pekka Paalanen wrote:
> > > On Thu, 18 Nov 2021 09:29:27 -0500
> > > Jason Baron wrote:
> > >
> > >> On 11/16/21 3:46 AM, Pekka Paalanen wrote:
> > >>>
From: Arnd Bergmann
All references to the slave_id field have been removed, so remove the
field as well to prevent new references from creeping in again.
Originally this allowed slave DMA drivers to configure which device
is accessed with the dmaengine_slave_config() call, but this was
From: Arnd Bergmann
Nothing sets the slave_id field any more, so stop accessing
it to allow the removal of this field.
Signed-off-by: Arnd Bergmann
---
drivers/dma/tegra20-apb-dma.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c
From: Arnd Bergmann
The display driver wants to pass a custom flag to the DMA engine driver,
which it started doing by using the slave_id field that was traditionally
used for a different purpose.
As there is no longer a correct use for the slave_id field, it should
really be removed, and the
From: Arnd Bergmann
The slave_id was previously used to pick one DMA slave instead of another,
but this is now done through the DMA descriptors in device tree.
For the qcom_adm driver, the configuration is documented in the DT
binding to contain a tuple of device identifier and a "crci" field,
From: Arnd Bergmann
It appears that the code that reads the slave_id from the channel config
was copied incorrectly from other drivers. Nothing ever sets this field
on platforms that use this driver, so remove the reference.
Reviewed-by: Baolin Wang
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
The last driver referencing the slave_id on Marvell PXA and MMP platforms
was the SPI driver, but this stopped doing so a long time ago, so the
TODO from the earlier patch can no be removed.
Fixes: b729bf34535e ("spi/pxa2xx: Don't use slave_id of dma_slave_config")
Fixes:
From: Arnd Bergmann
The slave device is picked through either devicetree or a filter
function, and any remaining out-of-tree drivers would have warned
about this usage since 2015.
Stop interpreting the field finally so it can be removed from
the interface.
Reviewed-by: Laurent Pinchart
From: Arnd Bergmann
The field is not interpreted by the DMA engine driver, as all the data
is passed from devicetree instead. Remove the assignment so the field
can eventually be deleted.
Reviewed-by: Nicolas Saenz Julienne
Signed-off-by: Arnd Bergmann
---
drivers/mmc/host/bcm2835.c | 2 --
From: Arnd Bergmann
Setting slave_id makes no sense with DT based probing, and
should eventually get removed entirely. Address this driver
by no longer setting the field here.
I could not find which DMA driver is used on PIC32, if it's
in the tree at all, but none of the obvious ones even care
From: Arnd Bergmann
This field is no longer set from any driver now, so remove the
last references as well.
Signed-off-by: Arnd Bergmann
---
include/sound/dmaengine_pcm.h | 2 --
sound/core/pcm_dmaengine.c| 5 ++---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git
From: Arnd Bergmann
The DMA resource is never set up anywhere, and passing this as slave_id
has not been the proper procedure in a long time.
As a preparation for removing all slave_id references from the ALSA code,
remove this one.
According to Dmitry Osipenko, this driver has never been used
From: Arnd Bergmann
I recently came across some new uses of the 'slave_id' field that
I had (almost) removed a few years ago. There are no legitimate
uses of this field in the kernel, only a few stale references and
two drivers that abuse the field as a side-channel between the
dmaengine driver
I wonder what vivo's interested in this for!
Anyway:
Reviewed-by: Lyude Paul
Do you need me to push this to drm-misc-next for you?
On Tue, 2021-11-16 at 17:48 -0800, Bernard Zhao wrote:
> This patch try to fix the potential memleak in error branch.
>
> Signed-off-by: Bernard Zhao
> ---
>
in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christophe-JAILLET/drm-amdkfd-Use-bitmap_zalloc-when-applicable/20211122-014305
base: git://anongit.freedesktop.org/drm/drm drm-next
config: x86_64-randconfig-a015-20211121 (attached as .config
Starting from a patch from Matt to_root_gt() returns the
reference to the root tile in order to abstract the root tile
from th callers.
Being the root tile identified as tile '0', embed the id in the
name so that i915->gt becomes i915->gt0.
The renaming has been mostly done with the following
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
Hi,
the first of the two patches concludes the first stage of
refactoring which makes the use of intel_gt on the different
subsystem. It's taken from Matt's series and it has alread been
reviewed. The patch has just been replaced before any multitile
patches and I think it can be already pushed.
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40
With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still using the pages.
Add waiting for gpu in the
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a
This patch series deals with async migration and async vram management.
It still leaves an important part out, which is async unbinding which
will reduce latency further, at least when trying to migrate already active
objects.
Patch 1/6 deals with accessing and waiting for the TTM moving
fence
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
Am 2021-11-21 um 12:41 p.m. schrieb Christophe JAILLET:
> The 'doorbell_bitmap' bitmap has just been allocated. So we can use the
> non-atomic '__set_bit()' function to save a few cycles as no concurrent
> access can happen.
>
> Signed-off-by: Christophe JAILLET
Thank you for the patches. I
Am 22.11.21 um 04:14 schrieb Huang Rui:
On Sun, Nov 21, 2021 at 11:54:52PM +0800, Randy Dunlap wrote:
Fix kernel-doc warnings in ttm_range_manager.c:
drivers/gpu/drm/ttm/ttm_range_manager.c:144: warning: expecting prototype for
ttm_range_man_init(). Prototype was for
Reviewed-by: Lyude Paul
On Sun, 2021-11-21 at 12:00 +0100, Hans de Goede wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined with some
Adds this common format to vkms.
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the
This will be useful to write tests that depends on these formats.
ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the new format introduced in patch 7 V3.
---
Add a helper function to validate the connector configuration receive in
the encoder atomic_check by the drivers.
So the drivers don't need do these common validations themselves.
Signed-off-by: Igor Torrente
---
V2: Move the format verification to a new helper at the drm_atomic_helper.c
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
possible inputs. It consists of 16 bits
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
This will allow us, in the future, to have different compositing and
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct is contains information of the frame that is
being used in the output composition. Thus, vkms_frame_info
is a
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Signed-off-by: Igor Torrente
---
Currently, the memory to the composition frame is being allocated using
the kzmalloc. This comes with the limitation of maximum size of one
page size(which in the x86_64 is 4Kb and 4MB for default and hugepage
respectively).
Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when
The `drm_mode_config_init` was deprecated since c3b790e commit, and it's
being replaced by the `drmm_mode_config_init`.
Signed-off-by: Igor Torrente
---
V2: Change the code style(Thomas Zimmermann).
---
drivers/gpu/drm/vkms/vkms_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Summary
===
This series of patches refactor some vkms components in order to introduce
new formats to the planes and writeback connector.
Now in the blend function, the plane's pixels are converted to ARGB16161616
and then blended together.
The CRC is calculated based on the ARGB1616161616
patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-ttm-Async-migration/20211122-162430
base:
On 2021-11-22 17:47, Alex Bee wrote:
Am 22.11.21 um 09:10 schrieb Sascha Hauer:
Hi Alex,
On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:
Hi Sascha,
Am 17.11.21 um 15:33 schrieb Sascha Hauer:
This series adds initial graphics support for the Rockchip RK356[68]
SoCs. Graphics
On Mon, Nov 22, 2021 at 10:26 AM Rob Clark wrote:
>
> On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen wrote:
> >
> > Capture gmu log in coredump to enhance debugging.
> >
> > Signed-off-by: Akhil P Oommen
> > ---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41
> >
On Wed, Nov 17, 2021 at 02:49:55PM -0800, Vinay Belgaumkar wrote:
> From: Chris Wilson
>
> While the power consumption is proportional to the frequency, there is
> also a static draw for active gates. The longer we are able to powergate
> (rc6), the lower the static draw. Thus there is a
On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen wrote:
>
> Capture gmu log in coredump to enhance debugging.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41
> +
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
>
Am 22.11.21 um 09:10 schrieb Sascha Hauer:
> Hi Alex,
>
> On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:
>> Hi Sascha,
>>
>> Am 17.11.21 um 15:33 schrieb Sascha Hauer:
>>> This series adds initial graphics support for the Rockchip RK356[68]
>>> SoCs. Graphics support is based around
CC Tomas and Sasha
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Monday, November 22, 2021 18:54
> To: Jason A. Donenfeld ; Lubart, Vitaly
> ; Gupta, Anshuman ;
> Surendrakumar Upadhyay, TejaskumarX
>
> Cc: LKML ; intel-...@lists.freedesktop.org; dri-
> devel
> Subject:
Hi
On Mon, 22 Nov 2021 at 15:35, Neil Armstrong wrote:
>
> Hi,
>
> On 22/11/2021 14:16, Jagan Teki wrote:
> > Hi Neil,
> >
> > On Mon, Nov 22, 2021 at 6:22 PM Neil Armstrong
> > wrote:
> >>
> >> On 22/11/2021 07:52, Jagan Teki wrote:
> >>> Some display panels would come up with a non-DSI
Am 2021-11-21 um 9:40 p.m. schrieb Alistair Popple:
diff --git a/mm/migrate.c b/mm/migrate.c
index 1852d787e6ab..f74422a42192 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -362,7 +362,7 @@ static int expected_page_refs(struct address_space
*mapping, struct page
Hi Daniele,
I'll give it a whirl on my laptop. Thanks.
Jason
Hi,
The fix for this is in flight:
https://patchwork.freedesktop.org/series/96658/
It just needs a last round of testing before we merge it.
Thanks,
Daniele
On 11/22/2021 8:47 AM, Jason A. Donenfeld wrote:
Hey Intel PXPers,
I hit this splat on 5.16-rc1 during system suspend:
Nov 22
Hey Intel PXPers,
I hit this splat on 5.16-rc1 during system suspend:
Nov 22 13:54:09 thinkpad systemd-logind[934]: Lid closed.
Nov 22 13:54:09 thinkpad systemd[1]: Reached target Sleep.
Nov 22 13:54:09 thinkpad systemd[1]: Starting System Suspend...
Nov 22 13:54:09 thinkpad
On 2021-11-08 at 18:45:45 +0100, Thomas Hellström wrote:
> The capture code is typically run entirely in the fence signalling
> critical path. We're about to add lockdep annotation in an upcoming patch
> which reveals a lockdep splat similar to the below one.
>
> Fix the associated potential
On 22.11.2021 16:07, Marek Szyprowski wrote:
> On 22.11.2021 15:55, Jagan Teki wrote:
>> On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki
>> wrote:
>>> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki
>>> wrote:
On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
wrote:
> On 22.11.2021 08:06,
-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-ttm-Async-migration/20211122-162430
Hi,
On 22/11/2021 14:16, Jagan Teki wrote:
> Hi Neil,
>
> On Mon, Nov 22, 2021 at 6:22 PM Neil Armstrong
> wrote:
>>
>> On 22/11/2021 07:52, Jagan Teki wrote:
>>> Some display panels would come up with a non-DSI output, those
>>> can have an option to connect the DSI host by means of interface
On 22/11/2021 14:04, Matthew Auld wrote:
On 22/11/2021 13:57, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.
Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive
On 11/19/2021 9:25 AM, Jani Nikula wrote:
On Fri, 19 Nov 2021, Daniel Vetter wrote:
On Fri, Nov 19, 2021 at 12:03:00PM +0200, Ville Syrjälä wrote:
On Fri, Nov 19, 2021 at 10:40:38AM +0100, Daniel Vetter wrote:
On Thu, Oct 28, 2021 at 05:04:19PM +0300, Ville Syrjälä wrote:
On Thu, Oct 28,
Le lun., nov. 22 2021 at 16:17:59 +0100, Lars-Peter Clausen
a écrit :
On 11/22/21 4:16 PM, Paul Cercueil wrote:
Hi Lars,
Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100,
On Mon, Nov 22, 2021 at 8:36 PM Maxime Ripard wrote:
>
> On Mon, Nov 22, 2021 at 08:01:47PM +0530, Jagan Teki wrote:
> > On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard wrote:
> > >
> > > On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > > > It's perfectly valid to dereference the
On 11/22/21 4:16 PM, Paul Cercueil wrote:
Hi Lars,
Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Hi Lars,
Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100,
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The
On 22.11.2021 15:55, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki wrote:
>> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki
>> wrote:
>>> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
>>> wrote:
On 22.11.2021 08:06, Jagan Teki wrote:
> Some display panels would come up
On 2021-11-08 at 18:45:44 +0100, Thomas Hellström wrote:
> The gpu coredump typically takes place in a dma_fence signalling
> critical path, and hence can't use GFP_KERNEL allocations, as that
> means we might hit deadlocks under memory pressure. However
> changing to __GFP_KSWAPD_RECLAIM which
On Mon, Nov 22, 2021 at 08:01:47PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard wrote:
> >
> > On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > > that patch would consume
On Mon, 2021-11-22 at 15:15 +0100, Christian König wrote:
> Am 16.11.21 um 16:53 schrieb Zack Rusin:
> > > On Nov 16, 2021, at 03:20, Christian König
> > > wrote:
> > >
> > > Am 16.11.21 um 08:43 schrieb Thomas Hellström:
> > > > On 11/16/21 08:19, Christian König wrote:
> > > > > Am 13.11.21 um
On Mon, Nov 22, 2021 at 07:49:26PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:35 PM Maxime Ripard wrote:
> > On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> > > On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard wrote:
> > > >
> > > > On Mon, Nov 22, 2021 at 12:22:19PM +0530,
Hi Marek,
On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki wrote:
>
> Hi Marek,
>
> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki wrote:
> >
> > Hi Marek,
> >
> > On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
> > wrote:
> > >
> > > On 22.11.2021 08:06, Jagan Teki wrote:
> > > > Some display panels
Hi,
On Sat, Nov 20, 2021 at 12:46:33AM +0200, Laurent Pinchart wrote:
> On Tue, Nov 16, 2021 at 03:35:02PM +0100, Maxime Ripard wrote:
> > The lvds.yaml file so far was both defining the generic LVDS properties
> > (such as data-mapping) that could be used for any LVDS sink, but also
> > the
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Hristos from comment #25)
> Kernel: 5.15.3
> Mesa: 21.2.5
> Xorg: 7.6
>
> I see this when running OpenMW and a lot of mods
>
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-2028]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.16-rc2]
[If your patch is
On 22.11.2021 15:40, Fabio Estevam wrote:
> Hi Jagan,
>
> On Mon, Nov 22, 2021 at 11:21 AM Jagan Teki
> wrote:
>
>> Is this with Bridge or normal DSI panel?
> According to the log shared by Marek, the dts being used is:
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> which includes
Hi Jagan,
On 22.11.2021 15:21, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
> wrote:
>> On 22.11.2021 08:06, Jagan Teki wrote:
>>> Some display panels would come up with a non-DSI output, those
>>> can have an option to connect the DSI host by means of interface
>>>
Hi Jagan,
On Mon, Nov 22, 2021 at 11:21 AM Jagan Teki wrote:
> Is this with Bridge or normal DSI panel?
According to the log shared by Marek, the dts being used is:
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
which includes arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi.
In this
On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard wrote:
>
> On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > that patch would consume memory for no particular reason.
> >
> > Again, I'm not pointing any
Hi Marek,
On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki wrote:
>
> Hi Marek,
>
> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
> wrote:
> >
> > On 22.11.2021 08:06, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output, those
> > > can have an option to connect the DSI
Hi Marek,
On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
wrote:
>
> On 22.11.2021 08:06, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> >
> > This DSI to non-DSI
-20211122 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
c133fb321f7ca6083ce15b6aa5bf89de6600e649)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x
Hi Maxime,
On Mon, Nov 22, 2021 at 7:35 PM Maxime Ripard wrote:
>
> On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard wrote:
> > >
> > > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > > Some
On 22.11.2021 08:06, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge
Am 16.11.21 um 16:53 schrieb Zack Rusin:
On Nov 16, 2021, at 03:20, Christian König wrote:
Am 16.11.21 um 08:43 schrieb Thomas Hellström:
On 11/16/21 08:19, Christian König wrote:
Am 13.11.21 um 12:26 schrieb Thomas Hellström:
Hi, Zack,
On 11/11/21 17:44, Zack Rusin wrote:
On Wed,
On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > It's perfectly valid to dereference the pointer in atomic_enable, and
> > that patch would consume memory for no particular reason.
>
> Again, I'm not pointing any mistake in dereference and certainly not
> understand about what
On Mon, Nov 22, 2021 at 07:18:17PM +0530, Anshuman Gupta wrote:
> On 2021-11-16 at 21:22:38 +0530, Tilak Tangudu wrote:
> > v1: Enable runtime pm autosuspend by default for Gen12
> > and later versions.
> >
> > v2: Enable runtime pm autosuspend by default for all
> > platforms(Syrjala Ville)
> >
On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> Hi Maxime,
>
> On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output, those
> > > can have an option to
On 22/11/2021 13:57, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.
Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via 304ac8032d3f
("Merge tag
Hi Marek.
On Mon, Nov 22, 2021 at 12:36 PM Jagan Teki wrote:
>
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to
From: Tvrtko Ursulin
This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.
Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via 304ac8032d3f
("Merge tag 'drm-next-2021-11-12' of
Hi Maxime,
On Mon, Nov 22, 2021 at 6:58 PM Maxime Ripard wrote:
>
> On Mon, Nov 22, 2021 at 06:35:58PM +0530, Jagan Teki wrote:
> > On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard wrote:
> > >
> > > On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > > > Get the display mode settings
Hi Maxime,
On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard wrote:
>
> On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> >
> >
On 2021-11-16 at 21:22:38 +0530, Tilak Tangudu wrote:
> v1: Enable runtime pm autosuspend by default for Gen12
> and later versions.
>
> v2: Enable runtime pm autosuspend by default for all
> platforms(Syrjala Ville)
>
> v3: Change commit message(Nikula Jani)
It would require to reorder the
On 28/10/2021 09:48, Matthew Auld wrote:
On 28/10/2021 02:43, Vivi, Rodrigo wrote:
On Wed, 2021-10-27 at 10:48 +0100, Matthew Auld wrote:
On Wed, 27 Oct 2021 at 10:44, Jani Nikula
wrote:
On Wed, 27 Oct 2021, Matthew Auld
wrote:
On Wed, 27 Oct 2021 at 09:58, Jani Nikula
wrote:
On Wed,
On Mon, Nov 22, 2021 at 06:35:58PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > > Get the display mode settings via mode_set bridge function
> > > instead of explicitly de-reference.
> >
> >
1 - 100 of 144 matches
Mail list logo
