Hi Dave,
On Wed, 27 Jul 2022 13:24:45 +1000 Dave Airlie wrote:
>
> My assumption is I fix this on sending my -next tree to Linus with a
> resolution I create at that time?
>
> Is there another option, we have this fixed in out drm-tip tree already.
Sounds good, no problem.
--
Cheers,
Stephen
Check the bo->resource value before accessing the resource
mem_type.
v2: Fix commit description unwrapped warning
[ 40.191227][ T184] general protection fault, probably for non-canonical
address 0xdc02: [#1] SMP KASAN PTI
[ 40.192995][ T184] KASAN: null-ptr-deref in
On 7/26/22 09:22, Helge Deller wrote:
> On 7/25/22 09:54, Javier Martinez Canillas wrote:
>> From: Daniel Vetter
>>
>> No driver access this anymore, except for the olpc dcon fbdev driver but
>> that has been marked as broken anyways by commit de0952f267ff ("staging:
>> olpc_dcon: mark driver as
Hi Marek, Liu,
On 22-07-26, Liu Ying wrote:
> On Tue, 2022-07-26 at 16:19 +0200, Marek Vasut wrote:
> > On 7/26/22 11:43, Marco Felsch wrote:
> > > FIFO underruns are seen if a AXI bus master with a higher priority
> > > do a
> > > lot of memory access. Increase the burst size to 256B to avoid
On Wed, 27 Jul 2022 at 12:55, Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell
> wrote:
> >
> > On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
> > wrote:
> > >
> > > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > > >
> > > > Today's
Hi all,
On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell
wrote:
>
> On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
> wrote:
> >
> > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > >
> > > Today's linux-next merge of the drm tree got a conflict in:
> > >
> > >
Hi Biju,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220726]
[cannot apply to drm-intel/for-linux-next pinchartl-media/drm/du/next
linus/master v5.19-rc8]
[If your patch is applied to the wrong git tree
On 07/26, Magali Lemes wrote:
> On 7/25/22 20:38, Melissa Wen wrote:
>
> > On 07/25, Magali Lemes wrote:
> > > On 7/25/22 16:42, André Almeida wrote:
> > > > Hi Magali,
> > > >
> > > > Às 15:15 de 25/07/22, Magali Lemes escreveu:
> > > > > As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
>
On 7/25/2022 5:49 PM, Douglas Anderson wrote:
As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually
Just to work in the process, I've pulled a bunch of patches Lyude
tested, that rework some of the nouveau display code.
Dave.
topic/nouveau-misc-2022-07-27:
drm/nouveau-misc: display patches.
These are just some precursor and cleanup display patches from Ben,
tested by Lyude.
The following
Extend the existing test cases to test the conversion from XRGB to
RGB565.
The documentation and the color picker available on [1] are useful
resources to understand this patch and validate the values returned by
the conversion function.
Tested-by: Tales L. Aparecida
Acked-by: Thomas
In order to support multiple destination format conversions, store the
destination pitch and the expected result in its own structure.
Tested-by: Tales L. Aparecida
Acked-by: Thomas Zimmermann
Reviewed-by: David Gow
Signed-off-by: José Expósito
---
.../gpu/drm/tests/drm_format_helper_test.c
The tests fail on big endian architectures, like PowerPC:
$ ./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/tests \
--arch=powerpc --cross_compile=powerpc64-linux-gnu-
Transform the XRGB buffer from little endian to the CPU endian
before calling the conversion
The tests available at the moment only check the conversion from
XRGB to RGB332. However, more conversions will be tested in the
future.
In order to make the struct and functions present in the tests more
generic, rename xrgb_to_rgb332_* to convert_xrgb_*.
Tested-by: Tales L.
Hello everyone,
This series is a follow up of the XRGB to RGB332 conversion KUnit
tests.
As I mentioned in v2 [1] I suspected that the inconsistency handling
the endian might need to be fixed.
Fortunately, Geert Uytterhoeven fixed it in commit 4d9db10576ff
("drm/format-helper: Fix endianness
Eliminate the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c:2344:67-68: Unneeded
semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
https://bugzilla.kernel.org/show_bug.cgi?id=216290
Bug ID: 216290
Summary: [amdgpu] drm/ttm: fbdev race condition into fork()
Product: Drivers
Version: 2.5
Kernel Version: 5.19.0-rc7+ 353afba44cdabdab9fdfaa6990a088718abd5d85
Hardware: AMD
https://bugzilla.kernel.org/show_bug.cgi?id=213145
Michal Przybylowicz (michal.przybylow...@gmail.com) changed:
What|Removed |Added
CC|
On Wed, 27 Jul 2022 at 04:18, Thomas Zimmermann wrote:
>
> Hi
>
> Am 26.07.22 um 19:41 schrieb Sam Ravnborg:
> > Hi Kevin.
> >
> > On Mon, Jul 25, 2022 at 04:53:53PM -0700, Kevin Brace wrote:
> >> From: Kevin Brace
> >>
> >> Changed the uAPI.
> >>
> >> Signed-off-by: Kevin Brace
> >
> > It
Às 17:47 de 25/07/22, Magali Lemes escreveu:
>
> On 7/25/22 16:42, André Almeida wrote:
>> Hi Magali,
>>
>> Às 15:15 de 25/07/22, Magali Lemes escreveu:
>>> As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
>>> _vcs_dpi_soc_bounding_box_st", change their types accordingly.
>>>
>> I can see
Hello Michal,
On 7/26/22 16:40, Michal Suchánek wrote:
> Hello,
>
> On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
>> On 7/20/22 16:27, Thomas Zimmermann wrote:
>>> Add a per-model device-function structure in preparation of adding
>>> color-management support.
On Mon, 25 Jul 2022 21:22:06 -0500 "Sierra Guiza, Alejandro (Alex)"
wrote:
> >> a) add the || to the end of the previous line
> >> b) indent such the we have a nice-to-read alignment
> >>
> >> if (!list_empty(_page_list) || isolation_error_count ||
> >> coherent_pages)
> >>
> > I missed
Hi
Am 26.07.22 um 01:53 schrieb Kevin Brace:
From: Kevin Brace
Changed the uAPI.
Signed-off-by: Kevin Brace
---
include/uapi/drm/via_drm.h | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/via_drm.h
Add comments to document gfx_off related members of struct amdgpu_gfx.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
Add documentation explaining those two new files.
While here, add a note about the value type.
Signed-off-by: André Almeida
---
Documentation/gpu/amdgpu/thermal.rst | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/amdgpu/thermal.rst
This series adds new logging features for GFXOFF available for vangogh
and documentation for it.
I've created a small userspace program to interact with this new debugfs
interface and it can be found at:
https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool
Changelog:
v2:
- Make entrycount
Implement functions to get and set GFXOFF's entry count and residency
for vangogh.
Signed-off-by: André Almeida
---
.../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +-
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92
Add debugfs interface to log GFXOFF statistics:
- Read amdgpu_gfxoff_count to get the total GFXOFF entry count at the
time of query since system power-up
- Write 1 to amdgpu_gfxoff_residency to start logging, and 0 to stop.
Read it to get average GFXOFF residency % multiplied by 100
during
Hi
Am 26.07.22 um 19:41 schrieb Sam Ravnborg:
Hi Kevin.
On Mon, Jul 25, 2022 at 04:53:53PM -0700, Kevin Brace wrote:
From: Kevin Brace
Changed the uAPI.
Signed-off-by: Kevin Brace
It would be great to have the new extensions to the UAPI documented
using kernel-doc.
As an example see:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
stay in sync with each other, and so we can
Hi Dave, Daniel,
Bug fixes for 5.20 and a few new things. I know it's a bit late for new
stuff, but this is mainly fixes for new IPs that were just added in 5.20
and more DC cleanup which is just code shuffling to group FP code into
separate code objects and spliting up the DC DM code into more
On 20/07/2022 11:16, Janusz Krzysztofik wrote:
From: Chris Wilson
Inside the shrinker, we cannot wake the device as that may cause
recursion into fs-reclaim, so instead we only unbind vma if the device
is currently awake. (In order to provide reclaim while asleep, we do
wake the device up
From: Rob Clark
Since that is what these fxns actually do.. they are getting *pinned*
pages (as opposed to cases where we need pages, but don't need them
pinned, like CPU mappings).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 18 +-
From: Rob Clark
We've already attached the fences, so obj->resv (which shrinker checks)
tells us whether they are still active. So we can unpin sooner, before
we drop the queue lock.
This also avoids the need to grab the obj lock in the retire path,
avoiding potential for lock contention
From: Rob Clark
Combine separate trace events for purge vs evict into one. When we add
support for purging/evicting active buffers we'll just add more info
into this one trace event, rather than adding a bunch more events.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c |
From: Rob Clark
All use of msm_gem_is_locked() is just for WARN_ON()s, so extract out
into an msm_gem_assert_locked() patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 36 +--
drivers/gpu/drm/msm/msm_gem.h | 8 +++-
2 files changed, 25
From: Rob Clark
If we are under enough memory pressure, we should stall waiting for
active buffers to become idle in order to evict.
v2: Check for __GFP_ATOMIC before blocking
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 70 +-
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 3c6add51d13b..c4844cf3a585 100644
---
From: Rob Clark
This converts over to use the shared GEM LRU/shrinker helpers. Note
that it means we are no longer tracking purgeable or willneed buffers
that are active separately. But the most recently pinned buffers should
be at the tail of the various LRUs, and the shrinker is already
From: Rob Clark
Add a simple LRU helper to assist with driver's shrinker implementation.
It handles tracking the number of backing pages associated with a given
LRU, and provides a helper to implement shrinker_scan.
A driver can use multiple LRU instances to track objects in various
states, for
From: Rob Clark
Otherwise if we hit reclaim pinning objects in the submit path, we'll be
blocking retire_worker trying to free a submit.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
drivers/gpu/drm/msm/msm_gem_submit.c | 10 --
From: Rob Clark
Avoid having multiple spots where we increment/decrement pin_count (and
associated LRU updating)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
Really what this is doing is updating various LRU lists.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
At this point the pinned refcnt is sufficient, and the shrinker is
already prepared to encounter objects which are still active according
to fences attached to the resv.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 45 ++--
From: Rob Clark
Currently in our shrinker path we shouldn't be encountering anything
that is active, but this will change in subsequent patches. So check
if there are unsignaled fences.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 10 ++
From: Rob Clark
Move more initialization into submit_create().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
From: Rob Clark
This lets us drop the NORETRY.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index
From: Rob Clark
Mostly a resend with switch to lockdep asserts for the GEM LRU helper
and conversion of msm locking checks to lockdep asserts, since that
seemed like a good idea.
original description below:
This is mostly motivated by getting drm/msm to pass an i-g-t shrinker
test that I've
Hi Kevin.
On Mon, Jul 25, 2022 at 04:53:53PM -0700, Kevin Brace wrote:
> From: Kevin Brace
>
> Changed the uAPI.
>
> Signed-off-by: Kevin Brace
It would be great to have the new extensions to the UAPI documented
using kernel-doc.
As an example see: vc4_drm.h
There are a lot of UAPI that is
Drivers tend to want to define the names of their regulators somewhere
in their source file as "static const". This means, inevitable, that
every driver out there open codes something like this:
static const char * const supply_names[] = {
"vcc", "vccl",
};
static int get_regulators(struct
In the patch ("regulator: core: Allow drivers to define their init
data as const") we no longer need to do copying of regulator bulk data
from initdata to something dynamic. Let's take advantage of that.
In addition to saving some code, this also moves us to using
ARRAY_SIZE() to specify how many
As of the patch ("regulator: core: Allow specifying an initial load w/
the bulk API") we can now specify the initial load in the bulk data
rather than having to manually call regulator_set_load() on each
regulator. Let's use it.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("Use the new
There are a number of drivers that follow a pattern that looks like
this:
1. Use the regulator bulk API to get a bunch of regulators.
2. Set the load on each of the regulators to use whenever the
regulators are enabled.
Let's make this easier by just allowing the drivers to pass the load
in.
3 regulators are specified listed but the number 2 is specified. Fix
it.
Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
1
As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.
It should be
1 regulators is specified listed but the number 2 is specified. This
presumably means we try to get a regulator with no name. Fix it.
Fixes: 033f47f7f121 ("drm/msm/dsi: Add DSI configuration for SDM660")
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("Fix number of regulators for
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads. The idea is to add some extra
functionality to the regulator "bulk" API so that consumers can
specify the load using that. Though I didn't convert everyone over, I
include patches in this
On Tue, Jul 26, 2022 at 11:32:28AM +0100, Richard Fitzgerald wrote:
> On 25/07/2022 19:09, Greg KH wrote:
> > On Mon, Jul 25, 2022 at 05:08:59PM +0100, Richard Fitzgerald wrote:
> > > Call try_module_get() on a component before attempting to call its
> > > bind() function, to ensure that a
Hi Alisa,
On Mon, Jul 25, 2022 at 01:45:55PM +0300, Alisa Khabibrakhmanova wrote:
> Pointer dev_priv->mmio, which was checked for NULL at via_do_init_map(),
> is passed to via_do_cleanup_map() and is dereferenced there without check.
>
> The patch adds the condition in via_dma_cleanup() which
RZ/G2L does not have plane registers as well as it uses different
CRTC. The below functions are SoC specific
* rcar_du_crtc_finish_page_flip()
* __rcar_du_plane_setup
* __rcar_du_plane_atomic_check
All other function can be handled in common code. This patch introduces
rcar_du_lib_vsp_init() to
Move vsp rcar_du_vsp_{map,unmap}_fb() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 75 ---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 15 -
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 75 +++
Move rcar_du_gem_prime_import_sg_table() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 45 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 4 --
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 45 +++
Move rcar_du_dumb_create() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 3 ---
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 25 +++
Add RCar DU encoder lib support by moving rcar_du_encoder_count_ports()
and rcar_du_encoder_funcs to the lib file and added
rcar_du_encoder_funcs() to share the common code between RCar and
RZ/G2L DU encoder drivers.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/Kconfig |
Move rcar_du_vsp_atomic_flush() to RCar DU vsp lib.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 13 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 13 +
Add RCar DU kms lib support by moving rcar_du_format_infos table and
rcar_du_format_infos() to the lib file to share the common code between
RCar and RZ/G2L DU KMS drivers.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/Makefile | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c
Add RZ/G2L reset and clocks to struct rcar_du_crtc, so that
we can share and optimize the common code between RCar and
RZ/G2L driver using RCar DU library.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
Move rcar_du_vsp_atomic_begin() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 2 ++
4 files
Add RCar DU vsp lib support by moving rcar_du_vsp_disable()
to the lib file so that same function can be used by both
RCar and RZ/G2L DU VSP drivers.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/Kconfig | 5 ++
drivers/gpu/drm/rcar-du/Makefile | 1 +
Adding RCar DU lib support(Encoder, vsp and KMS) proved that it can save
50% code saving on RZ/G2L compared to patch series [1].
The current patchset contains just movement of codes with some trivial changes.
The subsequent patch series will have more additions to vsp and kms library.
There is
On Mon, Jul 25, 2022 at 9:46 PM wrote:
>
> From: Akhil P Oommen
>
> Fix a null pointer access when memory allocation fails in
> a6xx_get_indexed_registers().
>
> Change-Id: I33e13745cd8e5841d2f377f48a199af98be2ed02
> Signed-off-by: Akhil P Oommen
> Signed-off-by: Devi prasad Dhamarasingi
> ---
Check the bo->resource value before accessing the resource
mem_type.
[ 40.191227][ T184] general protection fault, probably for non-canonical
address 0xdc02: [#1] SMP KASAN PTI
[ 40.192995][ T184] KASAN: null-ptr-deref in range
[0x0010-0x0017]
[
Thanks for the patch.
On Tue, Jul 26, 2022 at 10:21:13AM +0200, Peter Suti wrote:
> fb_deferred_io_init depends on smem_len being filled
> to be able to initialize the virtual page lists since
> commit 856082f021a2 ("fbdev: defio: fix the pagelist corruption")
>
This code has changed since then
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is
Hi
Am 26.07.22 um 02:12 schrieb Sami Tolvanen:
On Mon, Jul 25, 2022 at 4:37 PM Nathan Chancellor wrote:
When booting a kernel compiled with clang's CFI protection
(CONFIG_CFI_CLANG), there is a CFI failure in
drm_simple_kms_crtc_mode_valid() when trying to call
https://bugzilla.kernel.org/show_bug.cgi?id=216277
--- Comment #6 from dark_syl...@yahoo.com.ar ---
OK today it happened again so changing 78-graphics-card.rules did not fix it.
I just found this:
https://bbs.archlinux.org/viewtopic.php?id=260525
Which leads me to this:
On Tue, 2022-07-26 at 16:19 +0200, Marek Vasut wrote:
> On 7/26/22 11:43, Marco Felsch wrote:
> > FIFO underruns are seen if a AXI bus master with a higher priority
> > do a
> > lot of memory access. Increase the burst size to 256B to avoid such
> > underruns and to improve the memory access
On Tue, Jul 26, 2022 at 06:10:37AM +, yuji2.ishik...@toshiba.co.jp wrote:
> Hi Greg
>
> Thank you for your comments.
>
> > -Original Message-
> > From: Greg KH
> > Sent: Monday, July 25, 2022 9:51 PM
> > To: ishikawa yuji(石川 悠司 ○ＲＤＣ□ＡＩＴＣ○ＥＡ開)
> >
> > Cc: Rob Herring ; Hans Verkuil
Applied the series. Thanks!
Alex
On Tue, Jul 26, 2022 at 3:26 AM Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> smatch warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hwseq.c:910
> dcn32_init_hw() warn: inconsistent indenting.
>
> Reported-by: Abaci Robot
Hello,
On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
> On 7/20/22 16:27, Thomas Zimmermann wrote:
> > Add a per-model device-function structure in preparation of adding
> > color-management support. Detection of the individual models has been
> > taken from fbdev's
On 26/07/2022 14:12, Tvrtko Ursulin wrote:
On 25/07/2022 15:18, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In
On 7/26/22 11:43, Marco Felsch wrote:
FIFO underruns are seen if a AXI bus master with a higher priority do a
lot of memory access. Increase the burst size to 256B to avoid such
underruns and to improve the memory access efficiency.
Sigh, this again ...
diff --git
(cc'ing dri-devel)
This looks like it died down in the DRM code. It seems doubtful that the
flock code would be affecting this, but let me know if I'm incorrect
here.
Thanks,
Jeff
On Tue, 2022-07-26 at 21:14 +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Support the CRTC's color-management property and implement each model's
> palette support.
>
> The OF hardware has different methods of setting the palette. The
> respective code has been taken from fbdev's offb and refactored into
> per-model device
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Add a per-model device-function structure in preparation of adding
> color-management support. Detection of the individual models has been
> taken from fbdev's offb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Add a dedicated CRTC state to ofdrm to later store information for
> palette updates.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/ofdrm.c | 62 ++--
>
Reviewed-by: Javier Martinez Canillas
fb_deferred_io_init depends on smem_len being filled
to be able to initialize the virtual page lists since
commit 856082f021a2 ("fbdev: defio: fix the pagelist corruption")
Signed-off-by: Peter Suti
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, Jul 25, 2022 at 11:03 PM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
>
>
> > -Original Message-
> > From: André Almeida
> > Sent: Tuesday, July 26, 2022 12:15 AM
> > To: Quan, Evan ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ;
Hello Thomas,
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Open Firmware provides basic display output via the 'display' node.
> DT platform code already provides a device that represents the node's
> framebuffer. Add a DRM driver for the device. The display mode and
> color format is
Pointer sseu is being assigned a value that is never read. The pointer
is redundant and can be removed. Cleans up clang scan warning:
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:300:2: warning: Value stored
to 'sseu' is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King
---
On 25/07/2022 15:18, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer
On Fri, 22 Jul 2022 21:15:38 +0200, Krzysztof Kozlowski wrote:
> Rebased on Linus' master
>
> Changes since v1
>
> 1. Rework patchset as Rob suggested, so there is only one patch - changing spi
>and display/panel.
> v1:
>
On Tue, Jul 26, 2022 at 1:46 PM ChiaEn Wu wrote:
> On Mon, Jul 25, 2022 at 4:41 PM Andy Shevchenko
> wrote:
...
> > > +struct mt6370_led {
> > > + union {
> > > + struct led_classdev isink;
> > > + struct led_classdev_mc mc;
> > > + };
> >
> > Where is
On 7/25/22 20:38, Melissa Wen wrote:
On 07/25, Magali Lemes wrote:
On 7/25/22 16:42, André Almeida wrote:
Hi Magali,
Às 15:15 de 25/07/22, Magali Lemes escreveu:
As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
_vcs_dpi_soc_bounding_box_st", change their types accordingly.
I can see
On Tue, Jul 26, 2022 at 07:28:48PM +0800, ChiaEn Wu wrote:
> On Tue, Jul 26, 2022 at 5:31 PM Daniel Thompson
> wrote:
> ...
> > > > Does the MT6372 support more steps than this? In other words does it use
> > > > a fourteen bit scale or does it use an 11-bit scale at a different
> > > > register
On Mon, Jul 25, 2022 at 4:41 PM Andy Shevchenko
wrote:
...
> > From: ChiYuan Huang
>
> (Note this and read below)
...
> In conjunction with above what SoB of Alice means?
>
> You really need to take your time and (re-)read
>
On Tue, Jul 26, 2022 at 5:31 PM Daniel Thompson
wrote:
...
> > > Does the MT6372 support more steps than this? In other words does it use
> > > a fourteen bit scale or does it use an 11-bit scale at a different
> > > register location?
> >
> > Hi Daniel,
> >
> > Thanks for your reply.
> > Yes,
On 25/07/2022 12:42, Arunpravin Paneer Selvam wrote:
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 43
Novatek NT35596s is a generic DSI IC that drives command and video mode
panels. Add the driver for it. Currently add support for the LCD panel
from JDI connected with this IC, as found on Xiaomi Mi Mix2s phones.
Changes in v3:
- Embed the support into existing driver (panel-novatek-nt36672a), as
Add documentation for "novatek,nt35596s" panel.
Changes in v3:
- Embed the documentation into existing one (novatek,nt36672a).
Signed-off-by: Molly Sophia
---
.../display/panel/novatek,nt36672a.yaml | 20 ---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git
1 - 100 of 147 matches
Mail list logo
