On Wed, Sep 08, 2021 at 06:37:13PM -0700, Gurchetan Singh wrote:
> The plumbing is all here to do this. Since we always use the
> default fence context when allocating a fence, this makes no
> functional difference.
>
> We can't process just the largest fence id anymore, since it's
> it's
On 9/13/21 9:15 AM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration,
Hi,
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -60,6 +60,8 @@
> */
> #define VIRTIO_GPU_F_RESOURCE_BLOB 3
>
> +#define VIRTIO_GPU_F_RELEASE_FENCE4
> +
> enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_UNDEFINED = 0,
Where is the
Hi Vlastimil,
On 14/9/21 7:03 pm, Vlastimil Babka wrote:
On 9/10/21 16:10, Imran Khan wrote:
This change is in response to discussion at [1].
The patch has been created on top of my earlier changes [2] and [3].
If needed I can resend all of these patches together, though my
earlier patches
Quoting Doug Anderson (2021-09-14 19:17:03)
> Hi,
>
> On Tue, Sep 14, 2021 at 5:29 PM Stephen Boyd wrote:
> >
> > Quoting Philip Chen (2021-09-14 16:28:44)
> > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > > index
Hi,
On Tue, Sep 14, 2021 at 5:29 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-14 16:28:44)
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index e340af381e05..8d3e7a147170 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
This patch series consolidates the changes submitted and reviewed at [1]
and [2].
The patches at [1] and [2] were submitted separarely, but they have some
inter dependency (later patches were created on top of earlier ones).
As both sets are still under review, I have put them in a single
change
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
To print a stack entries, users of stackdepot, first
use stack_depot_fetch to get a list of stack entries
and then use stack_trace_print to print this list.
Provide a helper in stackdepot to print stack entries
based on stackdepot handle.
Also change above mentioned users to use this helper.
stack_depot_save allocates slabs that will be used for storing
objects in future.If this slab allocation fails we may get to
a situation where space allocation for a new stack_record fails,
causing stack_depot_save to return 0 as handle.
If user of this handle ends up invoking stack_depot_fetch
On Tue, Sep 14, 2021 at 10:53 AM Chia-I Wu wrote:
> ,On Mon, Sep 13, 2021 at 6:57 PM Gurchetan Singh
> wrote:
> >
> >
> >
> >
> > On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
> >>
> >> .
> >>
> >> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
> >> wrote:
> >> >
> >> >
> >> >
> >> > On
From: Jackie Liu
CONFIG_VGA_CONSOLE=n and CONFIG_MDA_CONSOLE=n will cause vt_buffer.h not
include .
But if we set CONFIG_MDA_CONSOLE=m, mdacon.c include
is in front of include . VT_BUF_HAVE_MEMSETW is not defined,
so vt_buffer.h will define a scr_memsetw, after that, vga.h also define
a
On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula wrote:
>
> On Tue, 14 Sep 2021, Lyude Paul wrote:
> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> >> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
> >> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> >> >
Quoting Philip Chen (2021-09-14 16:28:45)
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 8d3e7a147170..dc349d729f5a 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -117,6 +144,129
Quoting Philip Chen (2021-09-14 16:28:44)
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index e340af381e05..8d3e7a147170 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -368,6 +396,12 @@
Borislav Petkov writes:
> On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
>> Introduce a powerpc version of the cc_platform_has() function. This will
>> be used to replace the powerpc mem_encrypt_active() implementation, so
>> the implementation will initially only support the
Hi
On Mon, Sep 13, 2021 at 4:43 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
> >
> > Implement the first version of AUX support, which will be useful as
> > we expand the driver to support varied use cases.
> >
> > WARNING: This patch is not fully
Quoting Philip Chen (2021-09-14 16:28:43)
> Use dev_err_probe() to add logs for error cases at probing time.
>
> Signed-off-by: Philip Chen
> ---
>
Can you use a cover-letter for more than one patch series?
> (no changes since v1)
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 22
On Fri, Sep 10, 2021 at 10:52:57AM -0700, Lucas De Marchi wrote:
> On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote:
> > We shouldn't be using debugfs_ namespace for this functionality. Rename
> > debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make
> > functions, defines
On Tue, Sep 14, 2021 at 04:25:08PM +0200, Daniel Vetter wrote:
> On Mon, Sep 13, 2021 at 10:09:54PM -0700, Matthew Brost wrote:
> > An error capture allocates memory, memory allocations depend on resets,
> > and resets need to flush the G2H handlers to seal several races. If the
> > error capture
On Tue, Sep 14, 2021 at 04:29:21PM +0200, Daniel Vetter wrote:
> On Mon, Sep 13, 2021 at 10:09:56PM -0700, Matthew Brost wrote:
> > From: John Harrison
> >
> > When i915 receives a context reset notification from GuC, it triggers
> > an error capture before resetting any outstanding requsts of
Hi, Doug
Thanks for the review.
I fixed the nits you pointed out in v3.
PTAL.
On Mon, Sep 13, 2021 at 5:32 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
> >
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> >
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Reviewed-by: Douglas Anderson
Signed-off-by: Philip Chen
---
Changes in v3:
- Fix the nits from v2 review
Changes in v2:
- Add separate reg map config per page
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
Signed-off-by: Philip Chen
---
Changes in v3:
- Verify with HW and thus remove WARNING from the patch description
- Fix the reg names to better match the manual
- Fix
Use dev_err_probe() to add logs for error cases at probing time.
Signed-off-by: Philip Chen
---
(no changes since v1)
drivers/gpu/drm/bridge/parade-ps8640.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
On 9/14/2021 07:29, Daniel Vetter wrote:
On Mon, Sep 13, 2021 at 10:09:56PM -0700, Matthew Brost wrote:
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error
AFAIK this one is independent.
Christian, can you confirm ?
Andrey
From: amd-gfx on behalf of Alex Deucher
Sent: 14 September 2021 15:33
To: Christian König
Cc: Liu, Monk ; amd-gfx list ;
Maling list - DRI developers
Subject: Re: [PATCH 1/2] drm/sched: fix
On Tue, 14 Sep 2021, Lyude Paul wrote:
> On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
>> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
>> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
>> > control brightness, apparently needs a delay before setting brightness
On Tue, Sep 14, 2021 at 10:22 PM Douglas Anderson wrote:
> Version 5 of this series just fixes the panel ID encode macro to be
> cleaner and adds Jani's review tags.
>
> It could possibly be ready to land?
Definitely IMO, the kernel look so much better after this change,
so for the series:
Quoting Marijn Suijten (2021-09-11 06:19:19)
> All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> global name, most of which don't exist or have been renamed. These
> clock drivers seem to function fine without that except the 14nm driver
> for sdm6xx [1].
>
> At the same
On Tue, Sep 14, 2021 at 10:05:03PM +0200, Daniel Vetter wrote:
> On Tue, Sep 14, 2021 at 08:36:56AM -0700, Matthew Brost wrote:
> > On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> > > On Tue, 14 Sept 2021 at 14:55, Matthew Brost
> > > wrote:
> > > >
> > > > From: Venkata Sandeep
On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> > control brightness, apparently needs a delay before setting brightness
> > after power on. Without this delay the
Not all panels in panel-simple were marked what type of panel they
were. I searched through ARM/ARM64 Chromebooks or Chromebook-related
reference boards that I was aware of and found some panels that needed
to be moved. I also skimmed for panels that had no mode and were "big"
since it's quite
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
---
(no changes since v4)
Changes in v4:
- panel-simple-edp => panel-edp
Changes in v3:
- ("Don't re-read
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-edp driver for this.
We'll implement a solution like this:
* We'll read in two
All of the "HPD" handling added to panel-simple recently was for eDP
panels. Remove it from panel-simple now that panel-edp handles eDP
panels. The "prepare_to_enable" delay only makes sense in the context
of HPD, so remove it too. No non-eDP panels used it anyway.
Signed-off-by: Douglas Anderson
While cleaning up the descriptions of the delay for eDP panels I
realized that we'd have a bug if any panels need the
"prepare_to_enable" but HPD handling isn't happening in the panel
driver. Let's put in a stopgap to at least make us not violate
timings. This is not perfectly optimal but trying
Now that the delays are named / described with eDP-centric names, it
becomes clear that we should really specify the "hpd_reliable" and
"hpd_absent" separately without taking the other into account. Let's
fix it.
This should be a no-op change and just adjust how we specify
things. The actual
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple
Now that the eDP panel driver only handles eDP panels we can make
better sense of the delays here. Let's describe them in terms of the
standard eDP timing diagram from the eDP spec.
As part of this, it becomes pretty clear that some eDP panels have too
long of a "hpd_reliable_delay". This used to
The panel-simple driver handles way too much. Let's start trying to
get a handle on it by splitting out the eDP panels. This patch does
this:
1. Start by copying simple-panel verbatim over to a new driver,
simple-panel-edp.
2. Rename "panel_simple" to "panel_edp" in the new driver.
3. Keep
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. Let's enable the
new config.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
---
(no changes since v4)
Changes in v4:
- PANEL_SIMPLE_EDP => PANEL_EDP
- Reordered config
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we will split the PANEL_SIMPLE driver in two. By
default let's give everyone who had the old driver enabled the new
driver too. If folks want to opt-out of one or the other they always
can later.
Signed-off-by: Douglas
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel drivers to identify which
panel is
In the patch ("drm/edid: Allow the querying/working with the panel ID
from the EDID") we introduced a different way of working with the
panel ID stored in the EDID. Let's use this new way for the quirks
code.
Advantages of the new style:
* Smaller data structure size. Saves 4 bytes per panel.
*
A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.
This is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
Reviewed-by: Jani Nikula
---
(no changes since v4)
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be
Hi,
On Tue, Sep 14, 2021 at 12:12 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2021-09-09 14:00:17)
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> > b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> > new file mode 100644
> > index
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/logicvc/logicvc_drm.h | 3 +
drivers/gpu/drm/logicvc/logicvc_layer.c | 151 +++-
drivers/gpu/drm/logicvc/logicvc_layer.h | 7 ++
3 files changed, 155 insertions(+), 6 deletions(-)
diff --git
Introduces a driver for the LogiCVC display controller, a programmable
logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
Xilinx FPGAs. The controller is mostly configured at logic synthesis
time so only a subset of configuration is left for the driver to
handle.
The following
The LogiCVC multi-function device has a display part which is now
described in its binding. Add a patternProperties match for it.
Signed-off-by: Paul Kocialkowski
---
Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
The Xylon LogiCVC is a display controller implemented as programmable
logic in Xilinx FPGAs.
Signed-off-by: Paul Kocialkowski
Acked-by: Rob Herring
---
.../display/xylon,logicvc-display.yaml| 302 ++
1 file changed, 302 insertions(+)
create mode 100644
This series introduces support for the LogiCVC display controller.
The controller is a bit unusual since it is usually loaded as
programmable logic on Xilinx FPGAs or Zynq-7000 SoCs.
More details are presented on the main commit for the driver.
More information about the controller is available
On Tue, Sep 14, 2021 at 08:36:56AM -0700, Matthew Brost wrote:
> On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> > On Tue, 14 Sept 2021 at 14:55, Matthew Brost
> > wrote:
> > >
> > > From: Venkata Sandeep Dhanalakota
> > >
> > > Defining vma on stack can cause stack overflow, if
On Tue, Sep 14, 2021 at 12:48 PM Alex Deucher wrote:
>
> On Tue, Sep 7, 2021 at 6:25 AM Christian König
> wrote:
> >
> >
> > Reviewed-by: Christian König
>
> Is one of you going to push this to drm-misc?
I was assuming it was there already.
I guess I'll just apply it directly.
Hi,
On Tue, Sep 14, 2021 at 12:36 PM Andrzej Hajda wrote:
>
>
> W dniu 14.09.2021 o 20:59, Jani Nikula pisze:
> > On Tue, 14 Sep 2021, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Tue, Sep 14, 2021 at 11:16 AM Jani Nikula
> >> wrote:
> >>> On Thu, 09 Sep 2021, Douglas Anderson wrote:
> In
On Mon, Sep 13, 2021 at 02:17:42PM -0700, Matthew Brost wrote:
> On Mon, Sep 13, 2021 at 02:10:16PM -0700, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > When i915 receives a context reset notification from GuC, it triggers
> > an error capture before resetting any outstanding
On Tue, Sep 14, 2021 at 08:10:14PM +0300, Jani Nikula wrote:
> On Mon, 13 Sep 2021, Nathan Chancellor wrote:
> > On Tue, Aug 24, 2021 at 03:54:24PM -0700, Nathan Chancellor wrote:
> >> Commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings")
> >> disabled -Wsometimes-uninitialized as
i915 enables a wider set of warnings with '-Wall -Wextra' then disables
several with cc-disable-warning. If an unknown flag gets added to
KBUILD_CFLAGS when building with clang, all subsequent calls to
cc-{disable-warning,option} will fail, meaning that all of these
warnings do not get disabled
The clflush calls here aren't doing anything since we are not writting
something and flushing the cache lines to be visible to GuC. Here the
intention seems to be to make sure whatever GuC has written is visible
to the CPU before we read them. However a clflush from the CPU side is
the wrong
On Tue, Sep 7, 2021 at 6:25 AM Christian König wrote:
>
> Am 07.09.21 um 12:03 schrieb Huang Rui:
> > __fls() on sparc64 return "int", but here it is expected as "unsigned
> > long" (x86). It will cause the build errors because the warning becomes
> > fatal while it is using sparc configuration.
W dniu 14.09.2021 o 20:59, Jani Nikula pisze:
> On Tue, 14 Sep 2021, Doug Anderson wrote:
>> Hi,
>>
>> On Tue, Sep 14, 2021 at 11:16 AM Jani Nikula
>> wrote:
>>> On Thu, 09 Sep 2021, Douglas Anderson wrote:
In the patch ("drm/edid: Allow the querying/working with the panel ID
from
Was this fix independent of the other discussions? Should this be
applied to drm-misc?
Alex
On Wed, Sep 1, 2021 at 4:42 PM Alex Deucher wrote:
>
> On Wed, Sep 1, 2021 at 2:50 AM Christian König
> wrote:
> >
> > Am 01.09.21 um 02:46 schrieb Monk Liu:
> > > issue:
> > > in cleanup_job the
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
v3:
- Slight
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy
Hi Rob,
I just found out as I'm about to send a new revision that I had not yet
responded to your concerns here.
On Tue 12 Jan 21, 09:17, Rob Herring wrote:
> On Wed, Dec 23, 2020 at 10:29:44PM +0100, Paul Kocialkowski wrote:
> > The Xylon LogiCVC is a display controller implemented as
On Sat, Sep 11, 2021 at 05:30:45PM +0800, Huacai Chen wrote:
> My original work is at [1].
>
> Current default VGA device selection fails in some cases:
>
> - On BMC system, the AST2500 bridge [1a03:1150] does not implement
> PCI_BRIDGE_CTL_VGA [1]. This is perfectly legal but means the
>
On Fri, Sep 10, 2021 at 08:36:22AM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> session state might still be marked as alive after resume.
Quoting Douglas Anderson (2021-09-09 14:00:17)
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml
> new file mode 100644
> index ..6a621376ff86
> --- /dev/null
> +++
W dniu 14.09.2021 o 16:35, Maxime Ripard pisze:
> Hi,
>
> On Mon, Sep 13, 2021 at 08:29:37AM +0200, Andrzej Hajda wrote:
>> W dniu 10.09.2021 o 12:11, Maxime Ripard pisze:
>>> Interactions between bridges, panels, MIPI-DSI host and the component
>>> framework are not trivial and can lead to
On Tue, 14 Sep 2021, Doug Anderson wrote:
> Hi,
>
> On Tue, Sep 14, 2021 at 11:16 AM Jani Nikula
> wrote:
>>
>> On Thu, 09 Sep 2021, Douglas Anderson wrote:
>> > In the patch ("drm/edid: Allow the querying/working with the panel ID
>> > from the EDID") we introduced a different way of working
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> In the patch ("drm/edid: Allow the querying/working with the panel ID
> from the EDID") we introduced a different way of working with the
> panel ID stored in the EDID. Let's use this new way for the quirks
> code.
>
> Advantages of the new style:
>
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> EDIDs have 32-bits worth of data which is intended to be used to
> uniquely identify the make/model of a panel. This has historically
> been used only internally in the EDID processing code to identify
> quirks with panels.
>
> We'd like to use this
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> A future change wants to be able to read just block 0 of the EDID, so
> break it out of drm_do_get_edid() into a sub-function.
>
> This is intended to be a no-op change--just code movement.
>
> Signed-off-by: Douglas Anderson
> Acked-by: Sam
Hi,
On Tue, Sep 14, 2021 at 11:16 AM Jani Nikula
wrote:
>
> On Thu, 09 Sep 2021, Douglas Anderson wrote:
> > In the patch ("drm/edid: Allow the querying/working with the panel ID
> > from the EDID") we introduced a different way of working with the
> > panel ID stored in the EDID. Let's use
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 18fe19916bc3..4b54a2377821 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> In the patch ("drm/edid: Allow the querying/working with the panel ID
> from the EDID") we introduced a different way of working with the
> panel ID stored in the EDID. Let's use this new way for the quirks
> code.
>
> Advantages of the new style:
>
Hi Christophe,
Le mar., sept. 14 2021 at 11:27:16 +0200, Christophe Branchereau
a écrit :
The previous parameters caused an unbalanced yellow tint.
Signed-off-by: Christophe Branchereau
Acked-by: Paul Cercueil
Cheers,
-Paul
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++--
1
On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
>
> On 13/09/2021 17:50, Matthew Brost wrote:
> > On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 10/09/2021 20:49, Matthew Brost wrote:
> > > > On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin
Appears to match latest BSPEC
Reviewed-by: Clint Taylor
-Clint
On 9/3/21 5:35 PM, Matt Roper wrote:
From: Lucas De Marchi
Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined
On Tue, Sep 14, 2021 at 05:50:25PM +0200, Cornelia Huck wrote:
> On Fri, Sep 10 2021, Christoph Hellwig wrote:
>
> > On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> >> +
> >> + private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
> >> + if (!private)
> >> +
On Wed, 08 Sep 2021, Doug Anderson wrote:
> Hi,
>
> On Mon, Sep 6, 2021 at 3:05 AM Jani Nikula
> wrote:
>>
>> > +{
>> > + struct edid *edid;
>> > + u32 val;
>> > +
>> > + edid = drm_do_get_edid_blk0(drm_do_probe_ddc_edid, adapter, NULL,
>> > NULL);
>> > +
>> > + /*
>> > +
,On Mon, Sep 13, 2021 at 6:57 PM Gurchetan Singh
wrote:
>
>
>
>
> On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
>>
>> .
>>
>> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
>> wrote:
>> >
>> >
>> >
>> > On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
>> >>
>> >> On Wed, Sep 8, 2021 at
Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 3000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012]
On Tue, 14 Sept 2021 at 10:03, Christian König wrote:
>
> Am 14.09.21 um 10:50 schrieb Matthew Auld:
> > Add new flag to indicate special shmem based tt, which can directly
> > handle swapping itself, and should be visible to some shrinker.
> >
> > As part of this we should skip the
On Mon, 13 Sep 2021, Nathan Chancellor wrote:
> On Tue, Aug 24, 2021 at 03:54:24PM -0700, Nathan Chancellor wrote:
>> Commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings")
>> disabled -Wsometimes-uninitialized as noisy but there have been a few
>> fixes to clang that make the false
On Fri, Sep 10, 2021 at 10:26:42AM +0200, Christian König wrote:
> Abstract the complexity of iterating over all the fences
> in a dma_resv object.
>
> The new loop handles the whole RCU and retry dance and
> returns only fences where we can be sure we grabbed the
> right one.
>
> Signed-off-by:
On 2021-09-07 10:03, Simon Ser wrote:
> Hi all,
>
> Recently I've been discussing with various people [1] [2] about amdgpu's
> handling of KMS planes. AMD hardware is a bit special when it comes to
> the cursor plane, and it's not always 100% clear how that maps with the
> KMS API.
>
> Up until
Hi,
On Mon, Sep 13, 2021 at 8:23 PM yangcong
wrote:
>
> Compared to v5, squash this with patch #3 in the series in
> drm/panel: boe-tv101wum-nl6
>
> yangcong (4):
> drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail
> dt-bindings: drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V
On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I
> -Original Message-
> From: Deepak Rawat
> Sent: Tuesday, September 14, 2021 11:59 AM
> To: Dexuan Cui
> Cc: Haiyang Zhang ; David Airlie
> ; Daniel Vetter ; Thomas Zimmermann
> ; dri-devel@lists.freedesktop.org; linux-
> hyp...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject:
Thanks Dexuan, for the patch. A minor comment below.
On Mon, Sep 13, 2021 at 11:27 AM Dexuan Cui wrote:
>
> It looks like Hyper-V supports a hardware cursor feature. It is not used
> by Linux VM, but the Hyper-V host still draws a point as an extra mouse
> pointer, which is unwanted, especially
On Fri, Sep 10 2021, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
>> +
>> +private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
>> +if (!private)
>> +return ERR_PTR(-ENOMEM);
>
> Nit: there is no need to add GFP_KERNEL when
On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> On Tue, 14 Sept 2021 at 14:55, Matthew Brost wrote:
> >
> > From: Venkata Sandeep Dhanalakota
> >
> > Defining vma on stack can cause stack overflow, if
> > vma gets populated with new fields.
>
> Is there some higher level locking
1 - 100 of 181 matches
Mail list logo
