[Public]
Hi,
After investigating quite some time on this issue, found freeze problem is not
with the amdgpu part of buddy allocator patch as the patch doesn’t throw any
issues when applied separately on top of the stable base of drm-next. After
digging more into this issue, the below patch see
Hi Linus,
On Fri, May 27, 2022 at 06:04:14PM -0700, Linus Torvalds wrote:
> On Fri, May 27, 2022 at 4:41 PM Sudip Mukherjee
> wrote:
> >
> > I just tested with various values, sizeof(*edid) is 144 bytes at that place.
>
> Hmm. What compiler do you have? Because it seems very broken.
I am using
On Fri, May 27, 2022 at 06:04:14PM -0700, Linus Torvalds wrote:
> On Fri, May 27, 2022 at 4:41 PM Sudip Mukherjee
> wrote:
> >
> > I just tested with various values, sizeof(*edid) is 144 bytes at that place.
>
> Hmm. What compiler do you have? Because it seems very broken.
>
> You don't actually
sparse reports
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol
'gv100_fifo_runlist' was not declared. Should it be static?
gv100_fifo_runlist is only used in gv100.c, so change it to static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c | 2
This BUG_ON will never be reached, and there is a comment 20 above
explaining why.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 3e32
There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 19 +++
1 file
Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
480 (SM4350) and 750G (SM7225).
Signed-off-by: Konrad Dybcio
---
Changes since v2:
- Fix some values in a619_build_bw_table (I think I miscopied things last
time around..)
- Add a comment about icache/dcache allocation for f
Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 17 -
1 file
On Sat, 2022-05-28 at 18:03 +0200, Konrad Dybcio wrote:
> Leading spaces are not something checkpatch likes, and it says so when
> they are present. Use tabs consistently to indent function body and
> unwrap a 83-char-long line, as 100 is cool nowadays.
unassociated trivia:
> diff --git a/drivers
On 5/26/22 21:47, Javier Martinez Canillas wrote:
> Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather
> than .remove") fixed a use-after-free error due the vesafb driver freeing
> the fb_info in the .remove handler instead of doing it in .fb_destroy.
>
> This can happen if
On Sat, May 28, 2022 at 5:13 AM Sudip Mukherjee
wrote:
>
> just tried this with
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- drivers/gpu/drm/drm_edid.s
>
> size_of_edid:
> mov r0, #144@,
> ldmfd sp, {fp, sp, pc}@
So digging a bit deeper - since I have am
On Sat, May 28, 2022 at 10:40 AM Linus Torvalds
wrote:
>
> So digging a bit deeper - since I have am arm compiler after all - I
> note that 'sizeof(detailed_timings)' is 88.
Hmm.
sizeof() both
detailed_timings[0].data.other_data.data.range.formula.gtf2
and
detailed_timings[0].data.oth
On Sat, May 28, 2022 at 8:08 PM Linus Torvalds
wrote:
>
> Not very much tested, and I have no idea what it is that triggers this
> only on spear3xx_defconfig.
>
> Some ARM ABI issue that is triggered by some very particular ARM
> compiler flag enabled by that config?
It's CONFIG_ARM_AEABI, which
Hi Thomas,
On Mon, Oct 14, 2019 at 4:05 PM Thomas Zimmermann wrote:
> The display mode is set by converting the DRM display mode to an
> fb_info state and handling it to the fbdev driver's fb_setvar()
> function. This also requires a color depth, which we take from the
> value of struct drm_mode_
On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote:
>
> It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this
> option, you the kernel is built for the old 'OABI' that forces all non-packed
> struct members to be at least 16-bit aligned.
Looks like forced word (32 bit) alignment
On Sat, May 28, 2022 at 11:08:48AM -0700, Linus Torvalds wrote:
> This smells like a compiler bug triggered by "there's a 16-bit member
> field in that gtf2 structure, and despite it being packed and aligned
> to 1, we somehow still align the size to 2".
It's an age old thing, it's no compiler bug
On Sat, May 28, 2022 at 10:31 PM Linus Torvalds
wrote:
> On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote:
> >
> > It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this
> > option, you the kernel is built for the old 'OABI' that forces all
> > non-packed
> > struct members to
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d3fde8ff50ab265749704bd7fbcf70d35235421f Add linux-next specific
files for 20220527
Error/Warning reports:
https://lore.kernel.org/linux-mm/202205031017.4twman3l-...@intel.com
https://lore.kern
On Sat, 28 May 2022 at 08:44, Paneer Selvam, Arunpravin
wrote:
>
> [Public]
>
> Hi,
>
> After investigating quite some time on this issue, found freeze problem is
> not with the amdgpu part of buddy allocator patch as the patch doesn’t throw
> any issues when applied separately on top of the sta
19 matches
Mail list logo
