From: suijingfeng
There is a Vivante GC1000 V5037 in LS2K1000 and LS7A1000,
the gpu in those chip is a PCI device and it have 2D and 3D
in the same core. Therefore, this patch try to provide PCI
device driver wrapper for it by mimic the platform counterpart
one.
LS7A1000 is a bridge
From: suijingfeng
There is a vivante gpu (GC1000 V5037) in ls2k1000,
but it is pci device not platform device.
ls2k1000 is dual-core mips64 cpu made by loongson.
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
There is a Vivante GC1000 V5037 in LS2K1000 and LS7A1000,
the gpu is a PCI device and it have 2D and 3D in the same core.
Therefore, this patch try to provide PCI device driver wrapper
for it by mimic the platform counterpart.
LS7A1000 is a bridge chip, this bridge chip typically use
Hi Jakub,
On Fri, 19 Nov 2021 19:52:53 -0800 Jakub Kicinski wrote:
> cgroup.h (therefore swap.h, therefore half of the universe)
> includes bpf.h which in turn includes module.h and slab.h.
> Since we're about to get rid of that dependency we need
> to clean things up.
>
> Signed-off-by: Jakub
>
>
> On Fri, Nov 19, 2021 at 3:37 PM Akhil R wrote:
> >
> > Add support for ACPI based device registration so that the driver can
> > be also enabled through ACPI table.
>
> the ACPI
>
> ...
>
> > + if (has_acpi_companion(i2c_dev->dev)) {
>
> You are checkin for the companion and
On 21-11-19 19:52:53, Jakub Kicinski wrote:
> cgroup.h (therefore swap.h, therefore half of the universe)
> includes bpf.h which in turn includes module.h and slab.h.
> Since we're about to get rid of that dependency we need
> to clean things up.
>
> Signed-off-by: Jakub Kicinski
> ---
> static
cgroup.h (therefore swap.h, therefore half of the universe)
includes bpf.h which in turn includes module.h and slab.h.
Since we're about to get rid of that dependency we need
to clean things up.
Signed-off-by: Jakub Kicinski
---
CC: ax...@kernel.dk
CC: maarten.lankho...@linux.intel.com
CC:
On 18/11/2021 18.19, Thomas Zimmermann wrote:
Hi
Am 17.11.21 um 15:58 schrieb Hector Martin:
@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
module_platform_driver(simpledrm_platform_driver);
+static int __init simpledrm_init(void)
+{
+ struct
On Fri, Nov 19, 2021 at 9:38 AM Rob Clark wrote:
> On Thu, Nov 18, 2021 at 12:53 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 16, 2021 at 06:31:10PM -0800, Gurchetan Singh wrote:
> > > On Tue, Nov 16, 2021 at 7:43 AM Daniel Vetter wrote:
> > >
> > > > On Mon, Nov 15, 2021 at 07:26:14PM +,
Thanks for the patch.
Reviewed-by: Deepak Rawat
I will push this to drm-fixes, let me know otherwise.
Deepak
On Fri, 2021-11-19 at 12:29 +0100, Mohammed Gamal wrote:
> The Hyper-V DRM driver tries to free MMIO region on removing
> the device regardless of VM type, while Gen1 VMs don't use
Hi,
On Fri, Nov 19, 2021 at 2:47 PM Rob Clark wrote:
>
> +void msm_devfreq_boost(struct msm_gpu *gpu, unsigned factor)
> +{
> + struct msm_gpu_devfreq *df = >devfreq;
> + unsigned long freq;
> +
> + freq = get_freq(gpu);
> + freq *= factor;
> + freq /= HZ_PER_KHZ;
Hi,
On Fri, Nov 19, 2021 at 2:47 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This was supposed to be a relative timer, not absolute.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Douglas
On Fri, 19 Nov 2021 15:46:31 -0700
jim.cro...@gmail.com wrote:
> > So I could see us supporting subsystem specific trace buffer output
> > via dynamic debug here. We could add new dev_debug() variants that
> > allow say a trace buffer to be supplied. So in that way subsystems
> > could 'opt-out'
On Fri, Nov 19, 2021 at 2:46 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This was supposed to be a relative timer, not absolute.
>
Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
> 1
Hi Maxime,
Thank you for the patch.
On Tue, Nov 16, 2021 at 03:35:03PM +0100, Maxime Ripard wrote:
> Following the previous patch, let's introduce a generic panel-lvds
> binding that documents the panels that don't have any particular
> constraint documented.
>
> Signed-off-by: Maxime Ripard
>
From: Rob Clark
This was supposed to be a relative timer, not absolute.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index
From: Rob Clark
Re-work the boost and idle clamping to use PM QoS requests instead, so
they get aggreggated with other requests (such as cooling device).
This does have the minor side-effect that devfreq sysfs min_freq/
max_freq files now reflect the boost and idle clamping, as they show
On Fri, Nov 19, 2021 at 9:21 AM 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:
> >>> On Fri, 12 Nov 2021 10:08:41 -0500
> >>> Jason Baron wrote:
> >>>
>
Hi Maxime,
Thank you for the patch.
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 panel-lvds binding.
>
> That last binding
The pull request you sent on Fri, 19 Nov 2021 15:32:38 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-11-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ad44518affc66611644654cec9c165eb4e848030
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Daniel,
On Fri, Nov 19, 2021 at 11:01:18AM +0100, Daniel Vetter wrote:
> On Thu, Nov 18, 2021 at 11:30:43AM -0800, Brian Norris wrote:
> > On Thu, Nov 18, 2021 at 10:05:11AM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 17, 2021 at 02:48:40PM -0800, Brian Norris wrote:
> > > > ---
On Thu, Nov 18, 2021 at 12:53 AM Daniel Vetter wrote:
>
> On Tue, Nov 16, 2021 at 06:31:10PM -0800, Gurchetan Singh wrote:
> > On Tue, Nov 16, 2021 at 7:43 AM Daniel Vetter wrote:
> >
> > > On Mon, Nov 15, 2021 at 07:26:14PM +, Kasireddy, Vivek wrote:
> > > > Hi Daniel, Greg,
> > > >
> > > >
On Wed, Nov 17, 2021 at 02:16:13PM +, Chris Wilson wrote:
Quoting Andi Shyti (2021-11-17 13:34:56)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a9727447c0379..4bfedc04f5c70 100644
---
On 18/11/2021 13:02, Thomas Hellström wrote:
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
On 18/11/2021 13:02, Thomas Hellström wrote:
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
On Fri, Nov 19, 2021 at 08:36:56AM -0800, Souza, Jose wrote:
> On Tue, 2021-11-16 at 09:48 -0800, Matt Roper wrote:
> > From: Matt Atwood
> >
> > Extend existing workaround 1409120013 to DG2.
> >
> > Cc: José Roberto de Souza
> > Signed-off-by: Matt Atwood
> > Signed-off-by: Matt Roper
> >
On Fri, Nov 19, 2021 at 05:35:53PM +0100, Christian König wrote:
> Hi Thomas,
>
> Am 19.11.21 um 15:28 schrieb Thomas Hellström:
> > Hi, Christian,
> >
> > We have an upcoming use-case in i915 where one solution would be
> > sparsely populated TTM bos.
> >
> > We had that at one point where
On 11/18/2021 5:20 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-11-09 13:38:13)
From: Kuogee Hsieh
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and
Hi,
On Fri, Nov 19, 2021 at 8:39 AM Rob Clark wrote:
>
> On Fri, Nov 19, 2021 at 1:54 AM Pekka Paalanen wrote:
> >
> > On Thu, 18 Nov 2021 15:30:38 -0800
> > Rob Clark wrote:
> >
> > > On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Wed, 17 Nov 2021 14:48:40
On Fri, Nov 19, 2021 at 1:54 AM Pekka Paalanen wrote:
>
> On Thu, 18 Nov 2021 15:30:38 -0800
> Rob Clark wrote:
>
> > On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 17 Nov 2021 14:48:40 -0800
> > > Brian Norris wrote:
> > >
> > > > A variety of applications have
On Tue, 2021-11-16 at 09:48 -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2
Hi Thomas,
Am 19.11.21 um 15:28 schrieb Thomas Hellström:
Hi, Christian,
We have an upcoming use-case in i915 where one solution would be
sparsely populated TTM bos.
We had that at one point where ttm_tt pages were allocated on demand,
but this time we'd rather be looking at multiple
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:
>>> On Fri, 12 Nov 2021 10:08:41 -0500
>>> Jason Baron wrote:
>>>
On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
> On Thu, Nov
On Fri, Nov 19, 2021 at 04:04:28PM +, Simon Ser wrote:
> On Friday, November 19th, 2021 at 16:53, Daniel Vetter
> wrote:
>
> > Random idea ... should we perhaps let userspace connect the boosting? I.e.
> > we do a bunch of standardized boost targets (render clocks, display sr
> > exit), and
On Friday, November 19th, 2021 at 16:53, Daniel Vetter wrote:
> Random idea ... should we perhaps let userspace connect the boosting? I.e.
> we do a bunch of standardized boost targets (render clocks, display sr
> exit), and userspace can then connect it to whichever input device it
> wants to?
On Thu, Nov 18, 2021 at 05:59:14PM +0100, Sebastian Andrzej Siewior wrote:
> This is a revert of commits
>d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
> irqsafe")
>6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
> timeline->mutex")
>
On Thu, Nov 18, 2021 at 11:38:01AM +0100, Maxime Ripard wrote:
> Hi,
>
> This is a follow-up of the work to support the interactions between the
> hotplug
> and the scrambling support for vc4:
>
> https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/
>
Hi Bernard!
Dne torek, 16. november 2021 ob 03:14:49 CET je Bernard Zhao napisal(a):
> This change is to cleanup the code a bit.
>
> Signed-off-by: Bernard Zhao
Acked-by: Jernej Skrabec
Best regards,
Jernej
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
> 1 file changed, 1
On Fri, Nov 19, 2021 at 12:38:41PM +0200, Pekka Paalanen wrote:
> On Thu, 18 Nov 2021 17:46:10 -0800
> Brian Norris wrote:
>
> > Hi Pekka,
> >
> > Thanks for the thoughts and review. I've tried to respond below:
> >
> > On Thu, Nov 18, 2021 at 12:39:28PM +0200, Pekka Paalanen wrote:
> > > On
On Fri, Nov 19, 2021 at 11:54:19AM +0200, Pekka Paalanen wrote:
> On Thu, 18 Nov 2021 15:30:38 -0800
> Rob Clark wrote:
>
> > On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 17 Nov 2021 14:48:40 -0800
> > > Brian Norris wrote:
> > >
> > > > A variety of applications
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
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,
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
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
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 ---
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.
Patches 1/6 deals with accessing and waiting for the TTM moving
fence
Il 19/11/21 14:19, Robert Foss ha scritto:
Hey Angelo,
On Wed, 10 Nov 2021 at 13:46, AngeloGioacchino Del Regno
wrote:
Il 10/11/21 13:44, Dafna Hirschfeld ha scritto:
On 02.11.21 11:36, AngeloGioacchino Del Regno wrote:
In preparation for varying the poweron error handling in function
Get the display mode settings via mode_set bridge
function instead of explicitly de-reference.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
Replace atomic version of the pre_enable/enable/post_disable
operations to continue the transition to the atomic API.
Also added default drm atomic operations for duplicate, destroy
and reset state API's in order to have smooth transition on
atomic API's.
Tested on Allwinner R16/R40 DSI.
On Fri, Nov 19, 2021 at 3:37 PM Akhil R wrote:
>
> Add support for ACPI based device registration so that the driver
> can be also enabled through ACPI table.
the ACPI
...
> + if (has_acpi_companion(i2c_dev->dev)) {
You are checkin for the companion and using a handle, why not check
for
https://bugzilla.kernel.org/show_bug.cgi?id=211807
--- Comment #15 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Daan from comment #14)
> I also had this in my logs yesterday, right before my system locked
> completely (had to do a hard reset).
That's probably coincidence. I get these
On Wed, 17 Nov 2021 15:08:58 +0100
Maxime Ripard wrote:
> From: Dave Stevenson
>
> Adds a format that is 3 10bit YUV 4:2:0 samples packed into
> a 32bit work (with 2 spare bits).
>
> Supported on Broadcom BCM2711 chips.
>
> Signed-off-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
> ---
Hi, Christian,
We have an upcoming use-case in i915 where one solution would be
sparsely populated TTM bos.
We had that at one point where ttm_tt pages were allocated on demand,
but this time we'd rather be looking at multiple struct ttm_resources
per bo and those resources could be from
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, 2021 at 08:57:17AM -0500, George
https://bugzilla.kernel.org/show_bug.cgi?id=213391
Lahfa Samy (s...@lahfa.xyz) changed:
What|Removed |Added
Status|NEW |RESOLVED
Hey Angelo,
On Wed, 10 Nov 2021 at 13:46, AngeloGioacchino Del Regno
wrote:
>
> Il 10/11/21 13:44, Dafna Hirschfeld ha scritto:
> >
> >
> > On 02.11.21 11:36, AngeloGioacchino Del Regno wrote:
> >> In preparation for varying the poweron error handling in function
> >> ps8640_bridge_poweron(),
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be seperated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when
From: Zhi Wang
To support the early init of GVT-g, which will be put in i915, after the
GVT-g is moved into a dedicated module, we need to save the MMIO snapshot
in the early init of GVT-g, when the HW hasn't been touched.
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas
Hi Arnd,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vkoul-dmaengine/next]
[also build test WARNING on tiwai-sound/for-next staging/staging-testing
linus/master v5.16-rc1 next-2028]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Daan (daandelomba...@gmail.com) changed:
What|Removed |Added
CC|
The Hyper-V DRM driver tries to free MMIO region on removing
the device regardless of VM type, while Gen1 VMs don't use MMIO
and hence causing the kernel to crash on a NULL pointer dereference.
Fix this by making deallocating MMIO only on Gen2 machines and implement
removal for Gen1
Fixes:
On Fri, Nov 19, 2021 at 11:20:13AM +0100, Javier Martinez Canillas wrote:
> [ adding gregkh to Cc list for drivers/video/console ]
>
> On 11/12/21 14:32, Javier Martinez Canillas wrote:
> > The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
> > but the exported
On Thu, 18 Nov 2021 14:14:16 +0300, Dan Carpenter wrote:
> The ->gem_create_object() functions are supposed to return NULL if there
> is an error. None of the callers expect error pointers so returing one
> will lead to an Oops. See drm_gem_vram_create(), for example.
>
>
Applied to
On Wed, 17 Nov 2021 09:01:45 +0800, Joel Stanley wrote:
> Before the drm driver had support for this file there was a driver that
> exposed the contents of the vga password register to userspace. It would
> present the entire register instead of interpreting it.
>
> The drm implementation chose
On Thu, 18 Nov 2021 17:46:10 -0800
Brian Norris wrote:
> Hi Pekka,
>
> Thanks for the thoughts and review. I've tried to respond below:
>
> On Thu, Nov 18, 2021 at 12:39:28PM +0200, Pekka Paalanen wrote:
> > On Wed, 17 Nov 2021 14:48:40 -0800
> > Brian Norris wrote:
> >
> > > A variety of
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, 2021 at 08:57:17AM -0500, George Kennedy wrote:
> > > > Do a sanity check on
Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道：
>
> On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道：
> > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms:
> > > Convert to
> > > atomic helpers") introduced a number of issues
[ adding gregkh to Cc list for drivers/video/console ]
On 11/12/21 14:32, Javier Martinez Canillas wrote:
> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>
> It makes much more sense for the
Hello,
syzbot found the following issue on:
HEAD commit:fa55b7dcdc43 Linux 5.16-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fe2569b0
kernel config: https://syzkaller.appspot.com/x/.config?x=6d3b8fd1977c1e73
dashboard link:
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, 2021 at 08:57:17AM -0500, George Kennedy wrote:
> > > Do a sanity check on struct drm_format_info hsub and vsub values to
> > > avoid divide by zero.
On Thu, Nov 18, 2021 at 11:30:43AM -0800, Brian Norris wrote:
> Hi Daniel,
>
> Thanks for the review. Lots to address elsewhere, but I can respond
> here first:
>
> On Thu, Nov 18, 2021 at 10:05:11AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 17, 2021 at 02:48:40PM -0800, Brian Norris wrote:
>
> -Original Message-
> From: Tangudu, Tilak
> Sent: Tuesday, November 16, 2021 9:23 PM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Tangudu, Tilak ; Ewins, Jon
> ; Vivi, Rodrigo ; Nilawar, Badal
> ; Gupta, Anshuman ;
> Syrjala, Ville
> Subject: [PATCH
On Thu, 18 Nov 2021 15:30:38 -0800
Rob Clark wrote:
> On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
> >
> > On Wed, 17 Nov 2021 14:48:40 -0800
> > Brian Norris wrote:
> >
> > > A variety of applications have found it useful to listen to
> > > user-initiated input events to make
On Thu, Nov 18, 2021 at 11:23:32AM +0100, Michel Dänzer wrote:
> On 2021-11-08 17:00, Daniel Vetter wrote:
> > On Mon, Nov 08, 2021 at 04:34:53PM +0100, Jocelyn Falempe wrote:
> >> When using Xorg/Logind and an external monitor connected with an MST dock.
> >> After disconnecting the external
On Thu, Nov 18, 2021 at 03:00:15PM -0500, George Kennedy wrote:
>
>
> On 10/29/2021 10:14 AM, Brian Starkey wrote:
> > Hi,
> >
> > On Fri, Oct 29, 2021 at 09:15:28AM -0400, George Kennedy wrote:
> > > Asking if you have any input on how to deal with hsub and vsub = zero?
> > That's just a
On Thu, Oct 28, 2021 at 05:04:19PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 08:57:17AM -0500, George Kennedy wrote:
> > Do a sanity check on struct drm_format_info hsub and vsub values to
> > avoid divide by zero.
> >
> > Syzkaller reported a divide error in framebuffer_check() when
Hi Joel,
> Before the drm driver had support for this file there was a driver
> that exposed the contents of the vga password register to userspace.
> It would present the entire register instead of interpreting it.
>
> The drm implementation chose to mask of the lower bit, without
> explaining
78 matches
Mail list logo
