On 22-10-21, 15:06, Markus Schneider-Pargmann wrote:
> > > + dp_phy->regs = *(struct regmap **)dev->platform_data;
> > > + if (!dp_phy->regs) {
> > > + dev_err(dev, "No data passed, requires struct regmap**\n");
> > > + return -EINVAL;
> > > + }
> >
> > is there a reason to do it
Hi Julian,
Thank you for catching this.
On Mon, 25 Oct 2021 at 05:44, Julian Braha wrote:
>
> When DRM_CHIPONE_ICN6211 is selected, and DRM_KMS_HELPER is not selected,
> Kbuild gives the following warning:
>
> WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE
> Depends on [n]: H
On Fri, Oct 22, 2021 at 6:13 PM Jason-JH Lin wrote:
>
> Hi Angelo,
>
> Thanks for the reviews.
>
>
> On Thu, 2021-10-14 at 16:05 +0200, AngeloGioacchino Del Regno wrote:
> > > Add mt8195 vdosys0 clock driver name and routing table to
> > > the driver data of mtk-mmsys.
> > >
>
> [snip]
>
> > >
> >
"i" can be used uninitialized in one of the error branches. Fix this.
Signed-off-by: Christian König
Reported-by: kernel test robot
---
drivers/dma-buf/st-dma-resv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/st-dma-resv.c b/drivers/dma-buf/st-dma-resv
The logic to remove the conflicting frame buffers for fbdev devices that
use a given memory range is only compiled if CONFIG_FB option is enabled.
But having an ifdefery in drm_aperture_remove_conflicting_framebuffers()
makes the function harder to extend. Move the logic into its own helper.
Sugg
This patch-series add a drm.disable_native_drivers option that can be used
to prevent native DRM drivers to be probed. That way, the simpledrm driver
won't be removed which can be useful to troubleshoot DRM drivers problems.
Patch #1 is just a small preparatory patch that moves the logic to remove
The simpledrm driver allows to use the frame buffer that was set-up by the
firmware. This gives early video output before the platform DRM driver is
probed and takes over.
But it would be useful to have a way to disable this take over by native
DRM drivers. For example, there may be bugs in the DR
On 22/10/2021 13:06, Kai Song wrote:
Fix inconsistent IS_ERR and PTR_ERR in i915_gem_dmabuf.c
Signed-off-by: Kai Song
Pushed to drm-intel-gt-next. Thanks.
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
Hi guys,
just two minor cleanups related to the new DMA-buf iterators. Can I get an rb
or ack-by for that?
Thanks,
Christian.
We certainly hold the reservation lock here, no need for the RCU dance.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etna
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 31 ++-
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 8f1b5
On Sun, 24 Oct 2021, Hans de Goede wrote:
> In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
> for dual-link panels. This fixes the following WARN triggering:
>
> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate
> (expected 235710, found 118056)
>
On Sun, 24 Oct 2021, Hans de Goede wrote:
> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>
> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for a Cherry
> Trail tablet. It deviates from the typical reference design
Hello,
[replaced Andrzej Hajda's email address with his new one]
On Wed, Sep 29, 2021 at 10:05:57PM -0500, 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 implemen
On Wed, Sep 29, 2021 at 10:05:55PM -0500, Bjorn Andersson wrote:
> The existing pxa driver and the upcoming addition of PWM support in the
> TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
> thereby a need for a of_xlate function with the period as its single
> argument.
>
>
Hi,
On 10/25/21 10:25, Jani Nikula wrote:
> On Sun, 24 Oct 2021, Hans de Goede wrote:
>> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
>> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>>
>> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for a Cherry
>> Trail tab
On 22.10.21 11:28, Andrew Cooper wrote:
On 22/10/2021 07:47, Juergen Gross wrote:
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are identi
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. r
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
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 internal
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS te
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
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,s
Adds DPU(Display Processor Unit) support for the Unisoc's display
subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
v2:
- Use drm_xxx to replace all DRM_XXX.
- Use kzalloc to replace devm_kzalloc for sprd_dpu structure init.
v3:
- Remove dpu_layer stuff l
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
v5:
- Remove panel_in port for dsi node.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml | 88 +++
1 fil
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.
v2:
- Use drm
Quoting Matthew Brost (2021-10-22 19:42:19)
> On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > Hi Matt & John,
> >
> > Can you please queue patches with the right Fixes: references to convert
> > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
> > protectio
On Sun, Oct 10, 2021 at 02:46:28PM +0200, Greg Kroah-Hartman wrote:
> In order to better track where in the kernel the dma-buf code is used,
> put the symbols in the namespace DMA_BUF and modify all users of the
> symbols to properly import the namespace to not break the build at the
> same time.
>
On 2021-10-24 22:32, Javier Martinez Canillas wrote:
> Hello Ville,
>
> On 10/22/21 21:12, Ville Syrjälä wrote:
>> On Fri, Oct 22, 2021 at 04:40:40PM +0200, Javier Martinez Canillas wrote:
>>> The simpledrm driver allows to use the frame buffer that was set-up by the
>>> firmware. This gives early
Am 25.10.21 um 12:36 schrieb Greg Kroah-Hartman:
On Sun, Oct 10, 2021 at 02:46:28PM +0200, Greg Kroah-Hartman wrote:
In order to better track where in the kernel the dma-buf code is used,
put the symbols in the namespace DMA_BUF and modify all users of the
symbols to properly import the namespac
Hi All,
On 21.10.2021 22:21, Sam Ravnborg wrote:
Hi Douglas,
On Thu, Oct 21, 2021 at 12:29:01PM -0700, Douglas Anderson wrote:
Right now, the chaining order of
pre_enable/enable/disable/post_disable looks like this:
pre_enable: start from connector and move to encoder
enable: start fr
On 21.10.2021 17.35, Ville Syrjälä wrote:
On Thu, Oct 21, 2021 at 07:56:24PM +0530, Ramalingam C wrote:
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older ge
Hello,
On Mon, Oct 25, 2021 at 01:00:10PM +0200, Andrzej Hajda wrote:
> On 21.10.2021 22:21, Sam Ravnborg wrote:
> > On Thu, Oct 21, 2021 at 12:29:01PM -0700, Douglas Anderson wrote:
> >> Right now, the chaining order of
> >> pre_enable/enable/disable/post_disable looks like this:
> >>
> >> pre_en
Fix following coccicheck warning:
./drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3117:15-22: WARNING:
ERR_CAST can be used with eb->requests[i].
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)")
Cc: sta...@vger.kernel.org # 3.4
Signed-off-by: Johan Hovold
---
drivers/gpu/drm/udl/udl_connector.c | 2 +-
1 file changed, 1
Hi Greg,
On Mon, 25 Oct 2021 at 16:29, Christian König wrote:
>
> Am 25.10.21 um 12:36 schrieb Greg Kroah-Hartman:
> > On Sun, Oct 10, 2021 at 02:46:28PM +0200, Greg Kroah-Hartman wrote:
> >> In order to better track where in the kernel the dma-buf code is used,
> >> put the symbols in the namesp
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next spe
Quoting Thomas Hellström (2021-10-21 08:39:48)
> On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > pinned with GuC submission")
> > Signed-off-by: Matthew Brost
> > Cc: sta...@vger.kernel.org
This Cc: stable an
Hello Michel,
On 10/25/21 12:45, Michel Dänzer wrote:
> On 2021-10-24 22:32, Javier Martinez Canillas wrote:
>> Hello Ville,
>>
>> On 10/22/21 21:12, Ville Syrjälä wrote:
>>> On Fri, Oct 22, 2021 at 04:40:40PM +0200, Javier Martinez Canillas wrote:
The simpledrm driver allows to use the frame
On Mon, Oct 25, 2021 at 8:28 AM Javier Martinez Canillas
wrote:
>
> Hello Michel,
>
> On 10/25/21 12:45, Michel Dänzer wrote:
> > On 2021-10-24 22:32, Javier Martinez Canillas wrote:
> >> Hello Ville,
> >>
> >> On 10/22/21 21:12, Ville Syrjälä wrote:
> >>> On Fri, Oct 22, 2021 at 04:40:40PM +0200,
On Mon, Oct 25, 2021 at 05:43:49PM +0530, Sumit Semwal wrote:
> Hi Greg,
>
> On Mon, 25 Oct 2021 at 16:29, Christian König
> wrote:
> >
> > Am 25.10.21 um 12:36 schrieb Greg Kroah-Hartman:
> > > On Sun, Oct 10, 2021 at 02:46:28PM +0200, Greg Kroah-Hartman wrote:
> > >> In order to better track w
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
range,
add top down allocation support to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 75197ba6e40d..963
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 103
include/drm/drm_buddy.h | 4 ++
2 fil
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.
Move shared vram inline functions and structs
into a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 51
1 file changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git a/drivers/gpu/drm/a
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_m
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 drive
On 2021-10-25 14:28, Javier Martinez Canillas wrote:
> Hello Michel,
>
> On 10/25/21 12:45, Michel Dänzer wrote:
>> On 2021-10-24 22:32, Javier Martinez Canillas wrote:
>>> Hello Ville,
>>>
>>> On 10/22/21 21:12, Ville Syrjälä wrote:
On Fri, Oct 22, 2021 at 04:40:40PM +0200, Javier Martinez C
Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
Tvrtko will bring added bandwidth and focus to the GT/GEM domain
(drm-intel-gt-next).
This will help with the increased driver maintenance efforts, allows
alternating the drm-intel-gt-next pull requests and also should increase
the coverag
On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen
wrote:
>
> Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
> Tvrtko will bring added bandwidth and focus to the GT/GEM domain
> (drm-intel-gt-next).
>
> This will help with the increased driver maintenance efforts, allows
> alternating the
adding a trace,
...
[5.201715] [drm] amdgpu kernel modesetting enabled.
[5.201902] amdgpu: Virtual CRAT table created for CPU
[5.201909] amdgpu: Topology: Add CPU node
[5.201968] checking generic (e100 1d5000) vs hw (c000 1000)
[5.201969] checking generic (e100
On Mon, 25 Oct 2021 at 17:43, Naresh Kamboju wrote:
>
> Regression found on arm gcc-11 built with multi_v5_defconfig
> Following build warnings / errors reported on linux next 20211025.
>
> metadata:
> git_describe: next-20211025
> git_repo: https://gitlab.com/Lin
Hi,
This is a follow-up of the series here:
https://lore.kernel.org/all/20210924135530.1036564-1-max...@cerno.tech/
and the discussion that occured here:
https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/
The original series aimed at getting rid of the encoder->crtc pointer usage i
Accessing the crtc->state pointer from outside the modesetting context
is not allowed. We thus need to copy whatever we need from the KMS state
to our structure in order to access it.
In VC4, a number of users of that pointers have crept in over the years,
the first one being whether or not the do
The vc4 HDMI driver has multiple path shared between the CEC, ALSA and
KMS frameworks, plus two interrupt handlers (CEC and hotplug) that will
read and modify a number of registers.
Even though not bug has been reported so far, it's definitely unsafe, so
let's just add a spinlock to protect the re
The vc4 HDMI controller registers into the KMS, CEC and ALSA
frameworks.
However, no particular care is done to prevent the concurrent execution
of different framework hooks from happening at the same time.
In order to protect against that scenario, let's introduce a mutex that
relevant ALSA and
Even though we already check that the encoder->crtc pointer is there
during in startup(), which is part of the open() path in ASoC, nothing
guarantees that our encoder state won't change between the time when we
open the device and the time we prepare it.
Move the sanity checks we do in startup()
In some situation, we can end up being stuck on a non-blocking that went
through properly.
The situation that seems to trigger it reliably is to first start a
non-blocking commit, and then right after, and before we had any vblank
interrupt), start a blocking commit.
This will lead to the first c
Accessing the crtc->state pointer from outside the modesetting context
is not allowed. We thus need to copy whatever we need from the KMS state
to our structure in order to access it.
In VC4, a number of users of that pointers have crept in over the years,
and the previous commits removed them all
Accessing the crtc->state pointer from outside the modesetting context
is not allowed. We thus need to copy whatever we need from the KMS state
to our structure in order to access it.
However, in the vc4 HDMI driver we do use that pointer in the ALSA code
path, and potentially in the hotplug inter
We currently poke at encoder->crtc in the ALSA code path to determine
whether the HDMI output is enabled or not, and thus whether we should
allow the audio output.
However, that pointer is deprecated and shouldn't really be used by
atomic drivers anymore. Since we have the infrastructure in place
We currently rely on two functions, vc4_hdmi_supports_scrambling() and
vc4_hdmi_mode_needs_scrambling() to determine if we should enable and
disable the scrambler for any given mode.
Since we might need to disable the controller at boot, we also always
run vc4_hdmi_disable_scrambling() and thus ca
Hi,
On Thu, Oct 14, 2021 at 03:15:36PM +0200, Daniel Vetter wrote:
> On Wed, Oct 13, 2021 at 05:01:03PM +0200, Maxime Ripard wrote:
> > On Thu, Sep 30, 2021 at 11:19:59AM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 28, 2021 at 10:34:46AM +0200, Maxime Ripard wrote:
> > > > Hi Daniel,
> > > >
>
On 14/10/2021 17:13, Dmitry Baryshkov wrote:
On 07/10/2021 10:08, Vinod Koul wrote:
For DSC to work we typically need a 2,2,1 configuration. This should
suffice for resolutions upto 4k. For more resolutions like 8k this won't
work.
Also, it is better to use 2 LMs and DSC instances as half width
On 20/10/2021 09:57, Vinod Koul wrote:
On 14-10-21, 16:50, Dmitry Baryshkov wrote:
On 14/10/2021 16:41, Dmitry Baryshkov wrote:
On 07/10/2021 10:08, Vinod Koul wrote:
We cannot enable mode_3d when we are using the DSC. So pass
configuration to detect DSC is enabled and not enable mode_3d
when
On 07/10/2021 10:08, Vinod Koul wrote:
Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.
Signed-off-by: Vinod Koul
---
Changes since
v1:
- Drop unu
On 07/10/2021 10:08, Vinod Koul wrote:
We need to configure the encoder for DSC configuration and calculate DSC
parameters for the given timing so this patch adds that support by
adding dpu_encoder_prep_dsc() which is invoked when DSC is enabled.
Signed-off-by: Vinod Koul
---
Changes since
v1:
On Thu, Oct 21, 2021 at 10:22:43PM -0400, He Ying wrote:
> If we want to return from for_each_intel_connector_iter(), one
> way is calling drm_connector_list_iter_end() before returning
> to avoid memleak. The other way is just breaking from the bracket
> and then returning after the outside drm_co
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
> protected by the object lock.
>
> This removes the need to unpin, which is done by just releasing the
> lock.
>
> eb_reserve is slightly reworked for readability, but the
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Be thorough..
>
> Signed-off-by: Maarten Lankhorst
Is this strictly needed for something? Needs a proper commit message anyway.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gp
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
drivers
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel i
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/ad
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 ++
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
di
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 31 +
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 38 +-
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 11 +++
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 77 ++
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge but don't remove its driver.
Acked-by: Sam Ravnborg
Tested-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-s
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 98 +
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++---
1 file changed, 7
Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach
callback") moved the unregistration of the bridge DSI device and bridge
itself to the detach callback.
While this is correct for the DSI device detach and unregistration, the
bridge is added in the driver probe, and should thus be r
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device on removal.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 15 +--
1 file changed, 5 insertions(+), 10 de
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 13 -
1 file changed, 4 insertions(+
From: Rob Clark
Switch to the documented order dsi-host vs bridge probe.
Tested-by: Amit Pundir
Tested-by: Caleb Connolly
Tested-by: John Stultz
Signed-off-by: Rob Clark
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/dsi/dsi.c | 50 ---
drivers/gpu/drm
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 37 ++
Without proper care and an agreement between how DSI hosts and devices
drivers register their MIPI-DSI entities and potential components, we can
end up in a situation where the drivers can never probe.
Most drivers were taking evasive maneuvers to try to workaround this,
but not all of them were f
Hi Sam,
On Thu, Oct 21, 2021 at 05:22:55PM +0200, Sam Ravnborg wrote:
> Hi Maxime,
>
> > Let me know what you think,
>
> apply the lot to drm-misc-next. Maybe wait for an r-b or a-b on the kirin
> patch but the rest is IMO good to go.
I had a compilation error since the rebase of the v4, so I s
On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> Quoting Matthew Brost (2021-10-22 19:42:19)
> > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > > Hi Matt & John,
> > >
> > > Can you please queue patches with the right Fixes: references to convert
> > > all t
On Mon 25 Oct 01:42 PDT 2021, Uwe Kleine-K?nig wrote:
> Hello,
>
> [replaced Andrzej Hajda's email address with his new one]
>
> On Wed, Sep 29, 2021 at 10:05:57PM -0500, Bjorn Andersson wrote:
> > The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> > with the primary purpose
Hi,
Here is a series that enables the higher resolutions on the HDMI0 Controller
found in the BCM2711 (RPi4).
In order to work it needs a few adjustments to config.txt, most notably to
enable the enable_hdmi_4kp60 option.
Let me know what you think,
Maxime
---
Changes from v7:
- Rebased on c
Commit 9d44a8d5 ("drm/vc4: Fall back to using an EDID probe in the
absence of a GPIO.") added some code to read the EDID through DDC in the
HDMI driver detect hook since the Pi3 had no HPD GPIO back then.
However, commit b1b8f45b3130 ("ARM: dts: bcm2837: Add missing GPIOs of
Expander") changed
vc4_crtc_config_pv() retrieves the encoder again, even though its only
caller, vc4_crtc_atomic_enable(), already did.
Pass the encoder pointer as an argument instead of going through all the
connectors to retrieve it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 7 +++
Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the
detect hook, if we had an HPD GPIO we would only rely on it and return
whatever state it was in.
However, that commit changed that by mistake to only consider the case
where we have a GPIO and it returns a logical high, and w
We'll need that function in vc4_kms to compute the core clock rate
requirements.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b
1 - 100 of 253 matches
Mail list logo
