ping for a review of the nouveau patch
Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/arb.c
Hello,
On Mon, Dec 07, 2020 at 10:40:22PM -0600, Bjorn Andersson wrote:
> The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> with the primary purpose of controlling the backlight of the attached
> panel. Add an implementation that exposes this using the standard PWM
> framework
在 2020/12/7 17:22, Thomas Zimmermann 写道:
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committ
patch #1 is used drmm_mode_config_init() to do code refactoring.
patch #2 is deleted unused variable ‘priv’ to avoid warning.
Changes since v1:
patch #1 is removed the unused structure member
variable mode_config_initialized.
Tian Tao (2):
drm/hisilicon: Use managed mode-config init
drm/hisil
Hi,
Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI
controller.
Let me know what you think,
Maxime
Changes from v4:
- Added the tags from Thomas
- Fixed an issue with the clock doubling
- Changed a comment to match the code being introduced
Changes from v3:
- Don't
Reorder it alphabetically and remove one double entry.
Signed-off-by: Oleksij Rempel
---
.../bindings/display/panel/panel-simple.yaml | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Docu
That would work, but that's kind of an annoying requirement. I would prefer
the header to be self-sufficient.
Thanks,
James
On Mon, Dec 7, 2020 at 2:47 AM Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen <
> ppaala...@gmail.com> wrote:
>
> > But then, the code in the
On Thu, Dec 03, 2020 at 03:19:15PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Thu, 3 Dec 2020 at 13:25, Maxime Ripard wrote:
> >
> > Hi,
> >
> > Here's a series adding support for the DSI0 controller in the BCM2835 and
> > the
> > DSI1 controller found in the BCM2711.
> >
> > Let me know wh
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../bindings/display/sprd/sprd,sharkl3-dpu.yaml
On Sat, Dec 05, 2020 at 08:32:29PM +0100, Sam Ravnborg wrote:
> Hi Oleksij
> Thanks for fixing this, but something is not correct.
> I think you switched around the order of comment and compatible.
Ack, i confused my self with comments like:
> > - - edt,etm0700g0dh6
> > -# Emerging D
Some EDT compatibles are already supported by the driver but will fail
on checkpatch script. Fix it by syncing dt-bindings documentation with the
driver.
Signed-off-by: Oleksij Rempel
---
.../devicetree/bindings/display/panel/panel-simple.yaml| 3 +++
1 file changed, 3 insertions(+)
dif
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
v1:
- Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
Cc: Orson Zhai
I'm not completely sure what you're saying, but doesn't drm_base_types.h
(now drm_basic_types.h) make things robust to header order? The patch is in
another email. You can also see it here:
https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18
Thanks,
James
On Mon, Dec
Le vendredi 13 novembre 2020 à 21:39 +0100, Daniel Vetter a écrit :
> On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote:
> > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote:
> > > > On Tue, 10 Nov 2020 at 09:19, John
On 12/3/20 3:40 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration functions which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for comin
Add Plymovent Group BV BAS iMX6dl based board
Signed-off-by: Oleksij Rempel
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.ya
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/h
I'd noticed the #if could be combined, but they weren't in drm,h when they
could have been, so I didn't want to depart from the existing pattern.
I think "One of the BSDs" is more informative than "Not Linux" if that
statement is still true. Given the aversion to making drm.h robust to
Windows, I
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not needed to be called.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/tidss/tidss_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/ti
Not to make too big a deal of it, but the idea was that if you went out of
your way to define DRM_FOURCC_STANDALONE in your code base, that you would
also go through the pain of removing drm.h includes elsewhere. It's too
annoying of an implication to document/communicate, so I'm happier with the
o
So far, this panel seems to be compatible with "lg,lb070wv8", on other
hand it is better to set this compatible in the devicetree. So, let's
add it for now only to the dt-binding documentation to fix the
checkpatch warnings.
Signed-off-by: Oleksij Rempel
---
.../devicetree/bindings/display/panel
07.12.2020 04:32, Chanwoo Choi пишет:
> On 12/4/20 4:24 AM, Dmitry Osipenko wrote:
>> This patch moves ACTMON driver away from generating OPP table by itself,
>> transitioning it to use the table which comes from device-tree. This
>> change breaks compatibility with older device-trees and brings su
The original code blocks in drm.h look identical to me. I see:
#include
#include
typedef unsigned int drm_handle_t;
Good point about drm_basic_types.h. I'll change it to say "Not Linux" after
waiting a bit for more feedback.
Thanks,
James
On Mon, Dec 7, 2020 at 1:59 AM Simon Ser wrote:
> On
On Wed, Dec 02, 2020 at 05:06:40PM +0100, Paul Kocialkowski wrote:
> > > +static void logicvc_crtc_atomic_begin(struct drm_crtc *drm_crtc,
> > > + struct drm_atomic_state *state)
> > > +{
> > > + struct logicvc_crtc *crtc = logicvc_crtc(drm_crtc);
> > > + struct drm_cr
On Sat, Dec 05, 2020 at 08:35:38PM +0100, Sam Ravnborg wrote:
> Hi Oleksij,
>
> On Wed, Dec 02, 2020 at 09:18:20AM +0100, Oleksij Rempel wrote:
> > Some EDT compatibles are already supported by the driver but will fail
> > on checkpatch script. Fix it by syncing dt-bindings documentation with the
Add Plymovent Group BV M2M iMX6dl based board
Signed-off-by: Oleksij Rempel
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.ya
On 12/3/20 4:09 PM, Daniel Lezcano wrote:
On 03/12/2020 16:38, Lukasz Luba wrote:
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which mi
On Sat, Dec 05, 2020 at 08:36:39PM +0100, Sam Ravnborg wrote:
> On Wed, Dec 02, 2020 at 09:18:21AM +0100, Oleksij Rempel wrote:
> > So far, this panel seems to be compatible with "lg,lb070wv8", on other
> > hand it is better to set this compatible in the devicetree. So, let's
> > add it for now onl
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
patch #1 is used drmm_mode_config_init() to do code refactoring.
patch #2 is deleted unused variable ‘priv’ to avoid warning.
Changes since v1:
Remove the unused structure member variable mode_config_initialized.
Tian Tao (2):
drm/hisilicon: Use managed mode-config init
drm/hisilicon: Delete
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reu
Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/
Signed-off-by: Oleksij Rempel
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Docum
Plymovent M2M is a control interface produced for the Plymovent filter
systems.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plym2m.dts | 446
2 fil
Oh, I thought you meant:
#include "drm_basic_types.h"
#include "drm_fourcc.h"
Yours should work too. I don't have a preference vs. what I already have,
so if no one says anything, I can switch over to yours.
Thanks,
James
On Mon, Dec 7, 2020 at 2:53 AM Simon Ser wrote:
> On Monday, December 7
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
v2:
Remove the unused structure member variable mode_config_initialized.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/d
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by:
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files change
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files change
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Unisoc's display pipeline have several components as below
description, multi display controllers and corresponding physical inte
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
means of generating a PWM signal for backlight control of the attached
panel. The provided PWM chip is typically controlled by the
pwm-backlight driver, which if tied to the panel will provide DPMS.
But with the current implement
Create drm_basic_types.h to define types previously defined by drm.h.
Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
---
include/uapi/drm/drm.h | 12 ++---
include/uapi/drm/drm
changes v7:
- panel-simple.yaml: fix comments and part order
- panel-simple.yaml: invent a product description for the Kyocera tcg070wvlq
panel
changes v6:
- do more panel-simple.yaml related cleanups
changes v5:
- rebase against latest shawngup/for-next
- add patch to fix checkpatch warning on
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sprd/Kconfig| 1 +
drivers/gpu/drm/sprd/Makefile | 6
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file change
Hi Thomas,
On Mon, Dec 07, 2020 at 03:14:49PM +0100, Thomas Zimmermann wrote:
> Am 07.12.20 um 14:39 schrieb Maxime Ripard:
> > The pixel rate is for now quite simple to compute, but with more features
> > (30 and 36 bits output, YUV output, etc.) will depend on a bunch of
> > connectors propertie
Hi,
Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI
controller.
Let me know what you think,
Maxime
Changes from v3:
- Don't dereference the connector->state pointer if kzalloc failed
Changes from v2:
- Rebased on current drm-misc-next
- Fixed a bug that was dropping
On Mon, 2020-12-07 at 15:09 +, Colin King wrote:
> From: Colin Ian King
>
> Currently there is a null pointer check for hdmi_phy that implies it
> may be null, however a dev_err messages dereferences this potential null
> pointer. Avoid a null pointer dereference by only emitting the dev_err
Plymovent BAS is a base system controller produced for the Plymovent filter
systems.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plybas.dts | 394
On Mon, Dec 07, 2020 at 03:16:40PM +0100, Thomas Zimmermann wrote:
>
>
> Am 07.12.20 um 14:39 schrieb Maxime Ripard:
> > We'll need to access the connector state in our encoder setup, so let's
> > just pass the whole DRM state to our private encoder hooks.
> >
> > Signed-off-by: Maxime Ripard
>
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reu
ChangeList:
RFC v1:
1. only upstream modeset and atomic at first commit.
2. remove some unused code;
3. use alpha and blend_mode properties;
3. add yaml support;
4. remove auto-adaptive panel driver;
5. bugfix
RFC v2:
1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder
2.
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdm
Create drm_basic_types.h to define types previously defined by drm.h.
Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
James Park (1):
drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
include/u
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by:
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
On Fri, Dec 04, 2020 at 03:36:11PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Thu, 3 Dec 2020 at 07:46, Maxime Ripard wrote:
> >
> > The infoframes are sent at a regular interval as a data island packet,
> > so we don't need to wait for them to be sent when we're setting them up.
> >
> > How
On Mon, 2020-12-07 at 15:19 -0600, Rob Herring wrote:
> On Wed, Nov 18, 2020 at 04:21:22PM +0800, Chunfeng Yun wrote:
> > Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3: new patch
> > ---
> > .../display
I updated the patch earlier today incorporating the suggestions. I also had
to bring back "#include " to drm.h because there's some
sanity check that fails, as if it doesn't scan past the first level of
#includes..
- James
On Mon, Dec 7, 2020 at 3:14 AM Pekka Paalanen wrote:
> On Mon, 07 Dec 20
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fal
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/h
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file change
Reported-by: Thomas Zimmermann
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
i
On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> Just as a side note. I was looking at tpm_tis_probe_irq_single() and
> that function is leaking the interrupt request if any of the checks
> afterwards fails, except for the final interrupt probe check which does
> a cleanup. That m
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we
On 12/7/20 12:16 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 06.12.20 um 20:37 schrieb Randy Dunlap:
>> On 12/6/20 11:02 AM, Sam Ravnborg wrote:
>>> Fix kernel-doc warnings reported when using W=1
>>>
>>> v2:
>>> - Improve subject (Lee)
>>>
>>> v3:
>>> - Add RETURNS documentation (Thomas)
>>
>>
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS te
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 +
1 file changed, 107 insertions(+)
create mode 100644
Documentatio
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdm
On Mon, 2020-12-07 at 10:56 -0600, Rob Herring wrote:
> On Mon, 07 Dec 2020 11:20:55 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
> >
> > Signed-off-by: Liu Ying
> > ---
> > Note that this depends on the 'two cell binding' clock patch set which has
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Special thanks to Doug
05.12.2020 17:09, Krzysztof Kozlowski пишет:
> On Thu, 3 Dec 2020 22:24:29 +0300, Dmitry Osipenko wrote:
>> This series brings initial support for memory interconnect to Tegra20,
>> Tegra30 and Tegra124 SoCs.
>>
>> For the starter only display controllers and devfreq devices are getting
>> intercon
Hi Liu,
On Fri, Dec 04, 2020 at 03:33:40PM +0800, Liu Ying wrote:
> Hi,
>
> This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the
> Freescale i.MX8qxp SoC.
This looks good to me from the NWL and actual phy driver part. I'll
comment in the individual patches but leave comments o
Hi,
On Fri, Dec 04, 2020 at 03:33:41PM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_enable() to
Hi Liu,
Since we now gain optional properties validation would become even more
useful. Could you look into converting to YAML before adding more
values?
Cheers,
-- Guido
On Fri, Dec 04, 2020 at 03:33:43PM +0800, Liu Ying wrote:
> Add support for Mixel MIPI DPHY + LVDS PHY combo IP
> as found on
Hi Liu,
some minor comments inline:
On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> by SCU firmware and the driver would call a SCU firmwar
Am 08.12.20 um 09:18 schrieb Martin Peres:
On 04/12/2020 18:51, Arnd Bergmann wrote:
From: Arnd Bergmann
ttm_pool_type_count() is not used when debugfs is disabled:
drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigne
On Sun, Dec 06, 2020 at 10:33:09PM +0100, Thomas Gleixner wrote:
> On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote:
> > On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> >> Now that kstat_irqs is exported, get rid of count_interrupts in
> >> i915_pmu.c
> >
> > May I ask why this has been
Hi,
On Mon, Dec 07, 2020 at 03:32:06PM -0600, Rob Herring wrote:
> On Wed, 18 Nov 2020 09:29:53 +0100, Guido Günther wrote:
> > This panel from Shenzhen Yashi Changhua Intelligent Technology Co
> > uses the same driver IC but a different LCD.
> >
> > Signed-off-by: Guido Günther
> > Reviewed-by:
On Tue, 08 Dec 2020, Ankit Nautiyal wrote:
> This patch series attempts to add support for a DP-HDMI2.1 Protocol
> Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
> E5 to DisplayPort_v2.0:
> https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299
> Th
applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-tidss-Use-the-new-api-devm_drm_irq_install/20201208-155323
b
May I ask what exactly fails when you drop #include
from drm.h?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
For whatever reason this old series was never merged. Please let's get
this done.
For i915 DP this still needs a patch to start using the model size from
DPCD.
BR,
Jani.
Jani Nikula (6):
drm/dsc: use rc_model_size from DSC config for PPS
drm/i915/dsc: configure hardware using specified rc_mo
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote:
>
> On Mon, Dec 7, 2020 at 9:50 PM Christian König
> wrote:
> > Am 07.12.20 um 21:47 schrieb Alex Deucher:
> > > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
> > >> From: Arnd Bergmann
> > >>
> > >> As the DRM_AMD_DC_DCN3_0 code was x8
The PPS is supposed to reflect the DSC config instead of hard coding the
rc_model_size. Make it so.
Currently all users of drm_dsc_pps_payload_pack() hard code the size to
8192 also in the DSC config, so this change should have no impact, other
than allowing the drivers to use other sizes as neede
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other size
Move the intialization of the rc_model_size from the common code into
encoder code, allowing different encoders to specify the size according
to their needs. Keep using the hard coded value in the encoders for now
to make this a non-functional change.
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signe
Add a helper for calculating the rc buffer size from the DCPD offsets
DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Cc: Vandita Kulkarni
Reviewed-by: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dsc.c | 27 +++
The VBT fields match the DPCD data, so use the same helper.
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
Stop overriding the VBT defined value for rc_model_size.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 676e40
Hi Liu,
Thank you for the patch.
On Fri, Dec 04, 2020 at 03:33:42PM +0800, Liu Ying wrote:
> This patch allows LVDS PHYs to be configured through
> the generic functions and through a custom structure
> added to the generic union.
>
> The parameters added here are based on common LVDS PHY
> impl
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> means of generating a PWM signal for backlight control of the attached
> panel. The provided PWM chip is typically controlled by the
> pwm-backlight driver, whic
On 08-12-20, 09:50, Chunfeng Yun wrote:
> On Mon, 2020-12-07 at 15:09 +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently there is a null pointer check for hdmi_phy that implies it
> > may be null, however a dev_err messages dereferences this potential null
> > pointer. Avoid a n
On 03/12/2020 23:24, Sam Ravnborg wrote:
> Hi Tomi,
> On Thu, Dec 03, 2020 at 01:52:21PM +0200, Tomi Valkeinen wrote:
>> Hi DRM Bridge maintainers,
>>
>> On 30/11/2020 13:29, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> This series adds the DT bindings and a driver for DisplayPort connector.
>>>
>>> Minor
On Tue, Dec 08, 2020 at 12:33:00AM +0800, Christian König wrote:
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->size is the original size of the BO in arbitrary
> units, usually bytes.
>
> bo->mem.num_pages is the size i
Hi Tomi,
Thank you for the patch.
On Tue, Dec 08, 2020 at 02:28:35PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. As the first step,
> change "channel" to "dispc_channel" when dealing with the dispc channel.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by:
Hi Tomi,
Thank you for the patch.
On Tue, Dec 08, 2020 at 02:28:36PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. We have three
> different "channels":
>
> 1) DSI virtual channel ID. This is a number from 0 to 3, included in the
> packet payload.
>
> 2) VC
1 - 100 of 213 matches
Mail list logo
