Drop the assigned clock rate property and vote on the mdp clock to
max frequency during bind/probe sequence.
Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during
resume sequence.
- Add fixes tag.
Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)
- Add
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Set mdp clock to max clock rate during probe/bind sequence from the
opp table so that rails are not at undetermined state. Since we do not
know what will be the rate set in boot loader, it would be ideal to
vote at max frequency. There could be a firmware display programmed
in bootloader and we
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
On 2022/3/22 07:20, Rob Herring wrote:
On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
From: suijingfeng
Needs a commit message.
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
Same person? Don't need both emails.
Yes,
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Make vc4 driver use the new API so that the embedded encoder model
can be retained in the driver and there is no change in
functionality.
changes in v5:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware,
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose
On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> From: suijingfeng
>
Needs a commit message.
> Signed-off-by: suijingfeng
> Signed-off-by: Sui Jingfeng <15330273...@189.cn>
Same person? Don't need both emails.
> ---
> .../loongson/loongson,display-controller.yaml | 230
Now Cc'ing Daniel properly
Lucas De Marchi
On Mon, Mar 21, 2022 at 04:00:56PM -0700, Lucas De Marchi wrote:
+Thomas Zimmermann and +Daniel Vetter
Could you take a look below regarding the I/O to I/O memory access?
On Thu, Mar 03, 2022 at 11:30:11PM +0530, Balasubramani Vivekanandan wrote:
On 2022-03-21 at 14:19:01 +0530, Hellstrom, Thomas wrote:
> On Sun, 2022-03-20 at 02:12 +0530, Ramalingam C wrote:
> > XY_FAST_COLOR_BLT cmd is faster than the older XY_COLOR_BLT. Hence
> > for
> > clearing (Zero out) the pages of the newly allocated object, faster
> > cmd
> > is used.
>
> NIT:
On 2022-03-21 at 11:11:33 +0100, Das, Nirmoy wrote:
> In the previous version I replied only to the mailing list email so probably
> my email slipped through.
Sorry for the miss. Thank so much for the review.
Ram
>
> Reviewed-by: Nirmoy Das for patch 6-7
>
> On 3/19/2022 9:42 PM, Ramalingam C
On 2022-03-21 at 16:09:08 +0530, Hellstrom, Thomas wrote:
> On Sun, 2022-03-20 at 02:12 +0530, Ramalingam C wrote:
> > While clearing the Flat-CCS capable lmem object, we need to clear the
> > CCS
> > meta data corresponding to the memory.
> >
> > As part of live_migrate_clear add check for the
+Thomas Zimmermann and +Daniel Vetter
Could you take a look below regarding the I/O to I/O memory access?
On Thu, Mar 03, 2022 at 11:30:11PM +0530, Balasubramani Vivekanandan wrote:
memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.
When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the
On Xe-HP and later devices, dedicated compression control state (CCS)
stored in local memory is used for each surface, to support the
3D and media compression formats.
The memory required for the CCS of the entire local memory is 1/256 of
the local memory size. So before the kernel boot, the
Add a parameter called "extra_pages" for ttm_tt_init, to indicate that
driver needs extra pages in ttm_tt.
v2:
Used imperative wording [Thomas and Christian]
Signed-off-by: Ramalingam C
cc: Christian Koenig
cc: Hellstrom Thomas
Reviewed-by: Thomas Hellstrom
Reviewed-by: Christian Konig
Handle the src and dst chunk offsets for different instances of the copy
engines.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
XY_CTRL_SURF_COPY_BLT is a BLT cmd used for reading and writing the
ccs
Extend the live migrate selftest, to verify the ccs surface clearing
during the Flat-CCS capable lmem obj clear.
v2:
Look at right places for ccs data [Thomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 250 ++---
1 file changed, 222
Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more,
for clearing (Zero out) the pages of the newly allocated object.
XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT.
v2:
Typo fix at title [Thomas]
Signed-off-by: Ramalingam C
Signed-off-by: Chris Wilson
Reviewed-by:
Move the static calculations out of the loops for copy and clear.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
On Xe-HP and later devices, we use dedicated compression control
state (CCS) stored in local memory for each surface, to support
the 3D and media compression formats.
The memory required for the CCS of the entire local memory is
1/256 of the local memory size. So before the kernel
boot, the
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
v2(Michael Cheng): Use sizeof(*addr) instead of sizeof(addr) to get the
actual size of the page. Thanks to Matt Roper for
pointing
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Replace all occurrence of cache_clflush_range with drm_clflush_virt_range.
This will prevent compile errors on non-x86 platforms.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added
more patches to convert
On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> > > drm: Add drm_mode_init()
> > > drm/bridge: Use drm_mode_copy()
> > > drm/imx: Use
The first patch just prevents to iterate on a NULL job->bo array during
job cleanup. This situation can happen when v3d_lookup_bos() fails to
allocate memory for the job->bo array and job->bo_count was already set.
The second replace BOs lookup steps in v3d_lookup_bos() with the
common code in
When v3d_lookup_bos fails to `allocate validated BO pointers`,
job->bo_count was already set to args->bo_count, but job->bo points to
NULL. In this scenario, we must verify that job->bo is not NULL before
iterating on it to proper clean up a job. Also, drm_gem_object_put
already checks that the
As v3d_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
replace the explicit code in v3d to simply use the DRM function.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_gem.c | 49 +++
1 file changed, 3 insertions(+), 46 deletions(-)
diff
On Thu, Mar 03, 2022 at 11:30:10PM +0530, Balasubramani Vivekanandan wrote:
memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.
v2: Check if the log object allocated from local memory
On Mon, 21 Mar 2022, Ville Syrjälä wrote:
> On Wed, Mar 16, 2022 at 10:00:06AM +0200, Jani Nikula wrote:
> > On Fri, 18 Feb 2022, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Initialize on-stack modes with drm_mode_init() to guarantee
> > > no stack garbage in the list head, or
On Thu, Mar 03, 2022 at 11:30:08PM +0530, Balasubramani Vivekanandan wrote:
Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
On 21.03.22 19:49, Dominique Dumont wrote:
> On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
>> Dominique/Salvatore/Eric, what's the status of this regression?
>> According to the debian bug tracker the problem is solved with 5.16 and
>> 5.17, but was 5.15 ever fixed?
>
> I don't
On Wed, Mar 16, 2022 at 10:00:06AM +0200, Jani Nikula wrote:
> On Fri, 18 Feb 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Initialize on-stack modes with drm_mode_init() to guarantee
> > no stack garbage in the list head, or that we aren't copying
> > over another mode's list head.
On 2022-03-21 4:07 a.m., Thomas Hellström wrote:
On 3/21/22 11:30, Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at
Hi Liviu
On 3/21/2022 11:07 AM, Liviu Dudau wrote:
On Thu, Mar 17, 2022 at 10:26:38AM -0700, Abhinav Kumar wrote:
Hi Laurent
Thanks for the review.
On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar
Hi Livid
Thanks for your review.
All your comments are valid. I think I should re-order the patches like
you have suggested. That should address all comments.
Thanks
Abhinav
On 3/21/2022 10:24 AM, Liviu Dudau wrote:
On Thu, Mar 17, 2022 at 06:45:34PM -0700, Abhinav Kumar wrote:
For some
On Thu, Mar 17, 2022 at 10:26:38AM -0700, Abhinav Kumar wrote:
> Hi Laurent
>
> Thanks for the review.
>
> On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
> > Hi Abhinav,
> >
> > Thank you for the patch.
> >
> > On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar wrote:
> > > For some vendor
On 2022-03-21 10:28 a.m., Tvrtko Ursulin wrote:
On 21/03/2022 16:31, Michael Cheng wrote:
On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the
On 2022-03-21 10:28 a.m., Tvrtko Ursulin wrote:
On 21/03/2022 16:31, Michael Cheng wrote:
On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the
On Mon, 21 Mar 2022 at 19:21, Vinod Polimera wrote:
>
>
>
> > -Original Message-
> > From: Stephen Boyd
> > Sent: Friday, March 18, 2022 2:41 AM
> > To: quic_vpolimer ;
> > devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > freedr...@lists.freedesktop.org;
On 21/03/2022 16:31, Michael Cheng wrote:
On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything
On Thu, Mar 17, 2022 at 06:45:34PM -0700, Abhinav Kumar wrote:
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupts can
> also be shared between
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Joris L. (commandl...@protonmail.com) changed:
What|Removed |Added
CC|
Hi,
On Thu, Mar 17, 2022 at 06:45:33PM -0700, Abhinav Kumar wrote:
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_writeback_connector_init() and make
- Upon the G2H Notify-Err-Capture event, parse through the
GuC Log Buffer (error-capture-subregion) and generate one or
more capture-nodes. A single node represents a single "engine-
instance-capture-dump" and contains at least 3 register lists:
global, engine-class and engine-instance. An
Add a flags parameter through all of the coredump creation
functions. Add a bitmask flag to indicate if the top
level gpu_coredump event is triggered in response to
a GuC context reset notification.
Using that flag, ensure all coredump functions that
read or print mmio-register values related to
GuC log buffer regions for debug-log-events, crash-dumps and
error-state-capture are all part of a single bo allocation that
also includes the guc_log_buffer_state structures. Now that we
support it, increase the size allocation for error-capture.
Since the error-capture region is accessed at
Print the GuC captured error state register list (string names
and values) when gpu_coredump_state printout is invoked via
the i915 debugfs for flushing the gpu error-state that was
captured prior.
Since GuC could have reported multiple engine register dumps
in a single notification event, parse
Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.
Then, populate GuC ADS with the lists of registers we want
GuC to report back to host on engine reset events. This list
should include global, engine-class and engine-instance
registers for
Add intel_guc_capture_output_min_size_est function to
provide a reasonable minimum size for error-capture
region before allocating the shared buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 48 +++
Add GuC's error capture output structures and definitions as how
they would appear in GuC log buffer's error capture subregion after
an error state capture G2H event notification.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 47
For the sake of better code readibility, change previous
relay logging function names with "capture_logs" to
"copy_debug_logs" to differentiate from error capture
functions that will use a different region of the same buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
Add the ability for runtime allocation and freeing of
steered register list extentions that depend on the
detected HW config fuses.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 9 +
Add additional DG2 registers for GuC error state capture.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 80 ++-
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git
Add device specific tables and register lists to cover different engines
class types for GuC error state capture for XE_LP products.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 ++
In the rare but possible scenario where we are in the midst of
multiple GuC error-capture (and engine reset) events and the
user also triggers a forced full GT reset or the internal watchdog
triggers the same, intel_guc_submission_reset_prepare's call
to flush_work(>ct.requests.worker) can cause
Abstract out a Gen9 register list as the default for all other
platforms we don't yet formally support GuC submission on.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 82 +--
1 file changed, 59 insertions(+),
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register said lists
of global,
On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote:
On 19/03/2022 19:42, Michael Cheng wrote:
Previous concern with using drm_clflush_sg was that we don't know
what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at once to avoid paranoia.
And now we know,
From: suijingfeng
ls3A4000 evb board is shipped with adv7123 and tfp410 while ls2k1000
PI board use a DPI panel from FORLINX and a sii9022 HDMI transmitter.
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
arch/mips/configs/loongson2k_defconfig | 5 +
From: suijingfeng
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
From: suijingfeng
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
.../loongson/loongson,display-controller.yaml | 230 ++
1 file changed, 230 insertions(+)
create mode 100644
From: suijingfeng
___
|---| ||
| CRTC0 --> | DVO0 > | 1024x600 DPI Panel |
| _ _ ---| | Which panel to use
From: suijingfeng
This board is made by LEMOTE corporation, it has two name, one
is LX-6901, another is A1901.
This board has only one VGA output which is connected to the DVO1 of
the display controller.
+--++---+
| DDR4 ||
From: suijingfeng
The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
therefore can play with discrete graphics card.
While the integrated display copntroller is equipped with a VGA output
and a DVI
There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations,
From: suijingfeng
The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, Tts PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to
> -Original Message-
> From: Stephen Boyd
> Sent: Friday, March 18, 2022 2:41 AM
> To: quic_vpolimer ;
> devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedr...@lists.freedesktop.org; linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
On Mon, Mar 21, 2022 at 2:30 AM Christian König
wrote:
>
> Am 18.03.22 um 16:12 schrieb Rob Clark:
> > On Fri, Mar 18, 2022 at 12:42 AM Christian König
> > wrote:
> >> Am 17.03.22 um 18:31 schrieb Rob Clark:
> >>> On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote:
> [SNIP]
> > (At
On 21/03/2022 09:51, Christian König wrote:
Am 18.03.22 um 20:50 schrieb Robert Beckett:
when allocating a resource in place it is common to free the buffer's
resource, then allocate a new resource in a different placement.
e.g. amdgpu_bo_create_kernel_at calls ttm_resource_free, then calls
On Mon, 2022-03-21 at 14:43 +, Tvrtko Ursulin wrote:
>
> On 21/03/2022 13:40, Thomas Hellström wrote:
> > Hi,
> >
> > On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote:
> > >
> > > On 21/03/2022 12:33, Thomas Hellström wrote:
> > > > On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin
On Mon, 2022-03-21 at 15:12 +0100, Christian König wrote:
> Am 21.03.22 um 15:02 schrieb Zack Rusin:
> > On Mon, 2022-03-21 at 14:58 +0100, Christian König wrote:
> > > ⚠ External Email: This email originated from outside of the
> > > organization. Do not click links or open attachments unless you
From: Jordan Justen
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
v5:
* Fix documenation formatting and verified with `make htmldocs` as
suggested by Daniel
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
Acked-by: Jon
On 21/03/2022 13:40, Thomas Hellström wrote:
Hi,
On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote:
On 21/03/2022 12:33, Thomas Hellström wrote:
On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin wrote:
On 21/03/2022 11:03, Thomas Hellström wrote:
Hi, Tvrtko.
On 3/21/22 11:27,
Sorry I meant "sleep out" not "sleep in" obviously
On Mon, Mar 21, 2022 at 3:39 PM Christophe Branchereau
wrote:
>
> Following the introduction of bridge_atomic_enable in the ingenic
> drm driver, the crtc is enabled between .prepare and .enable, if
> it exists. Add it so the backlight is only
Following the introduction of bridge_atomic_enable in the ingenic
drm driver, the crtc is enabled between .prepare and .enable, if
it exists. Add it so the backlight is only enabled after the crtc is, to
avoid graphical issues.
As we're moving the "sleep in" command out of the init sequence
into
On 21.03.22 13:07, Éric Valette wrote:
> My problem has never been fixed.
>
> The proposed patch has been applied to 5.15. I do not remerber which version
> 28 maybe.
>
> I still have à RIP in pm_suspend. Did not test the Last two 15 versions.
>
> I can leave with 5.10 est using own compiled
Hi Christophe,
Le lun., mars 21 2022 at 14:36:51 +0100, Christophe Branchereau
a écrit :
Following the introduction of bridge_atomic_enable in the ingenic
drm driver, the crtc is enabled between .prepare and .enable, if
it exists.
Add it so the backlight is only enabled after the crtc is, to
On Fri, Mar 18, 2022 at 08:12:54AM -0700, Rob Clark wrote:
> On Fri, Mar 18, 2022 at 12:42 AM Christian König
> wrote:
> >
> > Am 17.03.22 um 18:31 schrieb Rob Clark:
> > > On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote:
> > >> [SNIP]
> > >>> (At some point, I'd like to use scheduler for
Am 21.03.22 um 15:02 schrieb Zack Rusin:
On Mon, 2022-03-21 at 14:58 +0100, Christian König wrote:
⚠ External Email: This email originated from outside of the
organization. Do not click links or open attachments unless you
recognize the sender.
Instead use the new dma_resv_get_singleton
Mhm, crap I've forgot the cover letter. Anyway should be a well known
set by now.
I've polished the documentation a bit more compared to the last version
and with this finally managed to correctly CC all the driver maintainers
on the relevant patches.
Please review and comment.
Cheers,
On Mon, 2022-03-21 at 14:58 +0100, Christian König wrote:
> ⚠ External Email: This email originated from outside of the
> organization. Do not click links or open attachments unless you
> recognize the sender.
>
> Instead use the new dma_resv_get_singleton function.
>
> Signed-off-by: Christian
From: Thomas Zimmermann
[ Upstream commit 3c3384050d68570f9de0fec9e58824decfefba7a ]
Fix a number of undefined references to drm_kms_helper.ko in
drm_dp_helper.ko:
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_duplicate_state':
From: Christoph Niedermaier
[ Upstream commit 6061806a863e8b65b109eb06a280041cc7525442 ]
If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the
From: Thomas Zimmermann
[ Upstream commit 3c3384050d68570f9de0fec9e58824decfefba7a ]
Fix a number of undefined references to drm_kms_helper.ko in
drm_dp_helper.ko:
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_duplicate_state':
From: Christoph Niedermaier
[ Upstream commit 6061806a863e8b65b109eb06a280041cc7525442 ]
If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 29 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 5 ++--
We can now add multiple writers to the dma_resv object.
Also enable the check for not adding containers in dma_resv.c again.
Signed-off-by: Christian König
Cc: amd-...@lists.freedesktop.org
---
drivers/dma-buf/dma-resv.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h |
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
v3: fix a missing case in radeon
v4: rebase on nouveau changes, fix
1 - 100 of 173 matches
Mail list logo
