Looks you can drop macro 'AMDGPU_DEFAULT_GTT_SIZE_MB' as well.
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of
> Mukul Joshi
> Sent: Wednesday, April 26, 2023 9:53 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Joshi, Mukul ; Kuehling,
Lo!
Sometimes the regression tracker runs into regressions himself... :-D
On 11.04.23 08:47, Stephen Rothwell wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
>
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230425]
[cannot apply to v6.3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Tue, Apr 25, 2023 at 05:48:27PM -0700, Chia-I Wu wrote:
> Signed-off-by: Chia-I Wu
> Cc: sta...@vger.kernel.org
I know I can not take patches without any changelog text at all, maybe
the DRM developers are more lax, but it's not a good idea at all.
thanks,
greg k-h
From: Dave Airlie
In order to add a new macro, Luis suggested converting some docs
for the new ones.
This tries to keep exisiting module_init, module_exit where they are,
and adds the new docs to the module section.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Cc: Luis Chamberlain
Cc:
From: Dave Airlie
This adds a tag that will go into the module info, only one firmware from
the group given needs to be available for this driver to work. This allows
dracut to avoid adding in firmware that aren't needed.
This just brackets a module list in the modinfo, the modules in the list
added a newline for block comment
checkpatch.pl output:
---
drivers/gpu/drm/vkms/vkms_drv.c
---
WARNING: Block comments use a trailing */ on a separate line
+* which ix XRGB in all cases. */
total: 0 errors, 1 warnings, 274
On Tue, Apr 25, 2023 at 7:27 PM Chen, Guchun wrote:
>
> From coding style's perspective, this lock/unlock handling should be put into
> amdgpu_ctx_priority_override.
The locking is to protect mgr->ctx_handles.
>
> Regards,
> Guchun
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
>From coding style's perspective, this lock/unlock handling should be put into
>amdgpu_ctx_priority_override.
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of Chia-
> I Wu
> Sent: Wednesday, April 26, 2023 8:48 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Pan, Xinhui
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: f600e0bbde8562a06bee31b3eb1b69d49acac4c5 Add linux-next specific
files for 20230425
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com
https
We're doing/planning on doing similar or related work here at chromium.
https://patchwork.kernel.org/project/dri-devel/list/?series=662676=both
Here's the stuff we have now (we're currently rebasing and touching it up,
myself and @Yi Xie will be taking over this work.
Our plans are to add
After reviewing this whole history, maybe attached patch is able to fix your
problem. Can you have a try please?
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of
> Mikhail Gavrilov
> Sent: Tuesday, April 25, 2023 9:20 PM
> To: Koenig, Christian
> Cc: Daniel Vetter ;
Use the helper function in TTM to get TTM memory
limit and set KFD's internal mem limit. This ensures
that KFD's TTM mem limit and actual TTM mem limit are
exactly same.
Signed-off-by: Mukul Joshi
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 3 ++-
Use the helper function in TTM to get TTM mem limit and
set GTT size to be equal to TTL mem limit.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git
Add a helper function to get TTM memory limit. This is
needed by KFD to set its own internal memory limits.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/ttm/ttm_tt.c | 6 ++
include/drm/ttm/ttm_tt.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Chia-I Wu
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
index e9b45089a28a6..863b2a34b2d64
Use the new efficient frequency toggling interface. Also
create a helper function to restore the frequencies after
the test is done.
v2: Restore max freq first and then min.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 42 ++---
1 file
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent
On 26/04/2023 03:06, Dmitry Baryshkov wrote:
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
catalog files by setting the
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.
Signed-off-by: Marijn Suijten
---
On 26/04/2023 02:06, Marijn Suijten wrote:
Instead of hardcoding many register defines for every INTF and AD4 index
with a fixed stride, turn the defines into singular chunks of math that
compute the address using the base and this fixed stride multiplied by
the index given as argument to the
On 26/04/2023 02:05, Marijn Suijten wrote:
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes:
The pull request you sent on Mon, 24 Apr 2023 15:41:41 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-04-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8cc58e289ed3b5bc50258f52776cf3dfa3bad66
Thank you!
--
Deet-doot-dot, I am a bot.
On 2023-04-25 15:37:44, Abhinav Kumar wrote:
>
>
> On 4/25/2023 3:15 PM, Marijn Suijten wrote:
> > On 2023-04-25 14:55:56, Abhinav Kumar wrote:
> >
> >>> I'll see whether I can include these fixes before sending v3 (got all
> >>> the other changes in and am all-ready to send it): is there any
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via debugfs.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Marijn Suijten
Reviewed-by:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
Some of these members were initialized while never read, while others
were not even assigned any pointer value at all. Drop them to save some
space, and above all confusion when looking at or accidentally
dereferencing these members.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
Doing a for loop in every DPU HW block driver init to find a catalog
entry matching the given ID is rather useless if the init function
called by RM already has that catalog entry pointer, and uses exactly
its ID to drive this init and for loop. Remove all that machinery to
drop quite some lines
Now that newer DPU platforms use a readpointer-done interrupt on the
INTF block, stop providing the unused interrupt on the PINGPONG block.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit arguments depend on one of multiple
interrupt
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now replaced with a more obvious
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
---
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
catalog files by setting the intr_tear_rd_ptr to the IRQ index spcified
in the offset
From: Konrad Dybcio
Now that newer SoCs since DPU 5.0.0 manage tearcheck in the INTF instead
of PINGPONG block, move the struct definition to a common file. Also,
bring in documentation from msm-4.19 techpack while at it.
Signed-off-by: Konrad Dybcio
[Marijn: Also move dpu_hw_pp_vsync_info]
Instead of hardcoding many register defines for every INTF and AD4 index
with a fixed stride, turn the defines into singular chunks of math that
compute the address using the base and this fixed stride multiplied by
the index given as argument to the definitions.
MDP_SSPP_TOP0_OFF is dropped as
A bunch of registers were appended at the end in e.g. commit
91143873a05d ("drm/msm/dpu: Add MISR register support for interface")
rather than being inserted in a place that maintains numerical sorting:
restore said numerical sorting.
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusion.
Note that downstream enables the
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support. To clean this
up, move the logic
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce
SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and
no other registers, hence the DITHER name of the macro and a
corresponding PINGPONG block length of zero. However, the PP_BLK_ macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.
Signed-off-by: Marijn
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused
On 4/25/2023 3:15 PM, Marijn Suijten wrote:
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
I'll see whether I can include these fixes before sending v3 (got all
the other changes in and am all-ready to send it): is there any other
SoC you're seeing this issue on?
Thats alright, you can
On 2023-04-25 14:32:51, Abhinav Kumar wrote:
> > We can return NULL from dpu_hw_foo_init(), which would mean that the
> > block was skipped or is not present.
>
> An then replace the `if INTF_NONE continue` logic in dpu_rm_init with a
> check for NULL that skips, and a
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
> > I'll see whether I can include these fixes before sending v3 (got all
> > the other changes in and am all-ready to send it): is there any other
> > SoC you're seeing this issue on?
> >
>
> Thats alright, you can have it in a separate series not
On 4/25/2023 2:53 PM, Marijn Suijten wrote:
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
>
>
> On 4/25/2023 1:43 PM, Marijn Suijten wrote:
> > On 2023-04-25 09:47:30, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> >>> On 2023-04-25 09:18:58, Abhinav Kumar wrote:
>
>
> On 4/24/2023 11:54
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
---
Reviewed-by: Abhinav Kumar
On 4/25/2023 2:09 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
On 25/04/2023 10:16, Marijn Suijten
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
>
>
>
> On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
> > On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
> > wrote:
> >>
> >> On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
> >>> On 25/04/2023 10:16, Marijn Suijten wrote:
> On 2023-04-24
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
>
>
> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> > On 2023-04-25 09:18:58, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/24/2023 11:54 PM, Marijn Suijten wrote:
> >>> On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >>>
> >> dither block should be
Hi,
> Andrzej Hajda (7):
> lib/ref_tracker: add unlocked leak print helper
> lib/ref_tracker: improve printing stats
> lib/ref_tracker: add printing to memory buffer
> lib/ref_tracker: remove warnings in case of allocation failure
> drm/i915: Correct type of wakeref
Hi John,
> Dan Carpenter pointed out that 'err' was not being set in the case
> where the GuC firmware version range check fails. Fix that.
>
> Note that while this is bug fix for a previous patch (see Fixes tag
is _a_ bug fix.
> below). It is an exceedingly low risk bug. The range check is
>
Hi Andrzej,
On Tue, Apr 25, 2023 at 12:05:43AM +0200, Andrzej Hajda wrote:
> Beside reusing existing code, the main advantage of ref_tracker is
> tracking per instance of wakeref. It allows also to catch double
> put.
> On the other side we lose information about the first acquire and
> the last
On 4/25/23 16:28, Thomas Zimmermann wrote:
Make fbdev's built-in helpers for reading and writing I/O and system
memory available to DRM. Replace DRM's internal helpers.
The first patch resolves a bug that's been in the fbdev code for
more than 15 years. Makes the read/write helpers work
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use GEN9 as a prefix for register lists that contain all GEN8
> registers.
alan:snip
alan: This patch as a stand-along looks good, so I'll provide the RB but take
note of the comment below
that
The last 3 comments in this thread contain arguments that are false and
were specifically pointed out as false 6 comments ago: Soft resets are just
as fatal as hard resets. There is nothing better about soft resets. If the
VRAM is lost completely, that's a different story, and if the hard reset is
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Fix Xe_LP name.
>
> Signed-off-by: John Harrison
alan:snip
> -/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
> +/* GEN8+ Render / Compute Per-Engine-Instance */
alan: two comments on this:
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use 'xe_lp*' prefixes for register lists that are common with
> Gen8.
alan:snip
> @@ -177,32 +177,32 @@ static const struct __guc_mmio_reg_descr
> empty_regs_list[] = {
> static const struct
On Sat, 22 Apr 2023 22:50:01 +0200, Sebastian Reichel wrote:
> Add compatible value for Inanbo t28cp45tn89 and make reset GPIO non
> mandatory, since it might not be connected to the CPU.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/display/panel/sitronix,st7789v.yaml
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Remove 99% duplicated steered register list code. Also, include the
> pre-Xe steered registers in the pre-Xe list generation.
>
> Signed-off-by: John Harrison
alan: Nice work - good cleanup. Thanks
On 2023-04-25 06:41:54, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
>
> Quoting Jordan Justen (2023-04-24 20:13:00)
> > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> > >
> > > Being able to "list" supported extensions sounds like a
On Fri, Apr 21, 2023 at 05:43:05PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "ilitek,ili9805" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/ilitek,ili9805.yaml | 60 +++
>
On Fri, Apr 21, 2023 at 05:43:02PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "synaptics,r63353" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/synaptics,r63353.yaml | 58 +++
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
> From: John Harrison
>
> A pair of pre-Xe registers were being included in the Xe capture list.
> GuC was rejecting those as being invalid and logging errors about
> them. So, stop doing it.
>
alan:snip
> #define
On Tue, 2023-04-25 at 16:41 +0300, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
An orthogonal (but losely related) question: Is PXP the only subsystem that has
the unique problem of: Uses a delayed worker to complete all dependencies for
init..
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
>
Hi Arnd,
On Mon, Apr 17, 2023 at 11:04:11PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The empty stub functions are defined as global functions, which
> causes a warning because of missing prototypes:
>
> drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype
>
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
>
Thomas Zimmermann writes:
> Implement DRM fbdev helpers for reading and writing framebuffer
> memory with the respective fbdev functions. Removes duplicate
> code.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 174 +---
> 1 file
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure
Thomas Zimmermann writes:
> Move the existing CFB read and write code for I/O memory into
> the new helpers fb_cfb_read() and fb_cfb_write(). Make them the
> default fp_ops. No functional changes.
>
It would be nice to get an explanation here about why moving these
make sense. I guess you are
Thomas Zimmermann writes:
> Push the test for info->screen_base from fb_read() and fb_write() into
> the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
> the driver operates on info->screen_buffer, test this field instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Thomas Zimmermann writes:
> The file-op entry points fb_read() and fb_write() verify that
> info->state has been set to FBINFO_STATE_RUNNING. Remove the same
> test from the implementations of struct fb_ops.{fb_read,fb_write}.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
Maybe can expand the explanation a little bit with something like this?
"The struct fb_info has a union to store the framebuffer
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
>
>
> On 4/24/2023 11:54 PM, Marijn Suijten wrote:
> > On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >
> dither block should be present on many other chipsets too but looks like
> on sm8550 was enabling it. Not sure how it was validated
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure how it was validated there. But we
are enabling dither, even other chipsets have this block.
Thomas Zimmermann writes:
Hello Thomas,
> Always return the number of bytes read or written within the
> framebuffer. Only return an errno code if framebuffer memory
> was not touched. This is the semantics required by POSIX and
> makes fb_read() and fb_write() compatible with IGT tests. [1]
>
On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
On 25/04/2023 10:16, Marijn Suijten wrote:
On 2023-04-24 16:23:17, Abhinav Kumar wrote:
On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
On
On Tue, Apr 18, 2023 at 09:40:05AM +0200, Roman Beranek wrote:
> Assign pll-mipi parent to tcon0's source clock via 'assigned-clocks'.
>
> Signed-off-by: Roman Beranek
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
Hi,
On Tue, Apr 18, 2023 at 09:40:02AM +0200, Roman Beranek wrote:
> Propagating rate change from tcon0 all the way to pll-video0 allows for
> greater precision in matching requested display timing.
>
> Signed-off-by: Roman Beranek
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 ++-
> 1
On 25/04/2023 17:03, Thomas Zimmermann wrote:
(cc'ing dri-devel, Jocelyn and Sam)
Hi Phil,
I've put dri-devel into cc, which is the developer's mailing list. It's
the first time I hear about this bug.
Thanks for pointing this to me, I will take a look at it.
--
Jocelyn
Am 25.04.23 um
Perform the correct casting of the intermediate coefficients of the
RGB565 pixel conversion. Currently, the pixel conversion is using s64
for the intermediate coefficients, which is causing the IGT pixel-format
tests to fail. So, cast the operands to s32 in order to improve the
vkms' test
(cc'ing dri-devel, Jocelyn and Sam)
Hi Phil,
I've put dri-devel into cc, which is the developer's mailing list. It's
the first time I hear about this bug.
Am 25.04.23 um 16:25 schrieb ker...@linuxace.com:
Hi Thomas,
I have been trying to track down why we lost console on our Dell servers
Hi Dinh,
On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
> On 4/4/23 05:11, Maxime Ripard wrote:
> > The SoCFGPA gate clock implements a mux with a set_parent hook, but
> > doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since set_parent() is there to, as
On Thu, Apr 13, 2023 at 02:44:51PM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2023-04-04 03:10:50)
> > Hi,
> >
> > This is a follow-up to a previous series that was printing a warning
> > when a mux has a set_parent implementation but is missing
> > determine_rate().
> >
> > The
Make fbdev's built-in helpers for reading and writing I/O and system
memory available to DRM. Replace DRM's internal helpers.
The first patch resolves a bug that's been in the fbdev code for
more than 15 years. Makes the read/write helpers work successfully
with the IGT tests.
Patches 2 to 4
Push the test for info->screen_base from fb_read() and fb_write() into
the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
the driver operates on info->screen_buffer, test this field instead.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/cobalt_lcdfb.c | 6
1 - 100 of 148 matches
Mail list logo
