On 09/06/2022 04:32, Kuo-Hsiang Chou wrote:
Hi Jocelyn Falempe,
-Original Message-
From: Jocelyn Falempe [mailto:jfale...@redhat.com]
Sent: Wednesday, June 08, 2022 9:17 PM
To: Kuo-Hsiang Chou ; Thomas Zimmermann
; airl...@redhat.com; airl...@linux.ie; dan...@ffwll.ch;
regressi...@leem
Am 09.06.22 um 09:06 schrieb Jocelyn Falempe:
On 09/06/2022 04:32, Kuo-Hsiang Chou wrote:
Hi Jocelyn Falempe,
-Original Message-
From: Jocelyn Falempe [mailto:jfale...@redhat.com]
Sent: Wednesday, June 08, 2022 9:17 PM
To: Kuo-Hsiang Chou ; Thomas Zimmermann
; airl...@redhat.com; air
Am 09.06.22 um 02:05 schrieb Felix Kuehling:
[SNIP]
+ *
+ * ret = drm_exec_lock(&exec, boB, 1);
Where is drm_exec_lock? It's not in this patch.
I've renamed this function to drm_exec_prepare_obj() but forgot to
update the documentation. Going to fix this, thanks.
+ * drm_exec_c
From: KuoHsiang Chou
The threshold value is used for AST2600 only.
Signed-off-by: KuoHsiang Chou
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220117083643.41493-1-kuohsiang_c...@aspeedtech.com
---
drivers/gpu/drm/ast/ast_mode.c | 5 -
1 file chan
Mainline commit bcc77411e8a6 ("drm/ast: Create threshold values for
AST2600") needs backporting into older Linux kernels. The earliest
affected version is v5.11.
KuoHsiang Chou (1):
drm/ast: Create threshold values for AST2600
drivers/gpu/drm/ast/ast_mode.c | 5 -
1 file changed, 4 inserti
Panels usually call drm_connector_set_panel_orientation(), which is
later than drm/kms driver calling drm_dev_register(). This leads to a
WARN()[1].
The orientation property is known earlier. For example, some panels
parse the property through device tree during probe.
The series add a panel API
Panels usually call drm_connector_set_panel_orientation(), which is
later than drm/kms driver calling drm_dev_register(). This leads to a
WARN().
The orientation property is known earlier. For example, some panels
parse the property through device tree during probe.
Add an API to return the prope
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-edp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-lvds.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/panel/
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Sam Ravnborg
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-simple.c | 14 +-
1 file changed, 13 insertions(+), 1 del
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/
To return the orientation property to drm/kms driver.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hans de Goede
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/d
Panel orientation property should be set before drm_dev_register().
Some drm driver calls drm_dev_register() in .bind(). However, most
panels sets orientation property relatively late, mostly in .get_modes()
callback, since this is when they are able to get the connector and
binds the orientation p
Hi Joel,
On Wed, 8 Jun 2022 at 00:01, Joel Selvaraj wrote:
>
> Hi,
>
> I can see that the dts changes from this patch series has been applied
> to 5.19-rc1 release. However, this patch that has the related change to
> the panel driver, is not applied in the 5.19-rc1 release. Any particular
> reas
Hi Joel,
On Wed, 8 Jun 2022 at 22:10, Joel Selvaraj wrote:
>
> Hi Sumit,
>
> On 08/06/22 22:00, Sumit Semwal wrote:
> > This is entirely my fault - It somehow missed my radar, and I didn't
> > queue it up. I will push it via drm-misc tree tonight. Apologies
> > again!
>
> No problem. Thanks for t
Am Donnerstag, 9. Juni 2022, 08:49:26 CEST schrieb Liu Ying:
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Tested-by: Marcel Ziswiler # Colibr
Hi Liu,
Thank you for the patch.
On Thu, Jun 09, 2022 at 02:49:20PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp pixel combiner.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Liu Ying
> ---
> v7->v8:
> * No change.
>
> v6->v7:
> * No change.
>
> v5->v6:
> * No change.
>
On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:
On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:
On 08/06/2022 08:17, Tvrtko Ursulin wrote:
On 07/06/2022 20:37, Niranjana Vishwanathapura wrote:
On Tue, Jun 07, 2022 at 11:27:14AM +0100, Tvrtko Ursulin wrote:
On 17/05/2022
Hi,
On Mon 31 Jan 22, 17:47, quentin.sch...@theobroma-systems.com wrote:
> From: Quentin Schulz
>
> To prepare for a new display to be supported by this driver which has a
> slightly different set of DSI mode related flags, let's move the
> currently hardcoded mode flags to the .data field of of
Hi,
On Mon 31 Jan 22, 17:47, quentin.sch...@theobroma-systems.com wrote:
> From: Klaus Goger
>
> The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
> controller is a Himax HX8394-F, slightly different from LTK050H3146W by
> its init sequence, mode details and mode flags.
>
> Cc
Hi,
On Mon 31 Jan 22, 17:47, quentin.sch...@theobroma-systems.com wrote:
> From: Quentin Schulz
>
> The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
> controller is a Himax HX8394-F, slightly different from LTK050H3146W by
> its init sequence, mode details and mode flags.
No
FWIW, I found that reverting the two drm merges (with `git revert -m`)
from 5.19-rc1 "fixed" the issue.
Hi
Am 08.06.22 um 16:04 schrieb Alex Williamson:
You shouldn't have to copy any of the implementation of the aperture
helpers.
If you call drm_aperture_remove_conflicting_pci_framebuffers() it should
work correctly. The only reason why it requires a DRM driver structure
as second argument is f
Hi,
Please file issue at:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> -Original Message-
> From: Intel-gfx On Behalf Of Jason
> A.
> Donenfeld
> Sent: torstai 9. kesäkuut
Hello,
On Thu, May 26, 2022 at 10:25:38PM +0200, Uwe Kleine-König wrote:
> A remove callback that just returns 0 is equivalent to no callback at all
> as can be seen in i2c_device_remove(). So simplify accordingly.
I intend to change the prototype of i2c remove callbacks to return void
after the
On Wed, Jun 08, 2022 at 05:37:50PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2022 at 02:58:21PM +0100, Daniel Thompson wrote:
> > Since it's inception in 2012 it has been understood that the DRM GEM CMA
> > helpers do not depend on CMA as the backend allocator. In fact the first
> > bug fix to
Done. https://gitlab.freedesktop.org/drm/intel/-/issues/6205
On Wed, Jun 08, 2022 at 05:36:08PM +0200, Maxime Ripard wrote:
> On Wed, Jun 08, 2022 at 04:14:22PM +0100, Peter Robinson wrote:
> > > > > As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry
> > > > > Pi
> > > > > 3B any more.
> > > > >
> > > > > If a monitor is attached to the de
On Thu, Jun 09, 2022 at 10:22:18AM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add 'richtek,bled-ocp-microamp' property to make it chooseable.
>
> The wrong backlight ocp level may affect the backlight channel output
> current smaller than configured.
>
> Signed-off-by: ChiYuan Huang
Rev
Hi Liu,
Thank you for the patch.
On Thu, Jun 09, 2022 at 02:49:23PM +0800, Liu Ying wrote:
> This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
> The pixel link forms a standard asynchronous linkage between
> pixel sources(display controller or camera module) and pixel
> cons
Hi Liu,
On Thu, Jun 09, 2022 at 02:49:17PM +0800, Liu Ying wrote:
> Hi,
>
> This is the v8 series to add some DRM bridge drivers support
> for i.MX8qm/qxp SoCs.
>
> The bridges may chain one by one to form display pipes to support
> LVDS displays. The relevant display controller is DPU embedded
On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> Instead of checking the state of various backlight_properties fields
> against the memorised state in atmel_lcdfb_info.bl_power,
> atmel_bl_update_status() should retrieve the desired state using
> backlight_get_brightness (which takes
Hi Daniel, Dave,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2022-06-09:
One fix to handle DT errors in ti-sn65dsi83, a fix for a use-after-free in
panfrost, two fixes for panel self-refresh handling, and one to fix
multiple output support on AST.
The following changes since commit
Hi Yunfei Dong,
On 5/26/22 11:57, Yunfei Dong wrote:
> Fix v4l2 capability bus_info value with correct chip name according to
> compatible.
>
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 delet
On 09/06/2022 04:22, cy_huang wrote:
> From: ChiYuan Huang
>
> Add 'richtek,bled-ocp-microamp' property to make it chooseable.
>
> The wrong backlight ocp level may affect the backlight channel output
> current smaller than configured.
>
> Signed-off-by: ChiYuan Huang
> ---
> Since v3:
> - Ref
Conversion to use bulk regulator API omitted filling the pwr_regs with
proper regulator IDs. This was left unnoticed, since none of my testing
platforms has used the pwr_regs. Fix this by propagating regulator ids
properly.
Fixes: 31b3b1f5e352 ("drm/msm/hdmi: use bulk regulator API")
Signed-off-by
> > > > > > As of Linux 5.18.0, module vc4 apparently isn't working on
> > > > > > Raspberry Pi
> > > > > > 3B any more.
> > > > > >
> > > > > > If a monitor is attached to the device, the boot messages show up as
> > > > > > usual, but right when KMS starts, the screen turns black.
> > > > > > S
Hi Javier
Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
From: Daniel Vetter
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
There is fb_client_register() to set up a 'client' on top of an fbdev.
The client would then
> >>> As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry Pi
> >>> 3B any more.
> >>>
> >>> If a monitor is attached to the device, the boot messages show up as
> >>> usual, but right when KMS starts, the screen turns black. Similarly, the
> >>> screen also turns black when the mod
On 09/06/2022 01:45, David Heidelberg wrote:
On 08/06/2022 14:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- d
On 08/06/2022 15:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were n
As agreed with David, this is a continuation of his work started at [1].
Changes since v2:
- Deprecated usage of phy-names for HDMI node, added two patches to
remove this property from DT files,
- Fixed the uninitialized variable access in hpd_gpio code.
Changes since v1:
- Dropped quotes in $i
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were not documented
- make phy-names deprecated, drop it from the examples
PHY:
- moved into phy/ dir
hdmi-mux-supply is not used by the SoC's HDMI block, it is thought to
power up the external logic. Thus it should not be a part of HDMI
bindings, but it should be declared at some other device in the DT (like
HDMI mux, bridge, etc). Mark it as deprecated.
Reviewed-by: Krzysztof Kozlowski
Reviewed
The HDMI circuitry on the IFC6410 is not powered by the 3v3. Drop the
hdmi-mux-supply property.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply
regulators that are to be enabled for HPD to work. Currently these
regulators contain the hpd_gdsc, which was replaced by the power-domains
support and hpd-5v/hpd-5v-en, which are not used by the chip itself.
They power up the ESD br
DB820c makes use of core-vcc-supply and core-vdda-supply, however the
driver code doesn't support these regulators. Enable them for HDMI on
8996 platform.
Fixes: 0afbe59edd3f ("drm/msm/hdmi: Add basic HDMI support for msm8996")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm platforms uses these properties, so it's
safe to drop them.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
dri
Several platform configs use empty 'none' regulator arrays. They are not
necessary, as the code will use corresponding _cnt field and skip the
array completely. Drop them now.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 -
1 file changed
With the last (and only) in-kernel user of hdmi-mux regulator, drop it
from the HDMI driver.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/driver
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm89
MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse
MSM8960's config for the MSM8660 (8x60).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064
Since there is no more difference between the HDMI platform data
between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a
single entry.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 27 +++
1 file changed, 3 in
Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface
clock (this is the same config as is used by the 8960).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 12
1 file changed, 12 insertions(+)
diff --git
Mark obsolete GPIO properties as deprecated. They are not used by
existing device trees. While we are at it, also drop them from the
schema example.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/hdmi
> Which kernel config do you use (is it a defconfig)?
These are custom configs provided by the distribution, the origin of
which I do not know.
You can find them at [1] (5.17.0, used in 5.17.1 as well) and [2]
(5.18.0, modified in 5.18.1).
The difference between these files and their upstream (k
> If I understand you properly, it results in a blank screen if the
> monitor is connected, but the system is still responsive?
Yes. Similar to (the other) Peter's findings, the system is fully
responsive, it's just that the monitor is displaying a black screen.
Meanwhile I stumbled upon another
Hello Thomas,
On 6/9/22 13:49, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
>> From: Daniel Vetter
>>
>> Well except when the olpc dcon fbdev driver is enabled, that thing
>> digs around in there in rather unfixable ways.
>
> There is fb_client
On Fri, Jun 03, 2022 at 07:56:16AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 3, 2022 at 7:14 AM Maxime Ripard wrote:
> >
> > On Fri, Jun 03, 2022 at 01:19:16PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> > > >
> > > > On Tue, May 31, 2022 at 0
> Could you start a bisection maybe?
I for one am having two issues here.
The harmless one is that I'm lacking a cooler for the RPi and my cross
compiling skills have become a bit rusty.
Both could be fixed quickly, of course.
The not so harmless one is that kernel 5.18.x is completely unusab
On Tue, 7 Jun 2022 19:08:48 +0800, GONG, Ruiqi wrote:
> Fix the `unused-but-set-variable` warning as how other iteration
> wrappers do.
>
>
Applied to drm/drm-misc (drm-misc-fixes).
Thanks!
Maxime
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
On 9/27/2021 8:59 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
Internal err
On 6/7/22 20:23, Javier Martinez Canillas wrote:
> The patches in this series contain mostly changes suggested by Daniel Vetter
> Thomas Zimmermann. They aim to fix existing races between the Generic System
> Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.
>
> For exa
Am 2022-06-09 um 03:18 schrieb Christian König:
Am 09.06.22 um 02:05 schrieb Felix Kuehling:
[SNIP]
+ *
+ * ret = drm_exec_lock(&exec, boB, 1);
Where is drm_exec_lock? It's not in this patch.
I've renamed this function to drm_exec_prepare_obj() but forgot to
update the documentati
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a re
On Wed, Jun 08, 2022 at 11:50:31AM -0400, Eric Farman wrote:
> > --- a/drivers/s390/cio/vfio_ccw_private.h
> > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > @@ -98,7 +98,6 @@ struct vfio_ccw_private {
> > struct completion *completion;
> > atomic_tavail;
> > struct
On 09/06/2022 00:55, Jason Ekstrand wrote:
On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
wrote:
On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote:
>
>
>On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
>>On Tue, Jun 07, 2022 at 11:18:11AM -0700,
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
>
> On 6/9/2022 2:17 AM, Rob Clark wrote:
> > On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen
> > wrote:
> >> On 6/8/2022 3:00 AM, Rob Clark wrote:
> >>> On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen
> >>> wrote:
> On 9/27/2021 8:5
Hi,
Thanks
Acked-by: Raphael Gallais-Pou
Cheers,
Raphaël
On 6/3/22 15:42, Yannick Fertre wrote:
> Remove error message about scaling & replace it by a debug
> message to avoid too much error.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 3 ++-
> 1 file changed, 2
Hi,
Thanks
Acked-by: Raphael Gallais-Pou
Cheers,
Raphaël
On 6/3/22 15:43, Yannick Fertre wrote:
> Fix issues reported by checkpatch.pl:
> - Braces {} should be used on all arms
> - Blank lines
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 5 ++---
> 1 file changed
On 6/9/2022 8:03 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
">" ??
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "stru
On 6/9/2022 8:27 PM, Doug Anderson wrote:
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
On 9/
On 6/8/2022 9:43 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
Hardware name: Google Wormdingler rev1+ INX panel board (DT)
pstate: 20c9 (nzCv daif +PAN +UAO)
pc : msm_readl+0x
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
>
> From testing on sc7180-trogdor devices, reading the GMU registers
> needs the GMU clocks to be enabled. Those clocks get turned on in
> a6xx_gmu_resume(). Confusingly enough, that function is called as a
> result of the runtime_pm of the G
On 6/9/2022 9:24 PM, Rob Clark wrote:
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
r
As Liviu pointed out, the arm,malidp-arqos-high-level property
mentioned in the original .txt binding was a mistake, and
arm,malidp-arqos-value needs to take its place.
The binding commit ce6eb0253cba ("dt/bindings: display: Add optional
property node define for Mali DP500") mentions the right nam
On Wed, 11 May 2022 13:03:36 +0100
Liviu Dudau wrote:
Hi Liviu,
> On Mon, May 09, 2022 at 02:49:01PM +0100, Andre Przywara wrote:
> > On Fri, 06 May 2022 17:39:53 -0500
> > Rob Herring wrote:
> >
> > > On Fri, 06 May 2022 15:05:32 +0100, Andre Przywara wrote:
> > > > The Arm Mali Display P
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a re
Hi,
On Wed, Jun 8, 2022 at 9:13 AM Rob Clark wrote:
>
> From: Rob Clark
>
> I've seen a few crashes like:
>
> CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
> Hardware name: Google Wormdingler rev1+ INX panel board (DT)
> pstate: 20c9 (nzCv daif +PAN +UA
This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.
v2: - commit message improvements to add detai
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well after
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt. The object only exists as a fake object pointing to ggtt
and gains no benefit in going via the internal backend.
Instead, create a dummy gem
Internal/volatile buffers should not be shmem backed.
If a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing.
Fix i915_ttm_shrink to handle !is_shmem volatile buffers by purging.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Signed-of
Create a kernel only internal memory region that uses ttm pool allocator to
allocate volatile system pages.
Refactor internal buffer backend to simply allocate from this new
region.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 187 +-
drivers/
In commit 450cede7f380 ("drm/i915/gem: Fix the mman selftest") we fixed up
the mman selftest to allocate user buffers via smem only if we have lmem,
otherwise it uses internal buffers.
As the commit message asserts, we should only be using buffers that
userland should be able to create.
Internal b
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915
Reorder scratch page allocation so that memory regions are available
to allocate the buffers
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
drivers/gpu/drm/i915/gt/intel_gt_gmch.h | 6 ++
drivers/gpu/drm/i9
Hi Javier.
On Thu, Jun 09, 2022 at 03:09:21PM +0200, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 6/9/22 13:49, Thomas Zimmermann wrote:
> > Hi Javier
> >
> > Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
> >> From: Daniel Vetter
> >>
> >> Well except when the olpc dcon fbdev
Hi Stephen,
thanks for taking care of all these backlight simplifications - this
really helps to make the code simpler and more readable.
On Thu, Jun 09, 2022 at 10:54:12AM +0100, Daniel Thompson wrote:
> On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> > Instead of checking the st
Hello Sam,
On 6/9/22 19:23, Sam Ravnborg wrote:
[snip]
>
> To repeat myself from irc.
> olpc_dcon is a staging driver and we should avoid inventing anything in
> core code for to make staging drivers works.
> Geert suggested EXPORT_SYMPBOL_NS_GPL() that could work and narrow it
> down to olpc_d
From: Rob Clark
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
pos:0
From: Rob Clark
The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to
provide additional file ops, like show_fdinfo().
v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS
varardic
v3: nits
Signed-off-by: Rob Clark
Acked-by: Thomas Zimmermann
---
include/drm
Hi Sam, Daniel,
On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg wrote:
> thanks for taking care of all these backlight simplifications - this
> really helps to make the code simpler and more readable.
You’re welcome! I noticed fb_blank was deprecated and near enough unused, and
started digging..
On 6/9/2022 10:17 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device
This series introduces a binding for Type-C data lane switches. These
control the routing and operating modes of USB Type-C data lanes based
on the PD messaging from the Type-C port driver regarding connected
peripherals.
The first patch introduces a change to the Type-C mux class mode-switch
matc
On Thu, Jun 9, 2022 at 11:04 AM Akhil P Oommen wrote:
>
> On 6/9/2022 10:17 PM, Douglas Anderson wrote:
> > >From testing on sc7180-trogdor devices, reading the GMU registers
> > needs the GMU clocks to be enabled. Those clocks get turned on in
> > a6xx_gmu_resume(). Confusingly enough, that funct
Instead of checking the state of various backlight_properties fields
against the memorised state in atmel_lcdfb_info.bl_power,
atmel_bl_update_status() should retrieve the desired state using
backlight_get_brightness (which takes into account the power state,
blanking etc.). This means the explicit
1 - 100 of 137 matches
Mail list logo
