If there is no GPU present, skip creation of the GPU-related debugfs
files, making the MSM's debugfs more usable.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_debugfs.c | 41 +++
drivers/gpu/drm/msm/msm_rd.c | 3 +++
2 files changed, 28
Readd the header that was erroneously dropped during KMS code
refactoring.
Fixes: 506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310100836.6e6zjece-...@intel.com/
Signed-off-by: Dmitry Baryshkov
---
On 2023/10/10 12:25, Huang Rui wrote:
These definitions are used fro qemu, and qemu imports this marco in the
headers to enable gfxstream or venus for virtio gpu. So it should add it
even kernel doesn't use this.
Signed-off-by: Huang Rui
---
Changes V1 -> V2:
- Add all capsets including
These definitions are used fro qemu, and qemu imports this marco in the
headers to enable gfxstream or venus for virtio gpu. So it should add it
even kernel doesn't use this.
Signed-off-by: Huang Rui
---
Changes V1 -> V2:
- Add all capsets including gfxstream and venus in kernel header (Dmitry
Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
Please add above information into your patch commit message.
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Kunwu.Chan
Sent: Tuesday, October 10, 2023 10:19 AM
To: evan.q...@amd.com; Deucher, Alexander ;
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the drm-msm tree got conflicts in:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
Signed-off-by: Ma Ke
---
drivers/gpu/drm/i2c/ch7006_drv.c | 7 +--
1 file changed, 5
The Snapdragon 670 uses similar clocks (with one frequency added) to the
Snapdragon 845 but reports DPU revision 4.1. Add support for this DPU
with configuration from the Pixel 3a downstream kernel.
Since revision 4.0 is SDM845, reuse some configuration from its catalog
entry.
Link:
The Snapdragon 670 has a display subsystem for controlling and
outputting to the display. Add support for it in the device tree.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Richard Acayan
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 292 +++
1 file changed, 292
Add support for the MDSS block on the SDM670 platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Richard Acayan
---
drivers/gpu/drm/msm/msm_mdss.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
Add documentation for the SDM670 display subsystem, adapted from the
SDM845 and SM6125 documentation.
Signed-off-by: Richard Acayan
---
.../display/msm/qcom,sdm670-mdss.yaml | 292 ++
1 file changed, 292 insertions(+)
create mode 100644
The SDM670 has DSI ports. Add the compatible for the controller.
Acked-by: Rob Herring
Signed-off-by: Richard Acayan
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
The SDM670 display controller has the same requirements as the SDM845
display controller, despite having distinct properties as described in
the catalog. Add the compatible for SDM670 to the SDM845 controller.
Acked-by: Rob Herring
Signed-off-by: Richard Acayan
---
Changes since v2 (20231003012119.857198-9-mailingrad...@gmail.com):
- rebase on series and reference generic sblk definitions (5/6)
- add interconnects properties in example (3/6)
- remove phy-names properties from dtsi (6/6)
- accumulate review tags (4/6, 6/6)
Changes since v1
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a
submission limit that corresponds to the number of jobs which can be
sent to the hardware.
This implies that for each job, drivers need to account for the
Reviewed-by: Lyude Paul
On Fri, 2023-10-06 at 17:55 -0700, Randy Dunlap wrote:
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> Fixes: d59e75eef52d ("drm/nouveau: exec: report max pushs through
On Sat, 2023-10-07 at 11:17 +0800, Ma Ke wrote:
> In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate()
> is assigned to mode, which will lead to a NULL pointer dereference
> on failure of drm_mode_duplicate(). Add a check to avoid npd.
>
> Signed-off-by: Ma Ke
> ---
>
Reviewed-by: Lyude Paul
On Sun, 2023-10-08 at 07:02 -0700, Randy Dunlap wrote:
> kernel-doc emits a warning:
>
> include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
> @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
> on line 49 - I thought it was a doc line
>
> We don't have a way to document a
From: Arnd Bergmann
After the vga console no longer relies on global screen_info, there are
only two remaining use cases:
- on the x86 architecture, it is used for multiple boot methods
(bzImage, EFI, Xen, kexec) to commucate the initial VGA or framebuffer
settings to a number of device
From: Arnd Bergmann
The two hyperv framebuffer drivers (hyperv_fb or hyperv_drm_drv) access the
global screen_info in order to take over from the sysfb framebuffer, which
in turn could be handled by simplefb, simpledrm or efifb. Similarly, the
vmbus_drv code marks the original EFI framebuffer as
From: Arnd Bergmann
I noticed that commit 0db5b61e0dc07 ("fbdev/vga16fb: Create
EGA/VGA devices in sysfb code") broke vga16fb on non-x86 platforms,
because the sysfb code never creates a vga-framebuffer device when
screen_info.orig_video_isVGA is set to '1' instead of VIDEO_TYPE_VGAC.
However,
From: Arnd Bergmann
To prepare for completely separating the VGA console screen_info from
the one used in EFI/sysfb, rename the vgacon instances and make them
local as much as possible.
ia64 and arm both have confurations with vgacon and efi, but the contents
never overlaps because ia64 has no
From: Arnd Bergmann
The vga console driver is fairly self-contained, and only used by
architectures that explicitly initialize the screen_info settings.
Chance every instance that picks the vga console by setting conswitchp
to call a function instead, and pass a reference to the screen_info
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 order to build the VGA console
driver in an allmodconfig build. The mips definition is
From: Arnd Bergmann
The dummycon default console size used to be determined by architecture,
but now this is a Kconfig setting on everything except ARM. Tracing this
back in the historic git trees, this was used to match the size of VGA
console or VGA framebuffer on early machines, but nowadays
From: Arnd Bergmann
On non-x86 architectures, the screen_info variable is generally only
used for the VGA console where supported, and in some cases the EFI
framebuffer or vga16fb.
Now that we have a definite list of which architectures actually use it
for what, use consistent #ifdef checks so
From: Arnd Bergmann
The list of dependencies here is phrased as an opt-out, but this is missing
a lot of architectures that don't actually support VGA consoles, and some
of the entries are stale:
- powerpc used to support VGA consoles in the old arch/ppc codebase, but
the merged
From: Arnd Bergmann
v3 changelog
No real changes, just rebased for context changes, and picked up the Acks.
This now conflicts with the ia64 removal and introduces one new dependency
on IA64, but that is harmless and trivial to deal with later.
Link:
Hi,
On Mon, Oct 9, 2023 at 2:02 PM Linus Walleij wrote:
>
> On Mon, Oct 9, 2023 at 10:53 PM Doug Anderson wrote:
>
> > Also: just as a heads up, Hsin-Yi measured the impact of removing the
> > "command table" for init and replacing it with a whole pile of direct
> > function calls. She found
On Sun, 01 Oct 2023 01:42:50 +0200, Mark Brown wrote:
> The maple tree register cache is based on a much more modern data structure
> than the rbtree cache and makes optimisation choices which are probably
> more appropriate for modern systems than those made by the rbtree cache.
>
>
Applied,
On Sat, 2 Sep 2023 19:34:31 +0200, Christophe JAILLET wrote:
> cdn_dp_audio_codec_init() can fail. So add some error handling.
>
> If component_add() fails, the previous cdn_dp_audio_codec_init() call
> should be undone, as already done in the remove function.
>
>
Applied, thanks!
[1/1]
On Mon, 9 Oct 2023 12:37:53 +0200, Michael Tretter wrote:
> Checking if a modifier is supported by a plane is normal behavior. It is
> normal that a plane may not support certain modifiers. Failing the check
> doesn't justify an error message in the kernel log and may mislead
> users.
>
> Demote
On Fri, 21 Apr 2023 16:13:03 +0800, Yang Li wrote:
> Convert platform_get_resource(), devm_ioremap_resource() to a single
> call to devm_platform_get_and_ioremap_resource(), as this is exactly
> what this function does.
>
>
Applied, thanks!
[1/1] drm/rockchip: dsi: Use
On Mon, 31 Jul 2023 20:53:04 +0800, Zhu Wang wrote:
> The driver depends on CONFIG_OF, so it is not necessary to use
> of_match_ptr here.
>
> Even for drivers that do not depend on CONFIG_OF, it's almost always
> better to leave out the of_match_ptr(), since the only thing it can
> possibly do is
On 10/10/2023 00:04, Abhinav Kumar wrote:
On 10/9/2023 1:53 PM, Dmitry Baryshkov wrote:
On 09/10/2023 22:21, Dmitry Baryshkov wrote:
On 09/10/2023 22:19, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
On 10/9/2023 1:53 PM, Dmitry Baryshkov wrote:
On 09/10/2023 22:21, Dmitry Baryshkov wrote:
On 09/10/2023 22:19, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't
On Mon, Oct 9, 2023 at 10:53 PM Doug Anderson wrote:
> Also: just as a heads up, Hsin-Yi measured the impact of removing the
> "command table" for init and replacing it with a whole pile of direct
> function calls. She found that it added over 100K to the driver (!!!).
> I believe it went from a
There is no need anymore to stop the drm_encoder instance in struct
msm_dsi. Remove corresponding field.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 4 +---
drivers/gpu/drm/msm/dsi/dsi.h | 6 ++
drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 +++-
3
Since the commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order") the
DSI hosts are not bound through the component framework if the DSI
driver wasn't attached to the DSI device connected to this host.
Afterwards, if there is no bridge (including the panel bridge) created
for the DSI device then
The MSM DSI driver has dropped support for calling
mdp_kms_funcs::set_split_display() callback. Drop corresponding callback
from the mdp5 driver together with the rest of the infrastructure.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 42
Since the commit 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual
DSI mode"), the second DSI host in the bonded pair will not be
associated with the encoder and will not get the bridges, thus making
condition in msm_dsi_manager_set_split_display() always false.
Technically that change broke
Since the driver was switched to devm_drm_bridge_add(), there is no need
anymore to store the created bridge instance in struct msm_dsi. Drop
this field and pass data directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 8 +---
drivers/gpu/drm/msm/dsi/dsi.h
As a followup to [1], as suggested by Abhinav drop unused fields from
struct msm_dsi.
[1] https://patchwork.freedesktop.org/series/120125/
Dmitry Baryshkov (5):
drm/msm/dsi: do not store internal bridge pointer
drm/msm/dsi: drop msm_dsi_device_connected() function
drm/msm/dsi: stop calling
On 10/9/23 16:45, Danilo Krummrich wrote:
On 10/9/23 15:36, Thomas Hellström wrote:
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform
On 09/10/2023 22:21, Dmitry Baryshkov wrote:
On 09/10/2023 22:19, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created
Hi,
On Sun, Oct 8, 2023 at 12:33 PM Linus Walleij wrote:
>
> On Sat, Oct 7, 2023 at 8:06 AM Cong Yang
> wrote:
>
> > Linus series proposed to break out ili9882t as separate driver,
> > but he didn't have time for that extensive rework of the driver.
> > As discussed by Linus and Doug [1], keep
Hi,
On Fri, Oct 6, 2023 at 11:07 PM Cong Yang
wrote:
>
> At present, we have found that there may be a problem of blurred
> screen during fast sleep/resume. The direct cause of the blurred
> screen is that the IC does not receive 0x28/0x10. Because of the
> particularity of the IC, before the
Hi,
On Fri, Oct 6, 2023 at 11:07 PM Cong Yang
wrote:
>
> From: Linus Walleij
>
> The Starry ILI9882t-based panel should never have been part of the boe
> tv101wum driver, it is clearly based on the Ilitek ILI9882t display
> controller and if you look at the custom command sequences for the
>
On 10/9/2023 13:02, Andi Shyti wrote:
Hi John,
...
if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
- drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
range", intf_id);
+ gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
intf_id);
Hi John,
...
> > > if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
> > > - drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
> > > range", intf_id);
> > > + gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
> > > intf_id);
> > > return;
> > >
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
The msm_drv_shutdown only makes sense for the KMS-enabled devices, while
msm_platform_driver is only used in the headless case. Remove the
shutdown callback from the driver structure.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Switch to drmm_mode_config_init() instead of drm_mode_config_init().
Drop drm_mode_config_cleanup() calls.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
1 file changed, 5
On 10/9/2023 12:54, Andi Shyti wrote:
Hi John,
...
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -71,6 +71,7 @@
#include "gem/i915_gem_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_print.h"
#include
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Rename the msm_pm_prepare() and msm_pm_complete() to
msm_kms_pm_prepare() and msm_kms_pm_complete() consequently.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
On 10/9/2023 12:50, Andi Shyti wrote:
Hi John,
...
if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
- drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
range", intf_id);
+ gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
intf_id);
Hi John,
...
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -71,6 +71,7 @@
> #include "gem/i915_gem_pm.h"
> #include "gt/intel_gt.h"
> #include "gt/intel_gt_pm.h"
> +#include "gt/intel_gt_print.h"
> #include "gt/intel_rc6.h"
>
> #include
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
The msm_pm_prepare()/msm_pm_complete() only make sense for the
KMS-enabled devices, they have priv->kms guards inside. Drop global
msm_pm_ops, which were used only by the headless msm device.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry
On 10/9/2023 12:43, Andi Shyti wrote:
Hi John,
From: Nirmoy Das
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Nirmoy Das
On 10/9/2023 12:21 PM, Dmitry Baryshkov wrote:
On 09/10/2023 22:19, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding
Hi John,
...
> if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
> - drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
> range", intf_id);
> + gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
> intf_id);
> return;
> }
>
> if
Hi John,
> > > From: Nirmoy Das
> > >
> > > Add a function for ratelimitted debug print.
> > >
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Reviewed-by: Matthew Auld
> > > Reviewed-by: Andi Shyti
> >
On 09/10/2023 22:19, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry
On 10/9/2023 12:01 PM, Dmitry Baryshkov wrote:
On 09/10/2023 21:51, Abhinav Kumar wrote:
On 10/9/2023 11:46 AM, Dmitry Baryshkov wrote:
On 09/10/2023 21:39, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM DSI driver use devm_drm_bridge_add() instead of
On 09/10/2023 21:51, Abhinav Kumar wrote:
On 10/9/2023 11:46 AM, Dmitry Baryshkov wrote:
On 09/10/2023 21:39, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM DSI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require
On 10/9/2023 09:52, Andi Shyti wrote:
Hi,
From: Nirmoy Das
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Nirmoy Das
On 10/9/2023 11:46 AM, Dmitry Baryshkov wrote:
On 09/10/2023 21:39, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM DSI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder.
Reviewed-by: Neil Armstrong
Signed-off-by: Dmitry Baryshkov
---
Instead of having a single file with all bridge chains, list bridges
under a corresponding per-encoder debugfs directory.
While we are at it, also slightly improve the formatting of the bridge
data: split a single line entry into multiple lines, include the symbol
name of the bridge funcs and add
Now as we have standard per-encoder debugfs directory, move DPU encoder
status file to that directory.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +++--
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder. As a showcase for this dir, migrate `bridge_chains' debugfs
file (which
Applied. Thanks!
On Mon, Oct 9, 2023 at 5:27 AM Sharma, Shashank wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Shashank Sharma
>
> Regards
> Shashank
> -Original Message-
> From: Icenowy Zheng
> Sent: Sunday, October 8, 2023 8:47 AM
> To: Deucher, Alexander ; Koenig,
On 09/10/2023 21:39, Abhinav Kumar wrote:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM DSI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by:
On 10/9/2023 11:10 AM, Dmitry Baryshkov wrote:
Make MSM DSI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
From: John Harrison
Update a bunch of GT related print messages in non-GT files to use the
GT specific helpers.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 8 +++-
drivers/gpu/drm/i915/i915_driver.c| 3 ++-
drivers/gpu/drm/i915/i915_perf.c
From: John Harrison
A bunch of print messages got missed in the update to using sub-system
specific helpers. So update those.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 29 +
drivers/gpu/drm/i915/gt/intel_gsc.c | 11
From: John Harrison
There was an update a while back to use sub-system specific print
helpers that implicitly add sub-system specific information to the
print. It seems a bunch of GT related messages got missed in that
update. So update them now.
Signed-off-by: John Harrison
John Harrison
Don't assume bpp of 1 and instead compute the destination pitch using the
intermediate buffer pixel format info when doing a format conversion.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd13xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
The driver only supports the SSD130x family of Solomon OLED controllers
now, but will be extended to also support the SSD132x (4-bit grayscale)
and SSD133x (16-bit RGB) controller families. Rename driver to ssd13xx.
Signed-off-by: Javier Martinez Canillas
---
MAINTAINERS
The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327)
are used by 16 grayscale dot matrix OLED panels, extend the driver to also
support this chip family.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd13xx-i2c.c | 13 ++
Add a Device Tree binding schema for the OLED panels based on the Solomon
SSD132x family of controllers.
Signed-off-by: Javier Martinez Canillas
---
.../bindings/display/solomon,ssd132x.yaml | 116 ++
1 file changed, 116 insertions(+)
create mode 100644
There are some commands that are shared between the SSD130x and SSD132x
controller families, define these as a common SSD13XX set of commands.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd13xx-spi.c | 4 +--
drivers/gpu/drm/solomon/ssd13xx.c | 45
To allow the driver to decouple the common logic in the function callbacks
from the behaviour that is specific of a given Solomon controller family.
For this, include a chip family to the device info and add fields to the
driver-private device struct, to store the hardware buffer maximum size,
This deemed useful to avoid hardcoding a page height and allow to support
other Solomon controller families, but dividing the screen in pages seems
to be something that is specific to the SSD130x chip family.
For example, SSD132x chip family divides the screen in segments (columns)
and common
Since the driver is now called ssd13xx and will support other Solomon OLED
controller families, rename the structs and functions prefixes as well.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd13xx-i2c.c | 63 +--
drivers/gpu/drm/solomon/ssd13xx-spi.c | 73 +--
Hello,
This patch-set adds support for the family of SSD132x Solomon controllers,
such as the SSD1322, SSD1325 and SSD1327 chips. These are used for 16 Gray
Scale Dot Matrix OLED panels.
The patches were tested on a Waveshare SSD1327 display using glmark2-drm,
fbcon, fbtests and the retroarch
On 06/10/2023 10:51, Tomi Valkeinen wrote:
Hi,
On 06/10/2023 10:35, Neil Armstrong wrote:
Hi,
On 04/09/2023 03:53, Dmitry Baryshkov wrote:
Instead of having a single file with all bridge chains, list bridges
under a corresponding per-encoder debugfs directory.
Example of the listing:
$ cat
The msm_drv.c contains generic code intermixed with KMS handling code.
Move all KMS-related code to a separate msm_kms.c file, cleaning up init
code while doing this move. This also prevents msm driver from registering
modesetting / atomic interfaces in the headless case.
Reviewed-by: Rob Clark
There is little point in having the empty debugfs file which always
returns -ENODEV. Change this file to be created only if KMS is actually
used.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2
The msm_drv_shutdown only makes sense for the KMS-enabled devices, while
msm_platform_driver is only used in the headless case. Remove the
shutdown callback from the driver structure.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 1 -
1 file
Rename the msm_pm_prepare() and msm_pm_complete() to
msm_kms_pm_prepare() and msm_kms_pm_complete() consequently.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 4 ++--
The msm_drv_shutdown function should only be used in the KMS case.
Rename it accordingly.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
Don't register the 'fb' debugfs file, if there is no KMS (and so no
framebuffers).
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_debugfs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
Make MSM DP driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 9
Switch to drmm_mode_config_init() instead of drm_mode_config_init().
Drop drm_mode_config_cleanup() calls.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
The msm_pm_prepare()/msm_pm_complete() only make sense for the
KMS-enabled devices, they have priv->kms guards inside. Drop global
msm_pm_ops, which were used only by the headless msm device.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1
As all output devices have switched to devm_drm_bridge_add(), we can
drop the bridges array from struct msm_drm_private.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4
drivers/gpu/drm/msm/msm_drv.h | 3 ---
2 files changed, 7 deletions(-)
Make MSM HDMI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 22
The dp_drm needs accessing the DP's platform device. Move pdev to the
public structure.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 -
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
2 files changed, 13 insertions(+),
Make MSM DSI driver use devm_drm_bridge_add() instead of plain
drm_bridge_add(). As the driver doesn't require any additional cleanup,
stop adding created bridge to the priv->bridges array.
Reviewed-by: Rob Clark
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 28
1 - 100 of 207 matches
Mail list logo
