On Mon, Nov 8, 2021 at 10:06 AM xiazhengqiao
wrote:
>
> Add STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
>
> Signed-off-by: xiazhengqiao
Tested-by: Hsin-Yi Wang
Tested with a mt8183 katsu board [1] which uses this panel.
[1]
The get_sg_table() function does not return NULL.
It returns error pointers.
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index
Use __string(), __assign_str() and __get_str() helpers in the TRACE_EVENT()
instead of string definitions in gpu scheduler trace.
[ 158.890890] [ cut here ]
[ 158.890899] fmt: 'entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw
job count:%d
'
In some user scenarios, the get_timeline_name callback uses the flags to
decide which way to return the timeline string name. Once the
trace_dma_fence_init event is enabled, it will call get_timeline_name
callback to dump the fence structure. However, at this moment, the flags
are always 0, and it
Initialize the flags for embedded fence in the job at dma_fence_init().
Otherwise, we will go a wrong way in amdgpu_fence_get_timeline_name
callback and trigger a null pointer panic once we enabled the trace event
here.
[ 156.131790] BUG: kernel NULL pointer dereference, address:
[TLDR: adding this regression to regzbot; most of this mail is compiled
from a few templates paragraphs some of you might have seen already.]
Hi, this is your Linux kernel regression tracker speaking.
Top-posting for once, to make this easy accessible to everyone.
Thanks for the report.
Adding
he return value of kzalloc() needs to be checked.
To avoid use of null pointer '_state->base' in case of the
failure of alloc.
Fixes: f0adbc382b8b ("drm/ast: Allocate initial CRTC state of the correct size")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/ast/ast_mode.c | 3 ++-
1 file
On 22-11-21, 23:21, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> I recently came across some new uses of the 'slave_id' field that
> I had (almost) removed a few years ago. There are no legitimate
> uses of this field in the kernel, only a few stale references and
> two drivers that abuse the
https://bugzilla.kernel.org/show_bug.cgi?id=215315
Len Brown (l...@kernel.org) changed:
What|Removed |Added
CC||alexdeuc...@gmail.com,
https://bugzilla.kernel.org/show_bug.cgi?id=215315
Bug ID: 215315
Summary: [REGRESSION BISECTED] amdgpu crashes system suspend -
NUC8i7HVKVA
Product: Drivers
Version: 2.5
Kernel Version: 5.15-rc1, 5.15, 5.16-rc4
Am Mittwoch, 8. Dezember 2021, 16:12:19 CET schrieb Sascha Hauer:
> "vpll" is a misnomer. A clock input to a device should be named after
> the usage in the device, not after the clock that drives it. On the
> rk3568 the same clock is driven by the HPLL.
> To fix that, this patch renames the vpll
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #51 from T. Noah (aus...@tutanota.com) ---
A possible solution is to pass
amdgpu.dpm=0
as a kernel launch option.
However: this kills fps in many games and probably anything that depends on the
gpu for rendering.
--
You may reply
On Sun, Dec 12, 2021 at 12:24 AM Hector Martin wrote:
>
> This code is required for both simplefb and simpledrm, so let's move it
> into the OF core instead of having it as an ad-hoc initcall in the
> drivers.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Hector Martin
> ---
>
EPROBE_DEFER is a special error return code, that can happen during
normal system boot and should not be printed as an error.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_bridge.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c
Host transfer in DSI master will invoke only when the DSI commands
sent from DSI devices like DSI Panel or DSI bridges and this host
transfer wouldn't invoke I2C based DSI bridge drivers.
Handling DSI host initialization in transfer calls might miss the
controller setup for I2C configured DSI
Now the exynos dsi driver is fully aware of bridge handling,
so get the display mode from bridge, mode_set API instead of
legacy encoder crtc.
This makes bridge usage more efficient instead of relying on
encoder stack.
Add mode_set in drm_bridge_funcs.
Signed-off-by: Jagan Teki
---
Changes for
The new support drm bridges are moving towards atomic functions.
Replace atomic version of functions to continue the transition
to the atomic API.
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 -
1 file changed, 16
Existing driver is calling manual bridge pre_enable, enable,
disable and post_disable helpers with their enable and
disable functions.
Separate the enable code with pre_enable and enable helpers
like enable the DSI in pre_enable and set the display in enable.
Separate the disable code with
Convert the encoders to bridge drivers in order to standardize on
a single API with built-in dumb encoder support for compatibility
with existing component drivers.
Driver bridge conversion will help to reuse the same bridge on
different platforms as exynos dsi driver can be used as a Samsung
Replace the manual panel handling code by a drm panel_bridge via
devm_drm_of_get_bridge().
Adding panel_bridge handling,
- Drops drm_connector and related operations as drm_bridge_attach
creates connector during attachment.
- Drops panel pointer and iterate the bridge, so-that it can operate
Trigger the panel operation helpers only if host found the panel.
Add check.
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
Changes for v2:
- new patch
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Updated series about drm bridge conversion of exynos dsi.
Patch 1: panel checker
Patch 2: panel_bridge API
Patch 3: Bridge conversion
Patch 4: pree_enable, post_disable
Patch 5: Atomic functions
Patch 6: atomic_set
Patch 7: DSI init in enable
[1]
https://bugzilla.kernel.org/show_bug.cgi?id=207763
--- Comment #10 from rocca...@gmail.com ---
i forgot to mention that i have "AMD RV620/M82 [Mobility Radeon HD 3450/3470]"
i tried same live usb with persistence on other pc (buitin intel somewhat) and
all worked fine
--
You may reply to this
https://bugzilla.kernel.org/show_bug.cgi?id=207763
rocca...@gmail.com changed:
What|Removed |Added
CC||rocca...@gmail.com
--- Comment #9
A CP_PROTECT entry for SMMU registers is missing for A540. According to
downstream sources its length is same as on A530 - 0x2 bytes.
On all other revisions SMMU region length is 0x1 bytes. Despite
this, we setup region of length 0x2 on all revisions. This doesn't
cause any issues on
This GPU is found on SoCs such as MSM8953 (650 MHz), SDM450 (600 MHz),
SDM632 (725 MHz).
Signed-off-by: Vladimir Lypak
---
Changes since v1:
- don't change behaviour for other GPU revisions
- also setup CP_PROTECT for SMMU
- correct formatting
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 39
On Fri, Dec 03, 2021 at 09:51:10PM +0300, Dmitry Baryshkov wrote:
> On 22/10/2021 20:33, Bjorn Andersson wrote:
> > On Fri 22 Oct 04:43 PDT 2021, Vladimir Lypak wrote:
> >
> > > This GPU is found on SoCs such as MSM8953(650MHz), SDM450(600MHz),
> > > SDM632(725MHz).
> > >
> > > Signed-off-by:
According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain the
3 bytes of the IEEE OUI as well as any additional payload bytes needed."
Now DRM driver check HDMI OUI but VSDB payload size at least five bytes.
That may caused some HDMI monitors' audio feature can't be enabled.
Because of
GGTT was available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Move the GGTT from i915 to gt and use to_gt() for accesssing the
ggtt.
Signed-off-by: Andi Shyti
Cc: Michal Wajdeczko
Cc: Matt Roper
---
drivers/gpu/drm/i915/display/intel_fbc.c
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winiarski
Cc: Michal Wajdeczko
Signed-off-by:
In preparation of the multitile support, highlight the root GT by
calling it gt0 inside the drm i915 private data.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
---
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c| 38
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
Cc: Michał Winiarski
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem.c
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gvt/gvt.c | 2 +-
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 22
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
From: Michał Winiarski
To allow further refactoring and abstract away the fact that GT is
stored inside i915 private.
No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 7 +--
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
At this point the early initialization of the gt needs to be
broken in two parts where the first is needed to assign to the gt
the i915 private
Hi,
the first patch concludes the first stage of refactoring which
makes the use of intel_gt on the different subsystem. It's taken
from Matt's series and it has alread been reviewed. The patch has
just been replaced before any multitile patches and I think it
can be already pushed.
Patch 2-10
Sorry... messed up with git-send-email and the series is not
threaded. I'm going to resend it.
Andi
On Sun, Dec 12, 2021 at 05:10:55PM +0200, Andi Shyti wrote:
> Hi,
>
> the first patch concludes the first stage of refactoring which
> makes the use of intel_gt on the different subsystem. It's
GGTT was available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Move the GGTT from i915 to gt and use to_gt() for accesssing the
ggtt.
Signed-off-by: Andi Shyti
Cc: Michal Wajdeczko
Cc: Matt Roper
---
drivers/gpu/drm/i915/display/intel_fbc.c
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winiarski
Cc: Michal Wajdeczko
Signed-off-by:
In preparation of the multitile support, highlight the root GT by
calling it gt0 inside the drm i915 private data.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
---
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c| 38
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
Cc: Michał Winiarski
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem.c
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gvt/gvt.c | 2 +-
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 22
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
From: Michał Winiarski
To allow further refactoring and abstract away the fact that GT is
stored inside i915 private.
No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 7 +--
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
At this point the early initialization of the gt needs to be
broken in two parts where the first is needed to assign to the gt
the i915 private
Hi,
the first patch concludes the first stage of refactoring which
makes the use of intel_gt on the different subsystem. It's taken
from Matt's series and it has alread been reviewed. The patch has
just been replaced before any multitile patches and I think it
can be already pushed.
Patch 2-10
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Fri, Oct 22, 2021 at 10:33:29AM -0700, Bjorn Andersson wrote:
> On Fri 22 Oct 04:43 PDT 2021, Vladimir Lypak wrote:
>
> > This GPU is found on SoCs such as MSM8953(650MHz), SDM450(600MHz),
> > SDM632(725MHz).
> >
> > Signed-off-by: Vladimir Lypak
> > ---
> >
Hi
On Fri, Dec 10, 2021 at 4:48 PM Dave Stevenson
wrote:
>
> Hi Michael
>
> On Fri, 10 Dec 2021 at 09:05, Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi Dave
> >
> > some questions below
> >
> > On Thu, Dec 9, 2021 at 7:10 PM Michael Nazzareno Trimarchi
> > wrote:
> > >
> > > Hi Dave
> > >
>
On Fri, Dec 10, 2021 at 09:00:56AM +, Wang, Zhi A wrote:
> On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> > Constify a number of static structs that are never modified to allow the
> > compiler to put them in read-only memory. In order to do this, constify a
> > number of local variables and
On Fri, Dec 10, 2021 at 08:20:22AM +, Wang, Zhi A wrote:
> On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> > These are never modified, so make them const to allow the compiler to
> > put them in read-only memory. WHile at it, make the description const
> > char* since it is never modified.
>
The devm_gen_pool_create() function does not return NULL. It
returns error pointers.
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/vboxvideo/vbox_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
Hi,
On 12/11/21 15:49, Miaoqian Lin wrote:
> The devm_gen_pool_create() function does not return NULL. It
> returns error pointers.
>
> Signed-off-by: Miaoqian Lin
This is already fixed in linux-next, see:
https://bugzilla.kernel.org/show_bug.cgi?id=210787
Janpieter Sollie (janpieter.sol...@edpnet.be) changed:
What|Removed |Added
Status|NEW |RESOLVED
62 matches
Mail list logo
