Most aspeed devices have a BMC, which allows to remotely see the screen.
Also in the common use case, those servers don't have a display connected.
So add a Virtual connector, to reflect that even if no display is
connected, the framebuffer can still be seen remotely.
This prepares the work to impl
Aspeed always report the display port as "connected", because it
doesn't set a .detect_ctx callback.
Fix this by providing the proper detect callback for astdp and dp501.
This also fixes the following regression:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP") T
It looks like my SMTP server has lost the second patch, so I'm
re-sending the series.
--
Jocelyn
On 12/07/2023 17:17, Jocelyn Falempe wrote:
Most aspeed devices have a BMC, which allows to remotely see the screen.
Also in the common use case, those servers don't have a display connected.
So
[Adding Arun]
Am 12.07.23 um 16:28 schrieb Mauro Carvalho Chehab:
As an example for the new documentation tool, add a documentation
for drm_buddy_test.
I opted to place this on a completely different directory, in order
to make easier to test the feature with:
$ make SPHINXDIRS="tests"
Hi,
Am Donnerstag, 13. Juli 2023, 00:34:47 CEST schrieb Tim Harvey:
> On Wed, May 3, 2023 at 9:33 AM Frieder Schrempf wrote:
> > From: Frieder Schrempf
> >
> > According to the documentation [1] the proper enable flow is:
> >
> > 1. Enable DSI link and keep data lanes in LP-11 (stop state)
> >
Hi
Am 12.07.23 um 20:32 schrieb Simon Ser:
Since commit 6b85aa68d9d5 ("drm: Enable PRIME import/export for all
drivers"), import/export is always supported. Document this so that
user-space knows what to expect.
Signed-off-by: Simon Ser
Cc: Thomas Zimmermann
Cc: Alex Deucher
Cc: Jeffrey Hugo
Em Wed, 12 Jul 2023 18:03:00 +0300
Jani Nikula escreveu:
> On Wed, 12 Jul 2023, Mauro Carvalho Chehab wrote:
> > diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
> > b/drivers/gpu/drm/tests/drm_buddy_test.c
> > index 09ee6f6af896..dd6c5afd6cd6 100644
> > --- a/drivers/gpu/drm/tests/drm_buddy
On Fri, Apr 21, 2023 at 10:16 AM Nancy.Lin wrote:
>
> fix Smatch static checker warning
> - uninitialized symbol comp_pdev in mtk_ddp_comp_init.
>
> Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for
> MT8195")
> Signed-off-by: Nancy.Lin
Reviewed-by: Fei Shao
This seems
The msm_gem_get_vaddr() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl")
Signed-off-by: Gaosheng Cui
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
1 file changed, 1 in
The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
1 file
The mipi_dsi_device_register_full() returns an ERR_PTR() on failure,
we should use IS_ERR() to check the return value.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 2 +-
1 fi
v2:
- I'm sorry I missed some emails, these patches were submitted last year,
now let me resend it with the following changes:
1. remove the patch: "drm/msm: Fix IS_ERR_OR_NULL() vs NULL check in
msm_icc_get()"
2. remove the patch: "drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kms"
3.
[AMD Official Use Only - General]
Any comments? Any advice?
Best Regards,
Wenyou
> -Original Message-
> From: Wenyou Yang
> Sent: Wednesday, June 21, 2023 2:32 PM
> To: Deucher, Alexander ; Limonciello, Mario
> ; Koenig, Christian ;
> Pan, Xinhui ; Quan, Evan
> Cc: Yuan, Perry ; Liang,
On Wed, Jul 12, 2023 at 5:34 PM Tim Harvey wrote:
>
> On Wed, May 3, 2023 at 9:33 AM Frieder Schrempf wrote:
> >
> > From: Frieder Schrempf
> >
> > According to the documentation [1] the proper enable flow is:
> >
> > 1. Enable DSI link and keep data lanes in LP-11 (stop state)
> > 2. Disable st
csky:
Acked-by: Guo Ren
On Fri, Jul 7, 2023 at 5:56 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> A number of architectures either kept the screen_info definition for
> historical purposes as it used to be required by the generic VT code, or
> they copied it from another architecture in o
> -Original Message-
> From: Tuo Li
> Sent: Friday, June 30, 2023 11:19 AM
> To: inki@samsung.com; sw0312@samsung.com;
> kyungmin.p...@samsung.com; airl...@gmail.com; dan...@ffwll.ch;
> krzysztof.kozlow...@linaro.org; alim.akh...@samsung.com
> Cc: dri-devel@lists.freedesktop.org
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
between commit:
570b295248b0 ("drm/amdgpu: fix number of fence calculations")
from Linus' tree and commit:
ca6c1e210aa7 ("drm/amdgpu: use the new drm_exec object for CS v3")
On 11/10/2022 1:44 AM, Gaosheng Cui wrote:
The msm_gem_get_vaddr() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
Hi Carlos,
Em 27/06/2023 15:22, Carlos Eduardo Gallo Filho escreveu:
[...]
So, replace each drm_framebuffer_plane_{width,height} and
fb_plane_{width,height} call to drm_format_info_plane_{width,height}
and remove them.
I see that with this replace, there's a small code change from
r
On 7/12/23 18:12, Andrew Lunn wrote:
+/**
+ * wbrf_supported_producer - Determine if the device can report frequencies
+ *
+ * @dev: device pointer
+ *
+ * WBRF is used to mitigate devices that cause harmonic interference.
+ * This function will determine if this device needs to report such
freq
> +/**
> + * wbrf_supported_producer - Determine if the device can report frequencies
> + *
> + * @dev: device pointer
> + *
> + * WBRF is used to mitigate devices that cause harmonic interference.
> + * This function will determine if this device needs to report such
> frequencies.
How is the WB
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.
That said, all subsytems th
Having a fence linked to a virtio_gpu_framebuffer in plane update sequence
would cause conflict when several planes referencing the same framebuffer
especially when those planes are updated concurrently (e.g. Xorg screen
covering multi-displays configured for an extended mode). So it is better
for
This helper is needed for framebuffer synchronization. Old framebuffer data
is often displayed on the guest display without this helper.
Cc: Gerd Hoffmann
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4
1 file changed, 4 insertions(+)
diff -
virtio_gpu_fence_release is added to free virtio-gpu-fence
upon release of dma_fence.
Cc: Gerd Hoffmann
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
"Resubmission"
This series is for fixing issues regarding scanout synchronization with
host (e.g. QEMU/KVM) that uses virtio-gpu. This was submitted a while ago
but didn't get enough feedback/reviews so I am trying it again. This is a
rebased version. And the previous version is at
https://lists.f
On Wed, May 3, 2023 at 9:33 AM Frieder Schrempf wrote:
>
> From: Frieder Schrempf
>
> According to the documentation [1] the proper enable flow is:
>
> 1. Enable DSI link and keep data lanes in LP-11 (stop state)
> 2. Disable stop state to bring data lanes into HS mode
>
> Currently we do this al
On Wed, Jul 12, 2023 at 2:43 PM Marek Vasut wrote:
>
> On 7/12/23 20:52, Tim Harvey wrote:
> > Greetings,
>
> Tim,
>
> > I've noticed a regression in 6.5-rc1 that I'm having trouble bisecting
> > between 6.4 with regards to imx8mm MIPI DSI.
> >
> > I'm testing on an imx8mm-venice-gw72xx-0x with th
From: Rob Clark
In an error path where the submit is free'd without the job being run,
the hw_fence pointer is simply a kzalloc'd block of memory. In this
case we should just kfree() it, rather than trying to decrement it's
reference count. Fortunately we can tell that this is the case by
check
On 12/07/2023 04:20, Abhinav Kumar wrote:
dpu_hw_intf has a few instances of structs which do not have
the dpu_hw prefix. Lets fix this by renaming those structs
and updating the usage of those accordingly.
Signed-off-by: Abhinav Kumar
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 +
On 12/07/2023 04:20, Abhinav Kumar wrote:
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
changes in v5:
dpu_core_perf.c contains several multi-line conditions which are hard to
comprehent because of the indentation. Rework the identation of these
conditions to make it easier to understand them.
Reviewed-by: Abhinav Kumar
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 ++--
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
This function does nothing, just clears one struct field. Drop it now.
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 --
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
Skip bandwidth aggregation and return early if there are no interconnect
paths defined for the DPU device.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_c
dpu_core_perf should not make decisions on the maximum possible core
clock rate. Pass the value from dpu_kms_hw_init().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 11 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 ++--
drivers/gpu/drm
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock rate rather than
rounding all the intermediate val
Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
full-featured catalog data.
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 73 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 +-
drivers/
In preparation to refactoring the dpu_core_perf debugfs interface,
extract the bandwidth aggregation function from
_dpu_core_perf_crtc_update_bus().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 39 +++
1 file changed, 22 insertions(+), 17 de
The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf management.
Note: min_bus_vote was not used at all, so it is just silently dropped.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm
Drop the leftover of bus-client -> interconnect conversion, the enum
dpu_core_perf_data_bus_id.
Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus
scaling")
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp
Apply several cleanups to the DPU's core_perf module.
Changes since v3:
- Dropped avg_bw type change (Abhinav)
- Removed core_perf from the commit cubject (Abhinav)
Changes since v2:
- Dropped perf tuning patches for now (Abhinav)
- Restored kms variable assignment in dpu_core_perf_crtc_release_b
On 13/07/2023 01:02, Abhinav Kumar wrote:
On 7/12/2023 5:11 AM, Dmitry Baryshkov wrote:
The SM8550 platform employs newer UBWC decoder, which requires slightly
different programming.
Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
Reviewed-by:
On 7/12/2023 5:11 AM, Dmitry Baryshkov wrote:
The SM8550 platform employs newer UBWC decoder, which requires slightly
different programming.
Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Do we also need another fi
On 7/12/23 20:52, Tim Harvey wrote:
Greetings,
Tim,
I've noticed a regression in 6.5-rc1 that I'm having trouble bisecting
between 6.4 with regards to imx8mm MIPI DSI.
I'm testing on an imx8mm-venice-gw72xx-0x with the following display:
- Powertip PH800480T013-IDF02 compatible panel
- T
On 6/27/2023 1:14 PM, Marijn Suijten wrote:
The regulator setup was likely copied from other SoCs by mistake. Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.
Fixes: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290
On Wed, Jul 12, 2023 at 12:24 PM Jagan Teki wrote:
>
> On Thu, Jul 13, 2023 at 12:22 AM Tim Harvey wrote:
> >
> > Greetings,
> >
> > I've noticed a regression in 6.5-rc1 that I'm having trouble bisecting
> > between 6.4 with regards to imx8mm MIPI DSI.
> >
> > I'm testing on an imx8mm-venice-gw72
On Fri, 26 May 2023 at 19:11, Karol Herbst wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this part.
On Thu, 13 Jul 2023 at 05:31, Dave Airlie wrote:
>
> On Tue, 23 May 2023 at 19:37, Karol Herbst wrote:
> >
> > On Mon, May 22, 2023 at 10:18 PM Karol Herbst wrote:
> > >
> > > This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary
> > > firmware files couldn't be loaded.
> >
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dp
On 7/10/2023 7:34 PM, Dmitry Baryshkov wrote:
On 11/07/2023 05:31, Abhinav Kumar wrote:
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf
On Tue, 23 May 2023 at 19:37, Karol Herbst wrote:
>
> On Mon, May 22, 2023 at 10:18 PM Karol Herbst wrote:
> >
> > This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary
> > firmware files couldn't be loaded.
> >
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/
On 12/07/2023 14:11, Dmitry Baryshkov wrote:
> From: Konrad Dybcio
>
> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are
> other connection paths:
> - a path that connects rotator block to the DDR.
> - a path that needs to be handled to ensure MDSS register access
> function
On Thu, Jul 13, 2023 at 12:22 AM Tim Harvey wrote:
>
> Greetings,
>
> I've noticed a regression in 6.5-rc1 that I'm having trouble bisecting
> between 6.4 with regards to imx8mm MIPI DSI.
>
> I'm testing on an imx8mm-venice-gw72xx-0x with the following display:
> - Powertip PH800480T013-IDF02 com
On Wed, Jul 12, 2023 at 11:46:14AM +0200, Uwe Kleine-König wrote:
> Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
> is the better name as "dev" is usually a struct device pointer.
>
> No semantic changes.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Russell King (
Greetings,
I've noticed a regression in 6.5-rc1 that I'm having trouble bisecting
between 6.4 with regards to imx8mm MIPI DSI.
I'm testing on an imx8mm-venice-gw72xx-0x with the following display:
- Powertip PH800480T013-IDF02 compatible panel
- Toshiba TC358762 compatible DSI to DBI bridge
-
Hi Dave, Daniel,
Fixes for 6.5.
The following changes since commit 6725f33228077902ddac2a05e0ab361dee36e4ba:
Merge tag 'drm-misc-next-fixes-2023-07-06' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-07-07 11:05:16
+1000)
are available in the Git repository at:
https://
On 7/12/2023 12:32 PM, Simon Ser wrote:
Since commit 6b85aa68d9d5 ("drm: Enable PRIME import/export for all
drivers"), import/export is always supported. Document this so that
user-space knows what to expect.
Signed-off-by: Simon Ser
Cc: Thomas Zimmermann
Cc: Alex Deucher
Cc: Jeffrey Hugo
Cc
Since commit 6b85aa68d9d5 ("drm: Enable PRIME import/export for all
drivers"), import/export is always supported. Document this so that
user-space knows what to expect.
Signed-off-by: Simon Ser
Cc: Thomas Zimmermann
Cc: Alex Deucher
Cc: Jeffrey Hugo
Cc: Daniel Vetter
---
include/uapi/drm/drm
On Wed, 2023-07-12 at 10:19 +0100, Tvrtko Ursulin wrote:
> On 11/07/2023 23:02, Alan Previn wrote:
> > On MTL, if the GSC Proxy init flows haven't completed, submissions to the
> > GSC engine will fail. Those init flows are dependent on the mei's
> > gsc_proxy component that is loaded in parallel w
On 7/9/23 03:03, Abhinav Kumar wrote:
On 7/7/2023 1:47 AM, Neil Armstrong wrote:
On 07/07/2023 09:18, Neil Armstrong wrote:
Hi,
On 06/07/2023 11:20, Amit Pundir wrote:
On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:
[Adding freedreno@ to cc list]
On Wed, 5 Jul 2023 at 08:31, Jagan
On 11/07/2023 17:04, Christian König wrote:
> Use managed memory allocation for this. That allows us to not keep
> track of all the files any more.
>
> Signed-off-by: Christian König
> ---
> drivers/accel/drm_accel.c | 2 -
> drivers/gpu/drm/drm_debugfs.c | 75 +--
On 11/07/2023 17:04, Christian König wrote:
> Instead of the per minor directories only create a single debugfs
> directory for the whole device directly when the device is initialized.
>
> For DRM devices each minor gets a symlink to the per device directory
> for now until we can be sure that thi
On 7/12/23 17:10, Paulo Pavacic wrote:
Hi,
[...]
Or whether it makes sense to outright have a separate driver. The later
would introduce duplication, but maybe that much duplication is OK.
I would like to create new driver because panel-st7701 seems to be
outdated and is using non-standard m
On 7/12/2023 3:03 AM, Andrzej Hajda wrote:
On 11.07.2023 22:31, Daniele Ceraolo Spurio wrote:
Due to a change in the auth flow on MTL, GuC 70.7.0 and newer will only
be able to authenticate HuC 8.5.1 and newer. The plan is to update the 2
binaries sinchronously in linux-firmware so that the f
On 07/12, Aurabindo Pillai wrote:
>
>
> On 7/12/2023 12:24 PM, Melissa Wen wrote:
> > On 07/12, Pillai, Aurabindo wrote:
> > > [Public]
> > >
> > > Hi Guilherme,
> > >
> > > Sorry there was one more patch which I missed to attach. Please add this
> > > 3rd patch and retry.
> > >
> > > Reverti
On 7/12/2023 12:24 PM, Melissa Wen wrote:
On 07/12, Pillai, Aurabindo wrote:
[Public]
Hi Guilherme,
Sorry there was one more patch which I missed to attach. Please add this 3rd
patch and retry.
Reverting that patch would cause high power consumption on Navi2x GPU also
cause hangs on cert
Hi Sebastian,
+ Thomas
s...@kernel.org wrote on Sat, 22 Apr 2023 22:49:59 +0200:
> Hi,
>
> This adds panel support for Inanbo T28CP45TN89, which I found inside of a
> handheld thermal camera. The panel is based on the st7789v controller. All
> information is based on reverse engineering.
I hav
Don't populate the read-only array on the stack, instead make it static
const.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/therm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/therm.c
b/drivers/
Allocations in the heap and stack tend to be small, with several
allocations sharing the same page. Sharing the same page for different
allocations with different access patterns leads to thrashing when we
migrate data back and forth on GPU and CPU access. To avoid this we
disable HMM migration
On 07/12, Pillai, Aurabindo wrote:
> [Public]
>
> Hi Guilherme,
>
> Sorry there was one more patch which I missed to attach. Please add this 3rd
> patch and retry.
>
> Reverting that patch would cause high power consumption on Navi2x GPU also
> cause hangs on certain multi monitor configuratio
Hi,
Thanks for you patch, I'm here join to the discussion.
I will express my opinion, educate me if I'm wrong.
My understanding is that drm_device is not really a device like
pci_device and platform_device.
the name 'dev' is generally refer to 'struct device *'.
So I think, the name 'drm
Don't populate the const read-only arrays on the stack but instead
make them static const. Use smaller types to use less storage for
the arrays. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King
---
V2: Use smaller int types, kudos to Helge Deller for suggesting this
-
Hello,
miquel.ray...@bootlin.com wrote on Thu, 22 Jun 2023 23:32:12 +0200:
> My previous attempt to slightly clean the OF core wrt device structures
> was rather unsuccessful as the idea behind the discussed cleanup was
> more impacting than what I thought, leading to most of the previous
> serie
Hello,
s...@ravnborg.org wrote on Sat, 10 Jun 2023 22:05:15 +0200:
> On Fri, Jun 09, 2023 at 04:48:43PM +0200, Miquel Raynal wrote:
> > On the SoC host controller, the pixel clock can be:
> > * standard: data is launched on the rising edge
> > * inverted: data is launched on the falling edge
> >
On 7/12/2023 11:50 AM, Guilherme G. Piccoli wrote:
On 12/07/2023 11:47, Pillai, Aurabindo wrote:
Hi Guilherme,
Sorry there was one more patch which I missed to attach. Please add this
3^rd patch and retry.
Reverting that patch would cause high power consumption on Navi2x GPU
also cause han
On 12/07/2023 11:47, Pillai, Aurabindo wrote:
> Hi Guilherme,
>
> Sorry there was one more patch which I missed to attach. Please add this
> 3^rd patch and retry.
>
> Reverting that patch would cause high power consumption on Navi2x GPU
> also cause hangs on certain multi monitor configurations.
On 7/12/23 16:57, Colin Ian King wrote:
Don't populate the const read-only arrays on the stack but instead
make them static const. Also makes the object code a little smaller.
Looks good, but you can optimze even further...
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/kyro/STG4000
On 12/07/2023 13:47, Christian König wrote:
> Just a straightforward conversion without any optimization.
>
> Only compile tested for now.
>
> Signed-off-by: Christian König
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> ---
> drivers/gpu/drm/panfrost/Kcon
On 12/07/2023 17:05, Sui Jingfeng wrote:
Hi,
I'm here join to the discussion. Because I know a little about aspeed BMC.
On 2023/7/10 16:07, Jocelyn Falempe wrote:
On 07/07/2023 09:30, Thomas Zimmermann wrote:
Hi
Am 06.07.23 um 18:37 schrieb Jocelyn Falempe:
[...]
You could out-comment th
Most aspeed devices have a BMC, which allows to remotely see the screen.
Also in the common use case, those servers don't have a display connected.
So add a Virtual connector, to reflect that even if no display is
connected, the framebuffer can still be seen remotely.
This prepares the work to impl
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> >
> > Really?
>
> FWIW, I agree with Christian here.
>
> > Each fil
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 479c4f66afa7..19ce68a7e1a8 100644
--- a
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
fs/proc/task_mmu.c | 24
fs/proc/task_nommu.c | 15 +--
2 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index cfab855fe7e9..05e9893552ce
Hi Uwe,
On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
Well personally I usu
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
security/selinux/hooks.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4e46cf3d67b6..289ef2d6a427 100644
--- a/security/selinux/hooks.c
+++ b/se
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device po
On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > > Background is that this makes merge conflicts easier to handle and
> >
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when thes
Introduce the two helpers for general use.
Signed-off-by: Kefeng Wang
---
include/linux/mm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1462cf15badf..0bbeb31ac750 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -926
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
Background is that this makes merge conflicts easier to handle and detect.
Really?
FWIW, I agree with
Use the helpers to simplify code, also kill unneeded goto cpy_name.
Signed-off-by: Kefeng Wang
---
kernel/events/core.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 78ae7b6f90fd..cb271f449b81 100644
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that nam
On 12.07.2023 13:07, Julia Lawall wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about s
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit
Hello Thomas,
On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > beca
1 - 100 of 262 matches
Mail list logo
