Am 2021-04-22 um 9:33 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
>
> wrote:
>
> Do AQL queue double-mapping with a single attach call. That will make it
> easier to create per-GPU BOs later, to be shared between the
On Fri, 23 Apr 2021, Kai-Heng Feng wrote:
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behavior is to let discret
Am 22.04.21 um 15:51 schrieb Jan Harkes:
On Thu, Apr 22, 2021 at 02:39:41PM +0200, Christian König wrote:
Am 22.04.21 um 14:27 schrieb Jan Harkes:
Looks good to me.
I'm also maintaining an out of tree coda module build that people sometimes
use, which has workarounds for differences between t
On Fri, 23 Apr 2021, ChiYuan Huang wrote:
> Hi, Lee:
>
> ChiYuan Huang 於 2021年4月19日 週一 下午5:55寫道：
> >
> > Lee Jones 於 2021年4月19日 週一 下午3:24寫道：
> > >
> > > On Mon, 19 Apr 2021, Lee Jones wrote:
> > >
> > > > On Mon, 19 Apr 2021, Lee Jones wrote:
> > > >
> > > > > On Mon, 19 Apr 2021, ChiYuan Huang
On Tue, 20 Apr 2021, Alex Deucher wrote:
> Applied. thanks!
Lovely. Thanks for these Alex.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-
Hey Sia,
Thanks for the reminder!
I've merged this patch to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/log/
On Thu, 22 Apr 2021 at 08:57, Sia Jee Heng wrote:
>
> Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI
> audio driver can accept the IEC958 data from the
This patch replaces ->mode_fixup() with ->atomic_check() so that
a full modeset can be requested from there when crtc_state->active
is changed to be true(which implies only connector's DPMS is brought
out of "Off" status, though not necessarily). Bridge functions are
added or changed to accommodat
Hi,
This series aims to make the nwl-dsi bridge be able to connect with
more MIPI DSI panels. Some MIPI DSI panel drivers like 'raydium,rm68200'
send MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
requires the MIPI DSI controller and PHY to be ready beforehand.
However, the exi
Some MIPI DSI panel drivers like 'raydium,rm68200' send
MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
requires the MIPI DSI controller and PHY to be ready beforehand.
Without this patch, the nwl-dsi driver gets the MIPI DSI controller
and PHY ready in bridge_funcs->atomic_pre_en
The check on unchanged HS clock rate in ->mode_set() improves
the callback's performance a bit by early return. However,
the up-coming patch would get MIPI DSI controller and PHY ready
in ->mode_set() after that check, thus likely skipped.
So, this patch removes that check to make sure MIPI DSI co
Hi Neil,
On Thu, 2021-04-22 at 14:07 +0200, Neil Armstrong wrote:
> Hi,
>
> On 22/04/2021 11:31, Liu Ying wrote:
> > Hi Neil,
> >
> > On Thu, 2021-04-22 at 10:48 +0200, Neil Armstrong wrote:
> > > Hi,
> > >
> > > On 22/04/2021 07:14, Liu Ying wrote:
> > > > Some MIPI DSI panel drivers like 'ray
Op 22-04-2021 om 13:00 schreef Mun, Gwan-gyeong:
> The changed name looks more accurate to the edp 1.4b spec.
> Looks good to me.
>
> Reviewed-by: Gwan-gyeong Mun
>
> On Wed, 2021-04-21 at 15:02 -0700, José Roberto de Souza wrote:
>> DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Captu
Op 22-04-2021 om 10:18 schreef Daniel Vetter:
> On Wed, Apr 21, 2021 at 04:39:10PM +0200, Maarten Lankhorst wrote:
>> Op 21-04-2021 om 16:32 schreef Daniel Vetter:
>>> On Wed, Apr 21, 2021 at 2:03 PM Maarten Lankhorst
>>> wrote:
Fixes the following htmldocs warnings:
drivers/gpu/drm/i915
On Thu, 22 Apr 2021 15:10:04 -0300
Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/uap
On Thu, Apr 22, 2021 at 03:08:48PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Mar 29, 2021 at 9:25 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Mar 25, 2021 at 5:09 PM Rob Herring wrote:
> > >
> > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > > > The sc7180-tr
On 22/04/2021 09:14, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 80 ++
In the function documentation, I removed the excess parameters,
described the undocumented ones, and fixed the syntax errors.
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 12 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 4 +++-
On Fri, Apr 23, 2021 at 11:42:47AM +0800, Artem Lapkin wrote:
> Problem: rmmod meson_gx_mmc - not stable without spi_master_suspend call
> and we can get stuck when try unload this module
> +++ b/drivers/spi/spi-meson-spifc.c
> @@ -359,6 +359,7 @@ static int meson_spifc_remove(struct platform_devi
On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The Kconfig dependency is incomplete since DRM_I915_GVT is a 'bool'
> > > sy
On 16/04/2021 17:37, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_irq.c:114: warning: expecting prototype for
enable_vblank(). Prototype was for omap_irq_enable_vblank() instead
drivers/gpu/drm/omapdrm/omap_irq.c:140: warning: expecting prot
On 16/04/2021 17:37, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: expecting prototype for
omap_gem_dumb_map(). Prototype was for omap_gem_dumb_map_offset() instead
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
C
From: dingsenjie
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: dingsenjie
---
drivers/gpu/drm/zte/zx_vou.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
Hello all,
We found this error when using Freedreno driver on an i.MX53 device
with Wayland. Any idea how to fix this?
[ 32.414110] [drm:msm_ioctl_gem_submit] *ERROR* invalid cmdstream size: 0
[ 39.177075]
[ 39.178617] ==
[ 39.184804] WA
On Thu, Apr 22, 2021 at 01:18:09PM -0400, Lyude Paul wrote:
> On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote:
> >
> > The init vs. register split is intentional. Registering the thing
> > and allowing userspace access to it before the rest of the driver
> > is ready isn't particularly grea
On Thu, Apr 22, 2021 at 06:33:44PM -0400, Lyude Paul wrote:
> OK - talked with Ville a bit on this and did some of my own research, I
> actually think that moving i2c to drm_dp_aux_init() is the right decision for
> the time being. The reasoning behind this being that as shown by my previous
> work
On Fri, Apr 23, 2021 at 12:11:06AM -0400, Lyude Paul wrote:
> On Thu, 2021-04-22 at 18:33 -0400, Lyude Paul wrote:
> > OK - talked with Ville a bit on this and did some of my own research, I
> > actually think that moving i2c to drm_dp_aux_init() is the right decision
> > for
> > the time being. Th
On Fri, Apr 23, 2021 at 12:46:54PM +0800, Kai-Heng Feng wrote:
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behav
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption,
On Fri, Apr 9, 2021 at 12:53 AM Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> In preparation for splitting this driver into sub-drivers, let's
> rename the main data structure so it's clear that it's holding data
> for the whole device and not just the MIPI-eDP bridge part.
>
> This is a no-op change.
>
Reviewed-by:
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Like the previous patch ("drm/bridge: ti-sn65dsi86: Rename the main
> driver data structure") this is just a no-op rename in preparation for
> splitting the driver up a bit.
>
> Here I've attempted to rename functions / structures making sur
On Fri, Apr 23, 2021 at 4:58 AM Otavio Salvador
wrote:
>
> Hello all,
>
> We found this error when using Freedreno driver on an i.MX53 device
> with Wayland. Any idea how to fix this?
>
> [ 32.414110] [drm:msm_ioctl_gem_submit] *ERROR* invalid cmdstream size: 0
The invalid cmdstream size is som
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Let's cleanup the debugfs code to:
> - Check for errors.
> - Use devm to manage freeing, which also means we don't need to store
> a pointer in our structure.
>
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes since v1)
>
> driv
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Tiny cleanup for probe so we don't keep having to specify
> "&client->dev" or "pdata->dev". No functional changes intended.
>
Nice
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes sin
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Let's:
> - Set the drvdata as soon as it's allocated. This just sets up a
> pointer so there's no downside here.
> - Remove the useless call to i2c_set_clientdata() which is literally
> the same thing as dev_set_drvdata().
>
> No functio
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> There's no devm_runtime_enable(), but it's easy to use
> devm_add_action_or_reset() and means we don't need to worry about the
> disable in our remove() routine or in error paths.
>
> No functional changes intended by this change.
>
Review
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> This is just code motion of the probe routine to move all the things
> that are for the "whole chip" (instead of the GPIO parts or the
> MIPI-to-eDP parts) together at the start of probe. This is in
> preparation for breaking the driver into
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Let's use the newly minted aux bus to break up the driver into sub
> drivers. We're not doing a full breakup here: all the code is still in
> the same file and remains largely untouched. The big goal here of
> using sub-drivers is to allow pa
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> When I added support for the hpd-gpio to simple-panel in commit
> 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying
> prepare()"), I added a special case to handle a circular dependency I
> was running into on the ti-sn65dsi86 b
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Let's make the bridge use autosuspend with a 500ms delay. This is in
> preparation for promoting DP AUX transfers to their own sub-driver so
> that we're not constantly powering up and down the device as we
> transfer all the chunks.
>
Revi
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> No functional changes--this just makes the diffstat of a future change
> easier to understand.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge
On Fri, 2021-04-23 at 12:25 +0200, Maarten Lankhorst wrote:
> Op 22-04-2021 om 13:00 schreef Mun, Gwan-gyeong:
> > The changed name looks more accurate to the edp 1.4b spec.
> > Looks good to me.
> >
> > Reviewed-by: Gwan-gyeong Mun
> >
> > On Wed, 2021-04-21 at 15:02 -0700, José Roberto de Souz
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Let's reorganize how we init and turn on the reference clock in the
> code to allow us to turn it on early (even before pre_enable()) so
> that we can read the EDID early. This is handy for eDP because:
> - We always assume that a panel is th
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> We'd like to be able to expose the DDC-over-AUX channel bus to our
> panel. This gets into a chicken-and-egg problem because:
> - The panel wants to get its DDC at probe time.
> - The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the D
Tested-by: Jonathan Marek
On 4/11/21 8:01 PM, Dmitry Baryshkov wrote:
msm_dsi_phy_get_clk_provider() always returns two provided clocks, so
return 0 instead of returning incorrect -EINVAL error code.
Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into a generic
code")
Signed
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
> drm_connector") the drm_get_edid() function calls
> drm_connector_update_edid_property() for us. There's no reason for us
> to call it again.
>
Reviewed-by: Bjorn Andersson
> S
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> I don't believe that it ever makes sense to read the EDID when a panel
> is not powered and the powering on of the panel is the job of
> prepare(). Let's make sure that this happens before we try to read the
> EDID. We use the pm_runtime func
On Fri, 23 Apr 2021 09:07:09 -0300
Jason Gunthorpe wrote:
> On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> > On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > > >
On 22/04/2021 00:31, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but easy to add.
The driver operates the
Add a quirk DW_I2S_QUIRK_STOP_ON_SHUTDOWN for Stoney/CZ
platforms.
For CZ/StoneyRidge platforms, ACP DMA between ACP SRAM and
I2S FIFO should be stopped before stopping I2S Controller DMA.
When DMA is progressing and stop request received, while DMA
transfer ongoing between ACP SRAM and I2S FIFO,
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> It doesn't make sense to go out to the bus and read the EDID over and
> over again. Let's cache it and throw away the cache when we turn power
> off from the panel. Autosuspend means that even if there are several
> calls to read the EDID bef
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> This is really just a revert of commit 58074b08c04a ("drm/bridge:
> ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
>
> The old code failed to read the EDID properly in a very important
> case: before the bridge's pre_enable()
On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
> Historically simple-panel had code to make sure that if prepare() was
> called on an already-prepared panel that it was a no-op. Similarly if
> unprepare() was called on an already-unprepared panel it was also a
> no-op. Essentially it means
Hi,
On Fri, Apr 23, 2021 at 9:12 AM Bjorn Andersson
wrote:
>
> On Fri 16 Apr 17:39 CDT 2021, Douglas Anderson wrote:
>
> > It doesn't make sense to go out to the bus and read the EDID over and
> > over again. Let's cache it and throw away the cache when we turn power
> > off from the panel. Autos
Hi, Jitao:
Jitao Shi 於 2021年4月20日 週二 下午9:26寫道：
>
> Add the drm_panel_prepare_power and drm_panel_unprepare_power control.
> Turn on panel power(drm_panel_prepare_power) and control before dsi
> enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last
> turn on backlight.
Please descr
Hi,
On Fri, Apr 16, 2021 at 3:41 PM Douglas Anderson wrote:
>
> Historically simple-panel had code to make sure that if prepare() was
> called on an already-prepared panel that it was a no-op. Similarly if
> unprepare() was called on an already-unprepared panel it was also a
> no-op. Essentially
dy.
This patch was developed agains linuxnext (next-20210416) with
drm-misc-next (as of 20210423) merged in on a sc7180-trogdor-lazor
device. To get things booting for me, I had to use Stephen's patch [2]
to keep from crashing but otherwise all the patches I needed were
here.
Primary change
In preparation for splitting this driver into sub-drivers, let's
rename the main data structure so it's clear that it's holding data
for the whole device and not just the MIPI-eDP bridge part.
This is a no-op change.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
(no changes
Let's cleanup the debugfs code to:
- Check for errors.
- Use devm to manage freeing, which also means we don't need to store
a pointer in our structure.
Signed-off-by: Douglas Anderson
---
Bjorn: I left off your tag on this patch since I made changes compared
to v4. Can you re-add if it still l
Like the previous patch ("drm/bridge: ti-sn65dsi86: Rename the main
driver data structure") this is just a no-op rename in preparation for
splitting the driver up a bit.
Here I've attempted to rename functions / structures making sure that
anything applicable to the whole chip (instead of just the
There's no devm_runtime_enable(), but it's easy to use
devm_add_action_or_reset() and means we don't need to worry about the
disable in our remove() routine or in error paths.
No functional changes intended by this change.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
Change
In commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to
avoid excessive unprepare / prepare") we started using pm_runtime, but
my patch neglected to add the proper pm_runtime_disable(). Doh! Add
them now.
Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid
excessive
Let's:
- Set the drvdata as soon as it's allocated. This just sets up a
pointer so there's no downside here.
- Remove the useless call to i2c_set_clientdata() which is literally
the same thing as dev_set_drvdata().
No functional changes intended.
Signed-off-by: Douglas Anderson
Reviewed-by:
When I added support for the hpd-gpio to simple-panel in commit
48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying
prepare()"), I added a special case to handle a circular dependency I
was running into on the ti-sn65dsi86 bridge chip. On my board the
hpd-gpio is actually provided by th
Tiny cleanup for probe so we don't keep having to specify
"&client->dev" or "pdata->dev". No functional changes intended.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
Changes in v5:
- Rebased atop the pm_runtime patch, which got reordered.
drivers/gpu/drm/bridge/ti-sn65dsi
This is just code motion of the probe routine to move all the things
that are for the "whole chip" (instead of the GPIO parts or the
MIPI-to-eDP parts) together at the start of probe. This is in
preparation for breaking the driver into sub-drivers.
Since we're using devm for all of the "whole chip
No functional changes--this just makes the diffstat of a future change
easier to understand.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 116 +-
1 file changed, 58 insertions(+), 58 dele
Let's use the newly minted aux bus to break up the driver into sub
drivers. We're not doing a full breakup here: all the code is still in
the same file and remains largely untouched. The big goal here of
using sub-drivers is to allow part of our code to finish probing even
if some other code needs
Let's reorganize how we init and turn on the reference clock in the
code to allow us to turn it on early (even before pre_enable()) so
that we can read the EDID early. This is handy for eDP because:
- We always assume that a panel is there.
- Once we report that a panel is there we get asked to rea
Let's make the bridge use autosuspend with a 500ms delay. This is in
preparation for promoting DP AUX transfers to their own sub-driver so
that we're not constantly powering up and down the device as we
transfer all the chunks.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
(n
This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2. Bas
Adding this link allows the panel code to do things like read the
EDID.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogd
We'd like to be able to expose the DDC-over-AUX channel bus to our
panel. This gets into a chicken-and-egg problem because:
- The panel wants to get its DDC at probe time.
- The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the DDC
bus, wants to get the panel at probe time.
By using a sub
I don't believe that it ever makes sense to read the EDID when a panel
is not powered and the powering on of the panel is the job of
prepare(). Let's make sure that this happens before we try to read the
EDID. We use the pm_runtime functions directly rather than directly
calling the normal prepare(
The of_find_i2c_adapter_by_node() could end up failing to find an
adapter in certain conditions. Specifically it's possible that
of_dev_or_parent_node_match() could end up finding an I2C client in
the list and cause bus_find_device() to stop early even though an I2C
adapter was present later in the
It doesn't make sense to go out to the bus and read the EDID over and
over again. Let's cache it and throw away the cache when we turn power
off from the panel. Autosuspend means that even if there are several
calls to read the EDID before we officially turn the power on then we
should get good use
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
As Laurent pointed out [1] this i
Dear all,
On a custom board I have a simple DPI panel. Panel's backlight is drive with an
I2C led driver (PCA9632). led-backlight driver is sued to manage this as a
backlight.
When using brightness-levels and default-brightness-level the backlight stay
turned-off even if manually trying to set
The pull request you sent on Fri, 23 Apr 2021 13:52:29 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5bfc75d92efd494db37f5c4c173d3639d4772966
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
v2:
- rebased on DSI PHY reworks
- reworked getting cphy_mode in dsi_host.c
- documentation change in separate patch
Jonathan Marek (2):
drm/
Document qcom,dsi-phy-cphy-mode option, which can be used to control
whether DSI will operate in D-PHY (default) or C-PHY mode.
Signed-off-by: Jonathan Marek
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bin
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 2 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 34 -
drive
On Fri, 2021-04-23 at 14:39 +0200, Thierry Reding wrote:
>
> I'm curious: how is a DP AUX adapter reference count going to solve the
> issue of potentially registering devices too early (i.e. before the DRM
> is registered)?
>
> Is it because registering too early could cause a reference count
>
This patch series fixes a regression that was introduced by one of the
changes I made to when Tegra registers its AUX adapters, along with
fixing some reference leaks that I found along the way.
!!!NOTE!!!
There's one thing I'm not entirely sure about, which is the
While we're taking a reference of the DDC adapter for a DP AUX channel in
tegra_sor_probe() because we're going to be using that adapter with the
SOR, now that we've moved where AUX registration happens the actual device
structure for the DDC adapter isn't initialized yet. Which means that we
can't
Noticed while fixing the regression I introduced in Tegra that Tegra seems
to actually never release the device or module references it's grabbing for
the DP AUX channel. So, let's fix that by dropping them when appropriate.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/tegra/sor.c | 19
Applied. Thanks!
Alex
On Thu, Apr 8, 2021 at 9:01 PM wrote:
>
> From: Yingjie Wang
>
> In dm_dp_mst_detect(), We should check whether or not @connector
> has been unregistered from userspace. If the connector is unregistered,
> we should return disconnected status.
>
> Fixes: 4562236b3bc0 ("dr
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
th
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14
1 - 100 of 171 matches
Mail list logo
