There's no user for that pointer so let's just get rid of it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vc4/vc4_txp.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm
There's already a regset in the vc4_crtc structure so there's no need to
duplicate it in vc4_txp.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_txp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c
drm_connector_unregister() is only to be used for connectors that have been
registered through drm_connector_register() after drm_dev_register() has
been called. This is our case here so let's remove the call.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_txp.c | 10 ++
1 file
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers
Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.
This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_un
The VC4 VEC driver private structure contains only a pointer to the
encoder and connector it implements. This makes the overall structure
somewhat inconsistent with the rest of the driver, and complicates its
initialisation without any apparent gain.
Let's embed the drm_encoder structure (through
Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.
This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_un
There's no user for that pointer so let's just get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vc4/vc4_vec.c | 7 ---
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 9c5b31f
drm_connector_unregister() is only to be used for connectors that have been
registered through drm_connector_register() after drm_dev_register() has
been called. This is our case here so let's remove the call.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 10 ++
1 file
Our current code now mixes some resources whose lifetime are tied to the
device (clocks, IO mappings, etc.) and some that are tied to the DRM device
(encoder, bridge).
The device one will be freed at unbind time, but the DRM one will only be
freed when the last user of the DRM device closes its fi
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/dri
Whenever the device and driver are unbound, the main device and all the
subdevices will be removed by calling their unbind() method.
However, the DRM device itself will only be freed when the last user will
have closed it.
It means that there is a time window where the device and its resources
ar
Our current code now mixes some resources whose lifetime are tied to the
device (clocks, IO mappings, etc.) and some that are tied to the DRM device
(encoder, bridge).
The device one will be freed at unbind time, but the DRM one will only be
freed when the last user of the DRM device closes its fi
The vc4 has a custom API to allow components to register a debugfs file
before the DRM driver has been registered and the debugfs_init hook has
been called.
However, the .late_register hook allows to have the debugfs file creation
deferred after that time already.
Let's remove our custom code to
The current code will call drm_connector_unregister() and
drm_connector_cleanup() when the device is unbound. However, by then, there
might still be some references held to that connector, including by the
userspace that might still have the DRM device open.
Let's switch to a DRM-managed initializ
mutex_init is supposed to be balanced by a call to mutex_destroy that we
were never doing in the vc4 driver.
Since a DRM-managed mutex_init variant has been introduced, let's just
switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 15 +--
drivers/gpu/drm
The vc4_irq_disable(), among other things, will call disable_irq() to
complete any in-flight interrupts.
This requires its counterpart, vc4_irq_enable(), to call enable_irq() which
causes issues addressed in a later patch.
However, vc4_irq_disable() is called by two callees: vc4_irq_uninstall()
a
At bind time, vc4_v3d_bind() will read a register to retrieve the v3d
version and make sure it's a version we're compatible with.
However, the v3d has an optional clock that is enabled only after the
register read-out and a power domain that wasn't enabled at all in the bind
implementation. This w
vc4_debugfs_add_file() can fail, so let's propagate its error code instead
of silencing it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_debugfs.c | 20 +++-
drivers/gpu/drm/vc4/vc4_drv.h | 30 --
2 files changed, 27 insertions(+), 23 d
vc4_perfmon_open_file() will instantiate a mutex for that file instance,
but we never call mutex_destroy () in vc4_perfmon_close_file().
Let's add that missing call.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gp
The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.
Let's switch to a DRM-managed initialization to clean up after ourselves
o
devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_v3d.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/d
On 2022-06-29 at 13:14:26 +0100, Matthew Auld wrote:
> Falling back to memcpy/memset shouldn't be allowed if we know we have
> CCS state to manage using the blitter. Otherwise we are potentially
> leaving the aux CCS state in an unknown state, which smells like an info
> leak.
>
> Fixes: 48760ffe9
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #29 from Alex Deucher (alexdeuc...@gmail.com) ---
Do they also work when you set amdgpu.dc=0 or has that always had problems for
you?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watc
On Wed, 29 Jun 2022, Maxime Ripard wrote:
> Connectors need to be cleaned up with a call to drm_connector_cleanup()
> in their drm_connector_funcs.destroy implementation.
>
> Let's check for this and complain if there's no such function.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/d
https://bugzilla.kernel.org/show_bug.cgi?id=216173
--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
Duplicate of:
https://bugzilla.kernel.org/show_bug.cgi?id=216120
https://gitlab.freedesktop.org/drm/amd/-/issues/2050
--
You may reply to this email to add a comment.
You are receivi
Hi!
> From: Maxime Ripard
>
> [ Upstream commit 2523e9dcc3be91bf9fdc0d1e542557ca00bbef42 ]
>
> We'll need to extend the vc4_async_flip_state structure to rely on
> another callback implementation, so let's move the current one into a
> union.
This and [04/22] drm/vc4: crtc: Use an union to sto
Hi!
> From: Xiang wangx
>
> [ Upstream commit fc378794a2f7a19cf26010dc33b89ba608d4c70f ]
>
> Delete the redundant word 'its'.
Calling typo in comment "syntax error" is ... interesting. Anyway, we
don't need this in stable.
Best regards,
Hi!
> [ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
>
> clk_put() already checks the clk ptr using !clk and IS_ERR()
> so there is no need to check it again before calling it.
Nice cleanup, but not a bugfix; we don't need it in -stable.
Best regards,
On Tue, 07 Jun 2022, Lyude Paul wrote:
> We already open-code this quite often, and will be iterating through
> payloads even more once we've moved all of the payload tracking into the
> atomic state. So, let's add a helper for doing this.
>
> Signed-off-by: Lyude Paul
> Cc: Wayne Lin
> Cc: Vill
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #30 from Harald Judt (h.j...@gmx.at) ---
I will have to test this. I have not known this option exists and what it does
nor what will happen if I disable it and if that is good or bad, so I have
never used it before.
--
You may reply
On Tue, 07 Jun 2022, Lyude Paul wrote:
> As Daniel Vetter pointed out, if we only use the atomic modesetting locks
> with MST it's technically possible for a driver with non-blocking modesets
> to race when it comes to MST displays - as we make the mistake of not doing
> our own CRTC commit tracki
On Mi, 2022-06-29 at 14:34 +0200, Maxime Ripard wrote:
> The DRM-managed function to register an encoder is
> drmm_encoder_alloc() and its variants, which will allocate the underlying
> structure and initialisation the encoder.
>
> However, we might want to separate the structure creation and the
On Tue, 07 Jun 2022, Lyude Paul wrote:
> Ugh, thanks ./scripts/get_maintainers.pl for confusing and breaking
> git-send email <<. Sorry for the resend everyone.
>
> For quite a while we've been carrying around a lot of legacy modesetting
> code in the MST helpers that has been rather annoying to k
[Dropped most people from Cc, keeping only lists]
On Wed, Jun 29, 2022 at 04:11:26PM +0300, Andrey Ryabinin wrote:
> On 6/28/22 17:03, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
> > (Only an error message is
Hi Dmitry,
>On 21/06/2022 13:53, Vinod Polimera wrote:
>> Add support for basic panel self refresh (PSR) feature for eDP.
>> Add a new interface to set PSR state in the sink from DPU.
>> Program the eDP controller to issue PSR enter and exit SDP to the
>> sink.
>>
>> Signed-off-by: Sankeerth Billa
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #31 from Harald Judt (h.j...@gmx.at) ---
Created attachment 301306
--> https://bugzilla.kernel.org/attachment.cgi?id=301306&action=edit
dmesg.out
amdgpu.dc=0 doesn't seem to make any practical difference.
BTW: With the new patchset
My apologies for the late reply...
On 01/06/2022 03:40, yuji2.ishik...@toshiba.co.jp wrote:
> Hi Hans,
>
> Thank you for your advice.
> I prepared some description of DNN accelerator and its usage.
>
> Handling memory blocks for Visconti5 accelerators
>
> Visconti5 Image-Processing-Acceler
Hi Dmitry,
>On 21/06/2022 13:53, Vinod Polimera wrote:
>> This change avoids panel prepare/unprepare based on self-refresh
>> state.
>>
>> Signed-off-by: Sankeerth Billakanti
>> Signed-off-by: Kalyan Thota
>> Signed-off-by: Vinod Polimera
>> ---
>> drivers/gpu/drm/bridge/panel.c | 102
>++
On 6/28/22 16:03, Uwe Kleine-König wrote:
From: Uwe Kleine-König
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. Th
On Wed, Jun 29, 2022 at 2:23 AM Rob Herring wrote:
>
> On Mon, Jun 27, 2022 at 02:43:39PM -0700, Prashant Malani wrote:
> > Hello Rob,
> >
> > On Mon, Jun 27, 2022 at 2:04 PM Rob Herring wrote:
> > >
> > > On Wed, Jun 22, 2022 at 05:34:30PM +, Prashant Malani wrote:
> > > > Introduce a bindin
On Wed, Jun 29, 2022 at 03:32:12PM +0200, Philipp Zabel wrote:
> On Mi, 2022-06-29 at 14:34 +0200, Maxime Ripard wrote:
> > The DRM-managed function to register an encoder is
> > drmm_encoder_alloc() and its variants, which will allocate the underlying
> > structure and initialisation the encoder.
On 27/06/2022 15:50, Pekka Paalanen wrote:
On Mon, 27 Jun 2022 13:40:04 +
Dennis Tsiang wrote:
This patch is an early RFC to discuss the viable options and
alternatives for inclusion of unsigned integer formats for the DRM API.
This patch adds a new single component 16-bit and a two compo
On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang
wrote:
> Thanks for your comments. This is not intended to be used for KMS, where
> indeed there would be no difference. This proposal is for other Graphics
> APIs such as Vulkan, which requires the application to be explicit
> upfront about
On Wed, Jun 29, 2022 at 10:33 PM Pin-yen Lin wrote:
>
> On Wed, Jun 29, 2022 at 2:23 AM Rob Herring wrote:
> >
> > On Mon, Jun 27, 2022 at 02:43:39PM -0700, Prashant Malani wrote:
> > > Hello Rob,
> > >
> > > On Mon, Jun 27, 2022 at 2:04 PM Rob Herring wrote:
> > > >
> > > > On Wed, Jun 22, 2022
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no
From: Chris Wilson
As an extension of the current skip TLB invalidations,
check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed.
This becomes more significant with GuC, as it can o
i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
When such test runs, the only output is:
[ 68.811639] i915: Performing live selftes
From: Chris Wilson
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmi
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
>.. which for me means a different patch 1, followed by patch 6 (moved
> to be patch 2) would be ideal stable material.
>
> Then we have the current patch 2 which is open/unknown (to me at least).
>
> And the rest seem like optimisations
Hi Andy,
Sorry for the late reply, I have some questions to ask you below. Thanks!
Andy Shevchenko 於 2022年6月24日 週五 凌晨2:56寫道：
>
> On Thu, Jun 23, 2022 at 2:00 PM ChiaEn Wu wrote:
> >
> > From: ChiaEn Wu
> >
> > Add Mediatek MT6370 charger driver.
>
> ...
>
> > +config CHARGER_MT6370
> > +
On Tue, Jun 28, 2022 at 10:32 PM Akhil P Oommen
wrote:
>
> On 6/29/2022 9:59 AM, Bjorn Andersson wrote:
> > On Tue 10 May 02:53 CDT 2022, Akhil P Oommen wrote:
> >
> >> Add a new sku to the fuse map of 7c3 gpu.
> >>
> >> Signed-off-by: Akhil P Oommen
> > Is this series still needed/wanted? I've b
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.
Then we have the current patch 2 which is open/unknown (to me at le
This series contains:
Cleanup:
- Convert to use devm_i2c_new_dummy_device()
- Use pm_runtime_force_suspend(resume)
Fixes:
- Fix NULL pointer crash when using edp-panel
and Impelment wait_hpd_asserted() callback.
The patches are not related to each other, but they are all
anx7625 patches so they ar
Simplify the resource management.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 96 +++
1 file changed, 27 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 3
Move devm_of_dp_aux_populate_ep_devices() after pm runtime and i2c setup
to avoid NULL pointer crash.
edp-panel probe (generic_edp_panel_probe) calls pm_runtime_get_sync() to
read EDID. At this time, bridge should have pm runtime enabled and i2c
clients ready.
Fixes: adca62ec370c ("drm/bridge: an
There's no need to check for IRQ or disable it in suspend.
Use pm_runtime_force_suspend(resume) to make sure anx7625 is powered off
correctly. Make the system suspend/resume and pm runtime suspend/resume
more consistant.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix/anx7625.c
Move hpd polling check into wait_hpd_asserted() callback. For the cases
that aux transfer function wasn't used, do hpd polling check after pm
runtime resume, which will power on the bridge.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 33 ++-
1
On Tue, Jun 28, 2022 at 6:46 PM Hsin-Yi Wang wrote:
>
> There's no need to check for IRQ or disable it in suspend.
>
> Use pm_runtime_force_suspend(resume) to make sure anx7625 is powered off
> correctly. Make the system suspend/resume and pm runtime suspend/resume
> more consistant.
>
> Signed-of
Hi Jani, let me know if you need more info or more changes are needed. Thanks!
On Wed, May 25, 2022 at 3:31 PM Mark Yacoub wrote:
>
> Hi Jani, thanks for your review. I got all the user space
> implementation ready to see it in context.
>
> libdrm patch to wrap this functionality:
> https://www.s
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now w
On 6/29/22 14:14, Matthew Auld wrote:
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
v2: (Nirmoy & Thomas):
- s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.
Signed-off-by: Matthew Auld
C
On 6/29/22 14:14, Matthew Auld wrote:
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.
Signed-off-by: Matthew Au
On Thu, 16 Jun 2022 15:32:53 +0100, Charles Keepax wrote:
> Historically, the legacy DAI naming scheme was applied to platform
> drivers and the newer scheme to CODEC drivers. During componentisation
> the core lost the knowledge of if a driver was a CODEC or platform, they
> were all now component
On Thu, 23 Jun 2022 13:51:14 +0100, Charles Keepax wrote:
> Historically, the legacy DAI naming scheme was applied to platform
> drivers and the newer scheme to CODEC drivers. During componentisation
> the core lost the knowledge of if a driver was a CODEC or platform, they
> were all now component
On 29/06/2022 17:11, Thomas Hellström wrote:
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this f
On 29/06/2022 17:22, Thomas Hellström wrote:
On 6/29/22 14:14, Matthew Auld wrote:
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
obje
On 6/29/22 18:28, Matthew Auld wrote:
On 29/06/2022 17:11, Thomas Hellström wrote:
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or mems
On Wed, Jun 29, 2022 at 9:01 AM Pin-yen Lin wrote:
>
> On Wed, Jun 29, 2022 at 10:33 PM Pin-yen Lin wrote:
> >
> > On Wed, Jun 29, 2022 at 2:23 AM Rob Herring wrote:
> > >
> > > On Mon, Jun 27, 2022 at 02:43:39PM -0700, Prashant Malani wrote:
> > > > Hello Rob,
> > > >
> > > > On Mon, Jun 27, 20
Hi Thomas,
On Tue, 21 Jun 2022, Thomas Zimmermann wrote:
Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.
Fbdev's deferred I/O can only track pages. From the range of pages, the
damage handler computes the clipping rectangle
On 29.06.22 05:54, Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should be allowed to pin such me
On 6/29/22 00:23, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20220628:
>
on i386:
ld: drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.o: in function
`dcn32_init_clocks':
dcn32_clk_mgr.c:(.text+0x70d): undefined reference to `__nedf2'
ld: dcn32_clk_mgr.c:(.text+0x9bf): und
Make sure bridge_disable will be called before suspend by calling
drm_mode_config_helper_suspend() in .prepare callback.
Signed-off-by: Hsin-Yi Wang
---
The issue is found if suspend is called via VT2 in several MTK SoC (eg.
MT8173, MT8183, MT8186) chromebook boards with eDP bridge:
bridge disabl
On Wed, Jun 29, 2022 at 3:05 PM Randy Dunlap wrote:
>
>
>
> On 6/29/22 00:23, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20220628:
> >
>
> on i386:
>
> ld: drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.o: in function
> `dcn32_init_clocks':
> dcn32_clk_mgr.c:(.text+0x70
Hi Dave, Daniel,
Fixes for 5.19.
The following changes since commit 76f0544428aced9e2f0d50ac7429e0f3064658cd:
Merge tag 'drm-msm-fixes-2022-06-28' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes (2022-06-29 14:16:46
+1000)
are available in the Git repository at:
https://gitlab.f
Hi Uwe,
On 22. 6. 28. 23:03, Uwe Kleine-König wrote:
> static const struct of_device_id atmel_sha204a_dt_ids[] = {
> diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
> index 40c07f4d656e..d1c674f3f2b9 100644
> --- a/drivers/extcon/extcon-rt8973a.c
> +++ b/drivers/extc
This series fixes possible out-of-bound memory accesses when users trigger
screen resolutions changes with invalid input parameters, e.g. reconfigures
screen which is smaller than the current font size, or if the virtual screen
size is smaller than the physical screen size.
Helge Deller (5):
fbc
The virtual screen size can't be smaller than the physical screen size.
Based on the general rule that we round up user-provided input if
neccessary, adjust the virtual screen size as well if needed.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org # v5.4+
---
drivers/video/fbdev/core/fbme
We need to prevent that users configure a screen size which is smaller than the
currently selected font size. Otherwise rendering chars on the screen will
access memory outside the graphics memory region.
This patch adds a new function fbcon_modechange_possible() which
implements this check and wh
Prevent that drivers configure a virtual screen resolution smaller than
the physical screen resolution. This is important, because otherwise we
may access memory outside of the graphics memory area.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org # v5.4+
---
drivers/video/fbdev/core/fbme
Prevent that users set a font size which is bigger than the physical screen.
It's unlikely this may happen (because screens are usually much larger than the
fonts and each font char is limited to 32x32 pixels), but it may happen on
smaller screens/LCD displays.
Signed-off-by: Helge Deller
Reviewe
Use the fbcon_info_from_console() wrapper which was added to kernel
v5.19 with commit 409d6c95f9c6 ("fbcon: Introduce wrapper for console->fb_info
lookup").
Signed-off-by: Helge Deller
---
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
sparse reports
drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches'
was not declared. Should it be static?
vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier
should be static.
Fixes: da8e393e23ef ("drm/vc4: drv: Adopt the dma configuration f
On 6/29/22 09:03, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Tue, Jun 28, 2022 at 10:52 PM Helge Deller wrote:
>> On 6/28/22 10:39, Geert Uytterhoeven wrote:
>>> On Sun, Jun 26, 2022 at 12:33 PM Helge Deller wrote:
We need to prevent that users configure a screen size which is smaller
>>>
Sorry for the late review. I finally got some time to look at this.
On Mon, 16 May 2022 16:56:39 -0600
Jim Cromie wrote:
> diff --git a/include/trace/events/drm.h b/include/trace/events/drm.h
> new file mode 100644
> index ..6de80dd68620
> --- /dev/null
> +++ b/include/trace/event
On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> diff --git a/drivers/usb/typec/hd3ss3220.c b/drivers/usb/typec/hd3ss3220.c
> index cd47c3597e19..2a58185fb14c 100644
> --- a/drivers/usb/typec/hd3ss3220.c
> +++ b/drivers/usb/typec/hd3ss3220.c
> @@ -245,14 +245,12 @@ static int hd3
On Tue, 28 Jun 2022 16:03:12 +0200
Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the remove
On 28/06/2022 16:03, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the remove function to retu
On Tue, Jun 28, 2022 at 4:08 PM Uwe Kleine-König
wrote:
>
> drivers/auxdisplay/ht16k33.c | 4 +---
> drivers/auxdisplay/lcd2s.c| 3 +--
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Mon, 27 Jun 2022 at 14:38, Daniel Vetter wrote:
>
> On Sat, Jun 25, 2022 at 01:01:14PM +0200, Jason A. Donenfeld wrote:
> > This is already set by anon_inode_getfile(), since dma_buf_fops has
> > non-NULL ->llseek, so we don't need to set it here too.
> >
> > Suggested-by: Al Viro
> > Cc: Sumi
On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the re
Hi Maxime,
i tested todays drm-misc-next 9db35bb349 with Raspberry Pi 3 B Plus
(arm/multi_v7_defconfig, mainline DTB) and get the following warning in
the kernel logs:
[ 25.698459] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
[ 25.698657] [ cut here ]---
This reverts commit 52e842432f36d5b15227d0ee0d2aa3d2bc3cc0b2.
The DT support never would have worked because there's no platform_data
providing ops. There's not any documented binding for it either.
Cc: Jingoo Han
Signed-off-by: Rob Herring
---
drivers/video/backlight/platform_lcd.c | 10 -
From: Rob Clark
A couple things useful for debugging iova faults:
1. caputre all buffer addresses and sizes even if we don't capture their
contents.
2. capture the GEM buffer debug labels
Rob Clark (2):
drm/msm/gpu: Capture all BO addr+size in devcore
drm/msm/gpu: Add GEM debug label to
From: Rob Clark
It is useful to know what buffers userspace thinks are associated with
the submit, even if we don't care to capture their content. This brings
things more inline with $debugfs/rd cmdstream dumping.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 36 ---
From: Rob Clark
When trying to understand an iova fault devcore, once you figure out
which buffer we accessed beyond the end of, it is useful to see the
buffer's debug label.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 +
drivers/gpu/drm/msm/msm_gpu.c | 4
Hi,
[keeping only individuals and lists in Cc to avoid bounces]
On 28/06/22 16:03, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignor
Quoting Rob Herring (2022-06-29 10:58:52)
> On Wed, Jun 29, 2022 at 9:01 AM Pin-yen Lin wrote:
> > >
> > > Yes it6505 is just a protocol converter. But in our use case, the output
> > > DP
> > > lines are connected to the Type-C ports and the chip has to know which
> > > port has DP Alt mode enab
On 2022-06-29 03:33, David Hildenbrand wrote:
On 29.06.22 05:54, Alex Sierra wrote:
is_pinnable_page() and folio_is_pinnable() were renamed to
is_longterm_pinnable_page() and folio_is_longterm_pinnable()
respectively. These functions are used in the FOLL_LONGTERM flag
context.
Subject talks abo
On 30.06.22 00:08, Felix Kuehling wrote:
> On 2022-06-29 03:33, David Hildenbrand wrote:
>> On 29.06.22 05:54, Alex Sierra wrote:
>>> is_pinnable_page() and folio_is_pinnable() were renamed to
>>> is_longterm_pinnable_page() and folio_is_longterm_pinnable()
>>> respectively. These functions are use
101 - 200 of 254 matches
Mail list logo
