Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel
support.
Signed-off-by: Marek Vasut
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff
Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel
compatible string.
Signed-off-by: Marek Vasut
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
.../devicetree/bindings/display/panel/panel-simple.ya
On 16/04/2022 03:09, Doug Anderson wrote:
Hi,
On Fri, Apr 15, 2022 at 3:45 PM Dmitry Baryshkov
wrote:
On Sat, 16 Apr 2022 at 00:13, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:47 PM Dmitry Baryshkov
wrote:
On 09/04/2022 05:36, Douglas Anderson wrote:
As talked about in the kern
On Fri, Apr 15, 2022 at 5:33 PM Chia-I Wu wrote:
>
> simple_ondemand interacts poorly with clamp_to_idle. It only looks at
> the load since the last get_dev_status call, while it should really look
> at the load over polling_ms. When clamp_to_idle true, it almost always
> picks the lowest freque
simple_ondemand interacts poorly with clamp_to_idle. It only looks at
the load since the last get_dev_status call, while it should really look
at the load over polling_ms. When clamp_to_idle true, it almost always
picks the lowest frequency on active because the gpu is idle between
msm_devfreq_id
Move tracking and busy time calculation to msm_devfreq_get_dev_status.
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 19 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +
drivers/gpu/drm/msm/msm_gpu.h | 9 +++-
drivers/g
It is redundant since commit 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS
constraints") because dev_pm_qos_update_request triggers get_dev_status.
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu
On 16/04/2022 03:12, Doug Anderson wrote:
Hi,
On Fri, Apr 15, 2022 at 3:12 PM Dmitry Baryshkov
wrote:
On Sat, 16 Apr 2022 at 00:17, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:51 PM Dmitry Baryshkov
wrote:
On 09/04/2022 05:36, Douglas Anderson wrote:
Let's add support for being
Hi,
On Fri, Apr 15, 2022 at 3:12 PM Dmitry Baryshkov
wrote:
>
> On Sat, 16 Apr 2022 at 00:17, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Apr 14, 2022 at 5:51 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On 09/04/2022 05:36, Douglas Anderson wrote:
> > > > Let's add support for being able to
Hi,
On Fri, Apr 15, 2022 at 3:45 PM Dmitry Baryshkov
wrote:
>
> On Sat, 16 Apr 2022 at 00:13, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Apr 14, 2022 at 5:47 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On 09/04/2022 05:36, Douglas Anderson wrote:
> > > > As talked about in the kerneldoc fo
On 4/14/2022 4:34 PM, Dmitry Baryshkov wrote:
On 15/04/2022 01:06, Kuogee Hsieh wrote:
On 4/8/2022 4:59 PM, Dmitry Baryshkov wrote:
On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh
wrote:
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle()
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP i
> From: Jason Gunthorpe
> Sent: Friday, April 15, 2022 8:07 PM
>
> On Fri, Apr 15, 2022 at 02:32:08AM +, Tian, Kevin wrote:
>
> > While it's a welcomed fix is it actually related to this series? The point
> > of this patch is that those functions are called when container_users
> > is non-ze
On Sat, 16 Apr 2022 at 02:36, Kuogee Hsieh wrote:
>
> Current DP driver implementation, event thread is kept running
> after DP display is unbind. This patch fix this problem by disabling
> DP irq and stop event thread to exit gracefully at dp_display_unbind().
>
> Changes in v2:
> -- start event
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP i
On 4/15/2022 4:27 PM, Dmitry Baryshkov wrote:
On Sat, 16 Apr 2022 at 02:10, Kuogee Hsieh wrote:
On 4/15/2022 3:48 PM, Dmitry Baryshkov wrote:
On Sat, 16 Apr 2022 at 01:34, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This p
On Sat, 16 Apr 2022 at 02:10, Kuogee Hsieh wrote:
>
>
> On 4/15/2022 3:48 PM, Dmitry Baryshkov wrote:
> > On Sat, 16 Apr 2022 at 01:34, Kuogee Hsieh wrote:
> >> Current DP driver implementation, event thread is kept running
> >> after DP display is unbind. This patch fix this problem by disabling
Hi Abhinav,
On 2022-04-15 12:25:55, Abhinav Kumar wrote:
> Hi Marijn
>
> Looking at msm-next tip, this code has already been refactored in
>
> https://gitlab.freedesktop.org/drm/msm/-/commit/ef58e0ad34365e2c8274b74e6e745b8c180ff0d3
>
> So, I will just rebase my changes on msm-next tip and it sh
On 4/15/2022 3:48 PM, Dmitry Baryshkov wrote:
On Sat, 16 Apr 2022 at 01:34, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unb
On Sat, 16 Apr 2022 at 01:34, Kuogee Hsieh wrote:
>
> Current DP driver implementation, event thread is kept running
> after DP display is unbind. This patch fix this problem by disabling
> DP irq and stop event thread to exit gracefully at dp_display_unbind().
>
> Changes in v2:
> -- start event
On Sat, 16 Apr 2022 at 00:13, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 14, 2022 at 5:47 PM Dmitry Baryshkov
> wrote:
> >
> > On 09/04/2022 05:36, Douglas Anderson wrote:
> > > As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
> > > patch and also in the past in commit a1e
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP i
On Sat, 16 Apr 2022 at 00:17, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 14, 2022 at 5:51 PM Dmitry Baryshkov
> wrote:
> >
> > On 09/04/2022 05:36, Douglas Anderson wrote:
> > > Let's add support for being able to read the HPD pin even if it's
> > > hooked directly to the controller. This will
Hi,
On Thu, Apr 14, 2022 at 5:51 PM Dmitry Baryshkov
wrote:
>
> On 09/04/2022 05:36, Douglas Anderson wrote:
> > Let's add support for being able to read the HPD pin even if it's
> > hooked directly to the controller. This will allow us to get more
> > accurate delays also lets us take away the w
Hi,
On Thu, Apr 14, 2022 at 5:47 PM Dmitry Baryshkov
wrote:
>
> On 09/04/2022 05:36, Douglas Anderson wrote:
> > As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
> > patch and also in the past in commit a1e3667a9835 ("drm/bridge:
> > ti-sn65dsi86: Promote the AUX channel to
Hi,
On Thu, Apr 14, 2022 at 4:52 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2022-04-08 19:36:23)
> > As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
> > patch and also in the past in commit a1e3667a9835 ("drm/bridge:
> > ti-sn65dsi86: Promote the AUX channel to it
https://bugzilla.kernel.org/show_bug.cgi?id=215842
Bug ID: 215842
Summary: PC freeze sidn kernel 5.17.x
Product: Drivers
Version: 2.5
Kernel Version: 5.17.3
Hardware: Intel
OS: Linux
Tree: Mainline
To make sure maintainers of amdgpu drivers are aware of any changes
in their documentation, add its entry to MAINTAINERS.
Signed-off-by: Tales Lelo da Aparecida
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d54b9f15ffce..b3594b2a09de 100644
Add missing acronyms to the amdgppu glossary.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1939#note_1309737
Signed-off-by: Tales Lelo da Aparecida
---
Documentation/gpu/amdgpu/amdgpu-glossary.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/amd
I was handling the request from [0] and then I noticed that some AMD
developers were missing from get_maintainers output due to the lack of a
reference to their documentation in the MAINTAINERS file.
[0] https://gitlab.freedesktop.org/drm/amd/-/issues/1939#note_1309737
Tales Lelo da Aparecida (2)
Quoting Kuogee Hsieh (2022-04-15 08:41:16)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 01453db..92c9819 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -230,6 +231,14 @@ void dp_display_signa
Quoting Abhinav Kumar (2022-04-15 12:09:42)
> Remove unused MSM_DISPLAY_CAP_HOT_PLUG and MSM_DISPLAY_CAP_EDID
> macros from msm_drv.h.
>
> Even if we need these, there are drm equivalent ones present.
>
> Reported-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
> ---
Reviewed-by: Stephen Boy
Hi Marijn
Looking at msm-next tip, this code has already been refactored in
https://gitlab.freedesktop.org/drm/msm/-/commit/ef58e0ad34365e2c8274b74e6e745b8c180ff0d3
So, I will just rebase my changes on msm-next tip and it should address
below comments as well.
Thanks
Abhinav
On 4/14/2022 3
Remove unused MSM_DISPLAY_CAP_HOT_PLUG and MSM_DISPLAY_CAP_EDID
macros from msm_drv.h.
Even if we need these, there are drm equivalent ones present.
Reported-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_drv.h | 4
1 file changed, 4 deletions(-)
diff --git
It's a local function, let's make it static.
Signed-off-by: Tales Lelo da Aparecida
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn10/
https://bugzilla.kernel.org/show_bug.cgi?id=215839
--- Comment #2 from kolAflash (kolafl...@kolahilft.de) ---
Thanks for your assessment Alex!
Here is the Mesa bug:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/6326
I can only set the status of this kernel.org bug to "resolved". But I guess i
https://bugzilla.kernel.org/show_bug.cgi?id=215839
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
From: Dave Stevenson
If a call to rpi_touchscreen_i2c_write from rpi_touchscreen_probe
fails before mipi_dsi_device_register_full is called, then
in trying to log the error message if uses ts->dsi->dev when
it is still NULL.
Use ts->i2c->dev instead, which is initialised earlier in probe.
Fixes
This small patch series tries to upstream 2 minor issues which has been
fixed in the vendor tree by Dave Stevenson.
Dave Stevenson (2):
drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised
drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare
.../gpu/drm/panel
From: Dave Stevenson
The panel has a prepare call which is before video starts, and an
enable call which is after.
The Toshiba bridge should be configured before video, so move
the relevant power and initialisation calls to prepare.
Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry
https://bugzilla.kernel.org/show_bug.cgi?id=215839
Bug ID: 215839
Summary: distorted video playback with hybrid GPU (DRI_PRIME=1,
Radeon HD 6470M and Intel-GPU)
Product: Drivers
Version: 2.5
Kernel Version: 5.15.28
Hard
The vc4_hdmi_encoder.hdmi_monitor field was used to cache the value
returned by drm_detect_hdmi_monitor() in order to avoid calling it
multiple times.
Now that drm_detect_hdmi_monitor() has been replaced with
drm_display_info.is_hdmi, there is no need to cache it in the driver
encoder struct.
Rem
Once EDID is parsed, the monitor HDMI support information is cached in
drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video().
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value, which is less efficient.
Avoid calling drm_detect_hdmi_monit
Hi everyone,
These patches replace the calls to drm_detect_hdmi_monitor() with the
more efficient drm_display_info.is_hdmi in the VC4 driver.
As I mentioned in v1, vc4_hdmi_encoder.hdmi_monitor (removed by this
series) is used by some code not present in the mainline kernel but
present in the Ras
Hi Biju,
Thank you for the patch.
On Wed, Mar 16, 2022 at 01:10:58PM +, Biju Das wrote:
> RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
> needs a different CRTC implementation. Factorise rcar_du_{atomic_check,
> modeset_init} by adding struct rcar_du_crtc_helper_
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP i
Do not exit quietly from compose_plane. If any plane has an invalid
map, propagate the error value upwards. While here, add log messages
for the invalid index.
Signed-off-by: Tales Lelo da Aparecida
---
drivers/gpu/drm/vkms/vkms_composer.c | 30 ++--
1 file changed, 20 in
Fix a copypasta error. The caller of compose_plane() already checks
primary_composer->map. In contrast, plane_composer->map is never
verified here before handling.
Fixes: 7938f4218168 ("dma-buf-map: Rename to iosys-map")
Reviewed-by: André Almeida
Signed-off-by: Tales Lelo da Aparecida
---
v2: d
Hi, this is a follow-up of my last patch. Thanks for the reviews!
Changes from v1:
Edit the first commit message as suggested by Melissa and add a commit to
enhance the
error handling (André)
Tales Lelo da Aparecida (2):
drm/vkms: check plane_composer->map[0] before using it
drm/vkms: retur
Hi Dave, Daniel,
New features for 5.19. There is a new DP define added in drm_dp_helper.h
to support some new DC code. That file has moved in drm-misc. Just
a heads up there when you merge.
The following changes since commit 15f9cd4334c83716fa32647652a609e3ba6c998d:
drm/amdgpu/gfx10: enable
On Fri, Apr 15, 2022 at 02:32:08AM +, Tian, Kevin wrote:
> While it's a welcomed fix is it actually related to this series? The point
> of this patch is that those functions are called when container_users
> is non-zero. This is true even without this fix given container_users
> is decremented
On Thu, 14 Apr 2022 22:00:09 -0500
Samuel Holland wrote:
> Hi Andreas,
>
> Thanks for the comments.
>
> On 4/14/22 3:15 AM, Andreas Kemnade wrote:
> > Hi Samuel,
> >
> > for comparison, here is my submission for the IMX EPDC bindings:
> >
> > https://lore.kernel.org/linux-devicetree/202202060
Hi Biju,
Thank you for the patch.
On Wed, Mar 16, 2022 at 01:10:57PM +, Biju Das wrote:
> RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
> needs a different CRTC implementation.
>
> Move rcar_du_output_name() to a new common file rcar_du_common.c, So that
> the s
Hi Biju,
Thank you for the patch.
On Wed, Mar 16, 2022 at 01:10:56PM +, Biju Das wrote:
> There are some differences related to max frame size supported by different
> R-Car/RZ-G family of SoC's
>
> Max frame size supported by R-Car Gen1 & R-Car Gen2 is 4095x2047
> Max frame size supported b
Hi Biju,
Thank you for the patch.
On Wed, Mar 16, 2022 at 01:10:55PM +, Biju Das wrote:
> Number of RPF's VSP is different on R-Car and RZ/G2L
> R-Car Gen3 -> 5 RPFs
> R-Car Gen2 -> 4 RPFs
> RZ/G2L -> 2 RPFs
>
> Add num_rpf to struct rcar_du_device_info to support later
> SoC without any
Hi Biju,
Thank you for the patch.
On Wed, Mar 16, 2022 at 01:10:54PM +, Biju Das wrote:
> Extend the Renesas DU display bindings to support the r9a07g044l
> DU module found on RZ/G2L LCDC.
Stupid question, but as this DU and the R-Car DU are completely
different pieces of hardware, wouldn't
> Wiadomość napisana przez Daniel Stone w dniu
> 12.04.2022, o godz. 13:30:
>
>> Testing Sacha patch (see today's email from Sascha) i'm getting
>>
>> Qt: EGL Error : Could not create the egl surface: error = 0x3009
>>
>> i'm reading this as: Qt tries allocate EGL surface and EGL returns er
Hi Biju,
Thank you for the patch.
On Mon, Mar 28, 2022 at 07:51:15AM +0100, Biju Das wrote:
> This driver supports the MIPI DSI encoder found in the RZ/G2L
> SoC. It currently supports DSI mode only.
>
> Signed-off-by: Biju Das
> ---
> v1->v2:
> * Rework based on dt-binding change (DSI + D-PHY
Il 15/04/22 10:39, jason-jh.lin ha scritto:
The mmsys routing table of mt8195 vdosys0 has 2 DITHER components,
so mmsys need to add DDP_COMPONENT_DITHER1 and change all usages of
DITHER enum form DDP_COMPONENT_DITHER to DDP_COMPONENT_DITHER0.
But its header need to keep DDP_COMPONENT_DITHER enum
Il 15/04/22 10:39, jason-jh.lin ha scritto:
Because mt8195 vdosys0 has 2 DITHER components,
so the postfix 0 need to be added to DDP_COMPONENT_DITHER.
Then DITHER enum will become:
DDP_COMPONENT_DITHER0 and DDP_COMPONENT_DITHER1.
Signed-off-by: jason-jh.lin
I think that "postfix" should be "
Il 15/04/22 10:39, jason-jh.lin ha scritto:
After mmsys and drm change DITHER enum to DDP_COMPONENT_DITHER0,
mmsys header can remove the useless DDP_COMPONENT_DITHER enum.
Signed-off-by: jason-jh.lin
Can you please fix the commit title with:
soc: mediatek: remove DDP_DOMPONENT_DITHER from enu
Il 15/04/22 10:39, jason-jh.lin ha scritto:
1. Add driver data of mt8195 vdosys0 to mediatek-drm and the sub driver.
2. Add get driver data function to identify which vdosys by io_start.
Signed-off-by: jason-jh.lin
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +
drivers/gpu/drm/mediate
Il 15/04/22 10:39, jason-jh.lin ha scritto:
1. Add mt8195 mmsys compatible for 2 vdosys.
2. Add io_start into each driver data of mt8195 vdosys.
3. Add get match data function to identify mmsys by io_start.
4. Add mt8195 routing table settings of vdosys0.
Signed-off-by: jason-jh.lin
Unless an
Hi Biju,
Thank you for the patch.
On Mon, Mar 28, 2022 at 07:49:30AM +0100, Biju Das wrote:
> The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
> can operate in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
> ---
> v1->v2:
> * Added full path for dsi
On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
When the open_device() op is called the container_users is incremented and
held incremented until close_device(). Thus, so long as drivers call
functions within their open_device()/close_device() region they do not
need to worry about the container_user
On 15/04/2022 04:42, sandor...@nxp.com wrote:
From: Sandor Yu
HDMI1.4b specification section 6.5.3:
Source shall only send GCPs with non-zero CD to sinks
that indicate support for Deep Color.
DW HDMI GCP default enabled, but only transmit CD
and do not handle AVMUTE, PP norDefault_Phase (yet).
66 matches
Mail list logo
