On Fri, Oct 08, 2021 at 02:56:29PM -0700, Matt Roper wrote:
From: Tvrtko Ursulin
Add some basic plumbing to support more than one dynamically allocated
struct intel_gt. Up to four gts are supported in i915->gts[], with slot
zero shadowing the existing i915->gt to enable source compatibility wi
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #3 from Lang Yu (lang...@amd.com) ---
Could you please reproduce it on a ubuntu 20.04 system? I didn't reproduce it
on ubuntu 20.04.
And could you please get outputs of following command before rebooting? Thanks!
$ cat /sys/kernel/d
On Fri, Oct 08, 2021 at 02:56:31PM -0700, Matt Roper wrote:
From: Paulo Zanoni
The first step of interrupt handling is to read a tile0 register that
tells us in which tile the interrupt happened; we can then we read the
usual interrupt registers from the appropriate tile.
Note that this is jus
Hi Lyude,
On Mon, Oct 25, 2021 at 09:30:14PM -0400, Lyude Paul wrote:
> topic/amdgpu-dp2.0-mst-2021-10-25:
> UAPI Changes:
> Nope!
>
> Cross-subsystem Changes:
> drm_dp_update_payload_part1() takes a new argument for specifying what the
> VCPI slot start is
>
> Core Changes:
> Make the DP MST he
Enabling the CONFIG_DRM_FBDEV_EMULATION Kconfig symbol can lead to linker
errors, if CONFIG_DRM_KMS_HELPER is built-in but CONFIG_FB as a module.
Because in that case the drm_kms_helper.o object will have references to
symbols that are defined in the fb.ko module, i.e:
$ make bzImage modules
Hi Rob,
Could you please share your opinion on this ?
On Tue, Oct 19, 2021 at 09:39:15PM +0200, Sam Ravnborg wrote:
> > > >
> > > > That will not help validating that new DTs are compliant with the last
> > > > version of the bindings.
> > > >
> > > > We have one tool, and two needs. The tool s
https://bugzilla.kernel.org/show_bug.cgi?id=213983
Christian König (christian.koe...@amd.com) changed:
What|Removed |Added
CC||christian.koe
On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>
> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
> include asm/smp.h here.
>
> Reported-by: kernel test robot
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
Jani, would it make sense to cherry-pick this to -fixes?
On Tue, 26 Oct 2021, Lucas De Marchi wrote:
> On Wed, Oct 13, 2021 at 03:12:55PM +0300, Jani Nikula wrote:
>>On Fri, 08 Oct 2021, Matt Roper wrote:
>>> On a multi-tile platform, each tile has its own registers + GGTT space,
>>> and BAR 0 is extended to cover all of them. Upcoming patches will st
On Tue, 26 Oct 2021 11:36:33 -0400
Harry Wentland wrote:
> On 2021-10-14 15:44, Shankar, Uma wrote:
> >
...
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation
> > matrix.
>
> No mode property here? Is there any hardware with
Hi!
Am 27.10.21 um 08:50 schrieb Arnd Bergmann:
On Wed, Oct 27, 2021 at 8:26 AM Randy Dunlap wrote:
On 10/26/21 11:19 PM, Arnd Bergmann wrote:
On Wed, Oct 27, 2021 at 2:58 AM Randy Dunlap wrote:
This trivial change makes it all build:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/dr
On Tue, 26 Oct 2021 11:02:31 -0400
Harry Wentland wrote:
> On 2021-10-12 17:01, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Pekka Paalanen
> >> Sent: Tuesday, October 12, 2021 5:25 PM
> >> To: Shankar, Uma
> >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.
Hello Rob,
can this patch can go in?
Thank you
David
On Mon, Oct 18 2021 at 08:48:23 -0500, Rob Herring
wrote:
On Sun, 17 Oct 2021 16:43:50 +0200, David Heidelberg wrote:
Conversion of text binding for Adreno GPU to the YAML format.
Signed-off-by: David Heidelberg
---
v2:
- added
On 18/10/2021 17:28, Neil Armstrong wrote:
Call drm_atomic_helper_check_plane_state() from the plane
atomic_check() callback in order to add plane state sanity
checking.
It will permit filtering out totally bad scaling factors, even
if the real check are done later in the atomic commit.
I thin
On 27/10/2021 11:29, Tomi Valkeinen wrote:
On 18/10/2021 17:28, Neil Armstrong wrote:
Call drm_atomic_helper_check_plane_state() from the plane
atomic_check() callback in order to add plane state sanity
checking.
It will permit filtering out totally bad scaling factors, even
if the real check a
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the overlay c
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to c
GPU relocs are gone. There should be no need for this workaround anymore.
Remove it.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuf
On Mon, Oct 25, 2021 at 06:54:34PM +0200, Sam Ravnborg wrote:
> Hi Maxime,
>
> On Mon, Oct 25, 2021 at 05:16:36PM +0200, Maxime Ripard wrote:
> > Hi Sam,
> >
> > On Thu, Oct 21, 2021 at 05:22:55PM +0200, Sam Ravnborg wrote:
> > > Hi Maxime,
> > >
> > > > Let me know what you think,
> > >
> > >
LGTM, Acked-by: Nirmoy Das for the series.
On 10/25/2021 10:05 AM, Christian König wrote:
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 31 ++-
1 file changed, 11 insertions(+), 20 deletions(-)
diff -
On Wed, 27 Oct 2021, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>>
>> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>> include asm/smp.h here.
>>
>> Reported-by: kernel test robot
>> Signed-off-by: Matthew Auld
>> Cc: Thomas Hellström
>
> Ja
On Wed, 27 Oct 2021, Jani Nikula wrote:
> On Wed, 27 Oct 2021, Matthew Auld wrote:
>> On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>>>
>>> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>>> include asm/smp.h here.
>>>
>>> Reported-by: kernel test robot
>>> Signed-off
On Wed, 27 Oct 2021 at 09:58, Jani Nikula wrote:
>
> On Wed, 27 Oct 2021, Matthew Auld wrote:
> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
> >>
> >> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
> >> include asm/smp.h here.
> >>
> >> Reported-by: kernel test robo
On Wed, 27 Oct 2021 at 09:36, Thomas Hellström
wrote:
>
> GPU relocs are gone. There should be no need for this workaround anymore.
> Remove it.
>
> Signed-off-by: Thomas Hellström
I was completely wrong here, sorry. Digging through the git history it
looks like this came from:
Commit 149c84077
Quoting Matthew Brost (2021-10-26 18:51:17)
> On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote:
> > Quoting Matthew Brost (2021-10-25 18:15:09)
> > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> > > > Quoting Matthew Brost (2021-10-22 19:42:19)
> > > > > On Fri,
Gerd,
Can we follow up on this issue?
The main pain point with your suggestion is the fact,
that it will cause VirGL protocol breakage and we would
like to avoid this.
Extending execbuffer ioctl and create_resource ioctl is
more convenient than having the protocol broken.
Blob resources is not
On Wed, 27 Oct 2021, Matthew Auld wrote:
> On Wed, 27 Oct 2021 at 09:58, Jani Nikula wrote:
>>
>> On Wed, 27 Oct 2021, Matthew Auld wrote:
>> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>> >>
>> >> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>> >> include asm/s
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, 27 Oct 2021, Matthew Auld wrote:
> >> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld
> >> > wrote:
> >> >>
> >> >> wbinvd_on_
On Tue, Oct 26, 2021 at 06:08:44PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also e
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on request
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot
Signed-off-by:
This patch series prepares error capture for asynchronous migration,
where the vma pages may not reflect the pages the GPU is currently
executing from but may be several migrations ahead.
The first patch deals with refcounting sg-list so that they don't
disappear under the capture code, which typi
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous m
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
[ Cc'ing Gurchetan Singh ]
> Can we follow up on this issue?
>
> The main pain point with your suggestion is the fact,
> that it will cause VirGL protocol breakage and we would
> like to avoid this.
>
> Extending execbuffer ioctl and create_resource ioctl is
> more convenient than having the pro
Quoting Dave Airlie (2021-10-26 03:34:52)
> On Mon, 25 Oct 2021 at 23:51, Daniel Vetter wrote:
> >
> > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen
> > wrote:
> > >
> > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
> > > Tvrtko will bring added bandwidth and focus to the GT/GEM
On 10/21/21 13:44, Matthew Auld wrote:
In theory if clflush_work_create() somehow fails here, and we don't yet
have mm.pages populated then we end up resetting cache_dirty, which is
likely wrong, since that will potentially skip the flush-on-acquire, if
it was needed.
It looks like intel_user_
On 10/21/21 13:44, Matthew Auld wrote:
We seem to have an unfortunate issue where we arrive from:
i915_gem_object_flush_if_display+0x86/0xd0 [i915]
intel_user_framebuffer_dirty+0x1a/0x50 [i915]
drm_mode_dirtyfb_ioctl+0xfb/0x1b0
Which can be before the pages are populated(and pi
Quoting Matthew Brost (2021-10-25 19:34:04)
> Hide the guc_id and tail fields, for request trace points, behind
> CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> are ABI (maybe?) so don't change them without kernel developers Kconfig
> options.
I've pushed the simple fix to el
On 10/21/21 13:44, Matthew Auld wrote:
Move it next to its partner in crime; gpu_write_needs_clflush.
A motivation in the commit message?
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Otherwise:
Reviewed-by: Thomas Hellström
On 10/21/21 13:44, Matthew Auld wrote:
Should not be needed. Even with non-coherent display, we should be using
device local-memory there, and not system memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Hi AngeloGioacchino,
Thanks for your suggestion.
On Thu, 2021-10-14 at 12:04 +0200, AngeloGioacchino Del Regno wrote:
> > Adds irq interface for multi hardware.
> >
> > Signed-off-by: Yunfei Dong
> > ---
> > .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33
> > +--
> > .../
On Thu, 30 Sep 2021, Daniel Vetter wrote:
> On Mon, Sep 27, 2021 at 09:23:45AM -0700, Kees Cook wrote:
>> On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
>> > From: Arnd Bergmann
>> >
>> > With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
>> >
>> > aarch64-
On Wed, 27 Oct 2021, Javier Martinez Canillas wrote:
> Enabling the CONFIG_DRM_FBDEV_EMULATION Kconfig symbol can lead to linker
> errors, if CONFIG_DRM_KMS_HELPER is built-in but CONFIG_FB as a module.
>
> Because in that case the drm_kms_helper.o object will have references to
> symbols that are
On 10/27/2021 2:53 AM, Geert Uytterhoeven wrote:
Hi George,
On Wed, Oct 27, 2021 at 3:13 AM George Kennedy
wrote:
On 10/26/2021 1:12 PM, Geert Uytterhoeven wrote:
On Tue, Oct 26, 2021 at 5:48 PM George Kennedy
wrote:
On 10/26/2021 10:11 AM, Geert Uytterhoeven wrote:
On Tue, Oct 26, 2021
(+ Tvrtko who was recently added as a drm/i915 co-maintainer)
Quoting Daniel Vetter (2021-01-22 10:40:48)
> On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell
> wrote:
> >
> > Hi Daniel,
> >
> > On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote:
> > >
> > > Hm that has been in drm-intel-gt-n
On Wed, 27 Oct 2021, Jani Nikula wrote:
> On Thu, 30 Sep 2021, Daniel Vetter wrote:
>> On Mon, Sep 27, 2021 at 09:23:45AM -0700, Kees Cook wrote:
>>> On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
>>> > From: Arnd Bergmann
>>> >
>>> > With CONFIG_FB=m and CONFIG_DRM=y, we get a
Hi Jason,
On Wed, Oct 27, 2021 at 10:19 AM jason-jh.lin wrote:
>
> From: Chun-Kuang Hu
>
> CMDQ is used to update display register in vblank period, so
> it should be execute in next 2 vblank. One vblank interrupt
> before send message (occasionally) and one vblank interrupt
> after cmdq done. I
On Wed, Oct 27, 2021 at 1:47 PM Jani Nikula wrote:
> On Thu, 30 Sep 2021, Daniel Vetter wrote:
> > On Mon, Sep 27, 2021 at 09:23:45AM -0700, Kees Cook wrote:
> >> On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
> >> > From: Arnd Bergmann
> >> >
> >> > With CONFIG_FB=m and CONFIG_D
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
Now that we added specific item to our subclassed drm_plane_state
we can add omap_plane_atomic_print_state() helper to dump out our own
driver specific plane state.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Armstrong
---
On 10/27/21 14:18, Arnd Bergmann wrote:
> On Wed, Oct 27, 2021 at 1:47 PM Jani Nikula
> wrote:
[snip]
>> drm_fb_helper.o is not part of drm.ko, it's part of
>> drm_kms_helper.ko. This adds some sort of indirect dependency via DRM
>> which might work, maybe by coincidence, maybe not - but it's c
On 10/27/21 1:43 AM, Laurent Pinchart wrote:
[...]
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvd
Regression found on arm64 gcc-10 and gcc-11 built with defconfig
Following build warnings / errors reported on linux next 20211027.
metadata:
git_describe: next-20211027
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: ae5179317e79 (\"Add linux
On 27/10/2021 14:23, Tomi Valkeinen wrote:
> On 18/10/2021 17:28, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> Now that we added specific item to our subclassed drm_plane_state
>> we can add omap_plane_atomic_print_state() helper to dump out our own
>> driver specific plane state.
>>
>> Sign
On 2021-10-27 04:00, Pekka Paalanen wrote:
> On Tue, 26 Oct 2021 11:36:33 -0400
> Harry Wentland wrote:
>
>> On 2021-10-14 15:44, Shankar, Uma wrote:
>>>
>
...
>> FWIW, AMD HW (depending on generation) can do these operations
>> (in this order):
>>
>> 1) 1D LUT (fixed or PWL programmable)
>
On 18/10/2021 17:28, Neil Armstrong wrote:
From: Benoit Parrot
If the drm_plane has a source width that's greater than the max width
supported by a single hw overlay, then we assign a 'r_overlay' to it in
omap_plane_atomic_check().
Both overlays should have the capabilities required to handle
On Wed, Oct 27, 2021 at 2:38 PM Javier Martinez Canillas
wrote:
> >
> > This is something we can't easily express in Kconfig, as we can't add the
> > dependency to a symbol that only gets selected by other drivers, which
> > is why the dependency has to be in the user-visible symbol,
> > in this c
On Wed, 27 Oct 2021, Javier Martinez Canillas wrote:
> On 10/27/21 14:18, Arnd Bergmann wrote:
>> On Wed, Oct 27, 2021 at 1:47 PM Jani Nikula
>> wrote:
>
> [snip]
>
>>> drm_fb_helper.o is not part of drm.ko, it's part of
>>> drm_kms_helper.ko. This adds some sort of indirect dependency via DRM
>
On 10/27/21 14:52, Arnd Bergmann wrote:
[snip]
>>
>> @@ -104,7 +105,6 @@ config DRM_FBDEV_EMULATION
>> bool "Enable legacy fbdev support for your modesetting driver"
>> depends on DRM
>> depends on FB
>> - select DRM_KMS_HELPER
>> select FB_CFB_FILLRECT
>>
On Wed, 27 Oct 2021, Arnd Bergmann wrote:
> On a related note, I did manage to sort out the backlight dependency issue
> (intel_panel.c:(.text+0x2f58): undefined reference to
> `backlight_device_register'),
> but haven't sent that one again yet, but I can if you like. This one changes
> DRM_I915 a
On Wed, 27 Oct 2021, Arnd Bergmann wrote:
> On Wed, Oct 27, 2021 at 2:38 PM Javier Martinez Canillas
> wrote:
>> >
>> > This is something we can't easily express in Kconfig, as we can't add the
>> > dependency to a symbol that only gets selected by other drivers, which
>> > is why the dependency
On Fri, 15 Oct 2021 16:33:43 +
Simon Ser wrote:
> In drm_connector_register, use drm_sysfs_connector_hotplug_event
> instead of drm_sysfs_hotplug_event, because the hotplug event
> only updates a single connector.
>
> Signed-off-by: Simon Ser
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
On 10/27/21 14:55, Jani Nikula wrote:
[snip]
>> Why the dependency has to be in a user-visible symbol? What could be the
>> problem with having something like:
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index cea777ae7fb9..f80b404946ca 100644
>> --- a/drivers/gpu/drm/
On 10/27/21 14:18, Arnd Bergmann wrote:
[snip]
> Right, how about this change on top?
>
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -117,9 +117,8 @@ config DRM_DEBUG_MODESET_LOCK
>
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modese
On Wed, Oct 27, 2021 at 3:06 PM Jani Nikula wrote:
> On Wed, 27 Oct 2021, Arnd Bergmann wrote:
> > This fails because of all the other drivers that try to 'select
> > DRM_KMS_HELPER'.
> > Kconfig will now complain about a symbol that gets selected while its
> > dependencies
> > are not met.
> >
On Wednesday, October 27th, 2021 at 15:15, Pekka Paalanen
wrote:
> On Fri, 15 Oct 2021 16:33:43 +
> Simon Ser wrote:
>
> > In drm_connector_register, use drm_sysfs_connector_hotplug_event
> > instead of drm_sysfs_hotplug_event, because the hotplug event
> > only updates a single connector.
From: Arnd Bergmann
Selecting FB_DDC currently turns on CONFIG_I2C implicitly,
which is often not desired and can lead to circular dependencies.
Change this to a 'depends on' and change all drivers that
rely on FB_DDC to have an appropriate I2C dependency as well.
Signed-off-by: Arnd Bergmann
From: Arnd Bergmann
Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
make any driver that needs it have a dependency on the class device
being available, to prevent circular dependencies.
This is the same way that the backlight is already treated for the DRM
subsystem
From: Arnd Bergmann
The i915 driver can use the backlight subsystem as an option, and usually
selects it when CONFIG_ACPI is set. However it is possible to configure
a kernel with modular backlight classdev support and a built-in i915
driver, which leads to a linker error:
drivers/gpu/drm/i915/d
On Wed, Oct 27, 2021 at 3:28 PM Arnd Bergmann wrote:
>
> Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> make any driver that needs it have a dependency on the class device
> being available, to prevent circular dependencies.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On 10/27/21 15:25, Arnd Bergmann wrote:
[snip]
> That's not going to help in this case, the way the helper functions work is
> that
> you select them as needed, and you avoid the other dependencies. This part
> works fine.
>
> We could probably get rid of this symbol by just making it an uncond
On Sun, Oct 24, 2021 at 05:50:10PM +0200, Hans de Goede wrote:
> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>
> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for a Cherry
> Trail tablet. It deviates from the typ
On Wed, 27 Oct 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The i915 driver can use the backlight subsystem as an option, and usually
> selects it when CONFIG_ACPI is set. However it is possible to configure
> a kernel with modular backlight classdev support and a built-in i915
> driver,
https://bugzilla.kernel.org/show_bug.cgi?id=213983
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christian König from comment #3)
> Well what happens here is that a buffer object is released while it is
> pinned and TTM now warns about doing stuff like that.
>
> The key po
On Wed, Oct 27, 2021 at 3:41 PM Jani Nikula wrote:
> > @@ -16,10 +18,6 @@ config DRM_I915
> > select IRQ_WORK
> > # i915 depends on ACPI_VIDEO when ACPI is enabled
> > # but for select to work, need to select ACPI_VIDEO's dependencies,
> > ick
>
> The comment needs updating as w
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Lang Yu from comment #3)
> Could you please reproduce it on a ubuntu 20.04 system? I didn't reproduce
> it on ubuntu 20.04.
Not on this machine unfortunately. I need it 24/7 as
Hi Marc
+Joe Perches
On 10/27/21 8:11 AM, Patrice CHOTARD wrote:
> Hi Marc
>
> On 10/20/21 1:39 PM, Marc Zyngier wrote:
>> On Wed, 20 Oct 2021 08:45:02 +0100,
>> Krzysztof Kozlowski wrote:
>>>
>>> On 20/10/2021 08:50, patrice.chot...@foss.st.com wrote:
From: Patrice Chotard
Not
On Wed, 27 Oct 2021 14:56:35 +0100,
Patrice CHOTARD wrote:
>
> Hi Marc
>
> +Joe Perches
>
> On 10/27/21 8:11 AM, Patrice CHOTARD wrote:
> > Hi Marc
> >
> > On 10/20/21 1:39 PM, Marc Zyngier wrote:
> >> On Wed, 20 Oct 2021 08:45:02 +0100,
> >> Krzysztof Kozlowski wrote:
> >>>
> >>> On 20/10/20
On 2021-10-26 6:54 a.m., Christian König wrote:
Am 26.10.21 um 04:33 schrieb Andrey Grodzovsky:
On 2021-10-25 3:56 p.m., Christian König wrote:
In general I'm all there to get this fixed, but there is one major
problem: Drivers don't expect the lock to be dropped.
I am probably missing so
Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky:
[SNIP]
Let me please know if I am still missing some point of yours.
Well, I mean we need to be able to handle this for all drivers.
For sure, but as i said above in my opinion we need to change only for
those drivers that don't use the _lo
https://bugzilla.kernel.org/show_bug.cgi?id=214847
Bug ID: 214847
Summary: [radeon] UBSAN shows several null-ptr-deref in
drm/radeon/atom.c, radeon_atombios.c,
atombios_encoders.c, atombios_crtc.c
Product: Drivers
https://bugzilla.kernel.org/show_bug.cgi?id=214847
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 299333
--> https://bugzilla.kernel.org/attachment.cgi?id=299333&action=edit
kernel config (kernel 5.15-rc7, AMD Ryzen 9 5950X)
--
You may reply to this email to add a
On Wed, Oct 13, 2021 at 04:04:13PM -0400, Thelford Williams wrote:
> Size can be any value and is user controlled resulting in overwriting the
> 40 byte array wr_buf with an arbitrary length of data from buf.
>
> Signed-off-by: Thelford Williams
> Signed-off-by: Alex Deucher
The fix works, but
On Wed, Oct 27, 2021 at 03:27:12PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Selecting FB_DDC currently turns on CONFIG_I2C implicitly,
> which is often not desired and can lead to circular dependencies.
>
> Change this to a 'depends on' and change all drivers that
> rely on FB_DDC t
On 2021-10-27 10:34 a.m., Christian König wrote:
Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky:
[SNIP]
Let me please know if I am still missing some point of yours.
Well, I mean we need to be able to handle this for all drivers.
For sure, but as i said above in my opinion we need to c
Am 27.10.21 um 16:47 schrieb Andrey Grodzovsky:
On 2021-10-27 10:34 a.m., Christian König wrote:
Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky:
[SNIP]
Let me please know if I am still missing some point of yours.
Well, I mean we need to be able to handle this for all drivers.
For sure
On Tue, Oct 12, 2021 at 03:09:00PM +0300, Gal Pressman wrote:
> Hey all,
>
> This is a followup to my previous RFCs [1][2], which now adds a new api
> to the RDMA subsystem that allows drivers to get a pinned dmabuf memory
> region without requiring an implementation of the move_notify callback.
>
On Wed, Oct 27, 2021 at 08:57:48AM +0100, Matthew Auld wrote:
On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
include asm/smp.h here.
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Ja
On Sat, 23 Oct 2021, Len Baker wrote:
> Sorry, but I'm missing something here. In linux-next this is the commit
> history of include/linux/stddef.h file:
>
> 3080ea5553cc stddef: Introduce DECLARE_FLEX_ARRAY() helper
> 50d7bd38c3aa stddef: Introduce struct_group() helper macro
> e7f18c22e6be stdde
On Tue, 26 Oct 2021 at 00:45, Dmitry Osipenko wrote:
>
> GENPD core now can set up domain's performance state properly while device
> is RPM-suspended. Runtime PM of a device must be enabled during setup
> because GENPD checks whether device is suspended and check doesn't work
> while RPM is disab
On Wed, 2021-10-27 at 18:14 +0530, Naresh Kamboju wrote:
> Regression found on arm64 gcc-10 and gcc-11 built with defconfig
> Following build warnings / errors reported on linux next 20211027.
>
> metadata:
> git_describe: next-20211027
> git_repo: https://gitlab.com/L
On 10/27/2021 2:53 AM, Geert Uytterhoeven wrote:
Hi George,
On Wed, Oct 27, 2021 at 3:13 AM George Kennedy
wrote:
On 10/26/2021 1:12 PM, Geert Uytterhoeven wrote:
On Tue, Oct 26, 2021 at 5:48 PM George Kennedy
wrote:
On 10/26/2021 10:11 AM, Geert Uytterhoeven wrote:
On Tue, Oct 26, 2021
On 2021-10-27 10:39, Guenter Roeck wrote:
> On Wed, Oct 13, 2021 at 04:04:13PM -0400, Thelford Williams wrote:
>> Size can be any value and is user controlled resulting in overwriting the
>> 40 byte array wr_buf with an arbitrary length of data from buf.
>>
>> Signed-off-by: Thelford Williams
>> S
Hi Simon,
On Mon, Oct 18, 2021 at 08:47:30AM +, Simon Ser wrote:
> If an hotplug event only updates a single connector, use
> drm_kms_helper_connector_hotplug_event instead of
> drm_kms_helper_hotplug_event.
>
> Changes in v4:
> - Simplify loop logic (Ville, Sam)
> - Update drm_connector_help
On Tue, 26 Oct 2021 at 00:46, Dmitry Osipenko wrote:
>
> Depending on hardware version, Tegra SoC may require a higher voltages
> during resume from system suspend, otherwise hardware will crash. Set
> SoC voltages to a nominal levels during suspend.
>
> Signed-off-by: Dmitry Osipenko
I don't un
On 10/27/21 8:22 AM, Harry Wentland wrote:
On 2021-10-27 10:39, Guenter Roeck wrote:
On Wed, Oct 13, 2021 at 04:04:13PM -0400, Thelford Williams wrote:
Size can be any value and is user controlled resulting in overwriting the
40 byte array wr_buf with an arbitrary length of data from buf.
Sign
On Tue, 26 Oct 2021 at 00:45, Dmitry Osipenko wrote:
>
> This series adds runtime PM support to Tegra drivers and enables core
> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>
> All patches in this series are interdependent and should go via Tegra tree
> for simplicity.
>
>
On 10/26/2021 7:24 AM, Nathan Chancellor wrote:
Clang warns:
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:162:6: error: variable 'commit' is
uninitialized when used here [-Werror,-Wuninitialized]
if (commit)
^~
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:106:32: note: initial
In theory if clflush_work_create() somehow fails here, and we don't yet
have mm.pages populated then we end up resetting cache_dirty, which is
likely wrong, since that will potentially skip the flush-on-acquire, if
it was needed.
It looks like intel_user_framebuffer_dirty() can arrive here before
1 - 100 of 207 matches
Mail list logo
