Hi,
On 12/02/2022 16:50, H. Nikolaus Schaller wrote:
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no long
Hello,
On Wed, Dec 01, 2021 at 02:23:28AM +0300, Dmitry Osipenko wrote:
> The PWM on Tegra belongs to the core power domain and we're going to
> enable GENPD support for the core domain. Now PWM must be resumed using
> runtime PM API in order to initialize the PWM power state. The PWM clock
> rate
Am 21.02.22 um 04:28 schrieb Qiang Yu:
On Fri, Feb 18, 2022 at 6:24 PM Christian König
wrote:
Am 18.02.22 um 11:16 schrieb Qiang Yu:
[SNIP]
If amdgpu_vm_ready() use evicting flag, it's still not equivalent to check
vm idle: true -> vm idle, false -> vm may be idle or busy.
Yeah, but why shou
On 20/02/2022 16:48, Dominique Dumont wrote:
On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
Does the system actually suspend?
Not really. The screens looks like it's going to suspend, but it does come
back after 10s or so. The light mounted in the middle of the power button does
On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> Does the system actually suspend?
Not really. The screens looks like it's going to suspend, but it does come
back after 10s or so. The light mounted in the middle of the power button does
not switch off.
> Is this system S0i3 or r
Hello Christoph,
On Sat, 19 Feb 2022 09:28:44 +
Christoph Niedermaier wrote:
> From: Max Krummenacher [mailto:max.oss...@gmail.com]
> Sent: Wednesday, February 9, 2022 10:38 AM
> >> If display timings were read from the devicetree using
> >> of_get_display_timing() and pixelclk-active is def
Hi
> Gesendet: Donnerstag, 17. Februar 2022 um 09:29 Uhr
> Von: "Sascha Hauer"
> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> @@ -10,7 +10,6 @@
> #include
> #include
> #include
> -#include
why dropping this after adding in part 16?
>
On Mon, Feb 21, 2022 at 08:28:35AM +0100, José Expósito wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
Reviewed-by: Maxime Ripard
Maxime
s
On Mon, Feb 21, 2022 at 08:33:39AM +0100, José Expósito wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
Reviewed-by: Maxime Ripard
Maxime
s
On Mon, Feb 21, 2022 at 08:37:57AM +0100, José Expósito wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
> ---
> drivers/gpu/drm/rcar-du/rcar_lv
On Mon, Feb 21, 2022 at 08:42:24AM +0100, José Expósito wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
Reviewed-by: Maxime Ripard
Maxime
s
On Sat, Feb 19, 2022 at 03:26:40AM +0100, Marek Vasut wrote:
> On 2/18/22 18:34, Lucas Stach wrote:
>
> Hi
>
> [...]
>
> > > drivers/gpu/drm/bridge/tc358767.c | 26 ++
> > > 1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/tc358767.c
>
On Sun, Feb 20, 2022 at 10:32:25PM +0100, Sam Ravnborg wrote:
> Hi Noralf,
>
> On Sun, Feb 20, 2022 at 04:59:34PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 19.02.2022 23.10, skrev Sam Ravnborg:
> > > Hi Noralf,
> > > On Fri, Feb 18, 2022 at 04:11:10PM +0100, Noralf Trønnes wrote:
> > >> Add a
Am Samstag, dem 19.02.2022 um 03:39 +0100 schrieb Marek Vasut:
> On 2/18/22 18:49, Lucas Stach wrote:
> > Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> > > The TC358767/TC358867/TC9595 are all capable of operating either from
> > > attached Xtal or from DSI clock lane clock. In c
On Sun, 20 Feb 2022 22:02:12 -0300
Igor Torrente wrote:
> Hi Melissa,
>
> On 2/9/22 18:45, Melissa Wen wrote:
> > On 02/08, Igor Torrente wrote:
> >> Hi Melissa,
> >>
> >> On 2/8/22 07:40, Melissa Wen wrote:
> >>> On 01/21, Igor Torrente wrote:
> Currently the blend function only acce
On 2/20/22 5:55 PM, Sui Jingfeng wrote:
> From: suijingfeng
>
> The display controller is a pci device, its PCI vendor id is 0x0014
> its PCI device id is 0x7a06.
>
> 1) In order to let the driver to know which chip the DC is contained
>in, the compatible string of the display controller is
On Mon, 21 Feb 2022, Dave Airlie wrote:
> On Thu, 17 Feb 2022 at 20:26, Joonas Lahtinen
> wrote:
>>
>> Hi Dave & Daniel,
>>
>> Here is the first drm-intel-gt-next feature PR towards v5.18.
>
> Am I missing some previous drm-intel pull?
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/g
Hi
(Now I remember your series ;)
On Fri, Feb 18, 2022 at 03:54:31PM +0100, Guillaume Ranquet wrote:
> dpintf is the displayport interface hardware unit. This unit is similar
> to dpi and can reuse most of the code.
>
> This patch adds support for mt8195-dpintf to this dpi driver. Main
> differe
Hi
Am 18.02.22 um 17:04 schrieb Michal Suchanek:
Since switch to simplefb/simpledrm VESA graphic modes are no longer
available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simplefb in l
On Mon, Feb 21, 2022 at 09:54:28AM +0100, Frank Wunderlich wrote:
> Hi
>
> > Gesendet: Donnerstag, 17. Februar 2022 um 09:29 Uhr
> > Von: "Sascha Hauer"
>
> > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > @@ -10,7 +10,6 @@
> > #include
>
From: Robin van der Gracht
This series of devices is using lg,lb070wv8 instead of kyo,tcg121xglp.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-victgo.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx
From: Robin van der Gracht
Interrupt counter is mainlined, now we can add missing counter nodes.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-victgo.dts | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff
From: David Jander
Recover default behavior of the device and set maximal brightness
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-victgo.dts | 2 +-
arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
From: Robin van der Gracht
According to Documentation/devicetree/bindings/sound/fsl,ssi.txt
'fsl,mode' should be specified for AC97 mode only.
The 'fsl,ssi' documentation doesn't say anything about specifying
'sound-dai-cells' so we'll remove that as well.
Signed-off-by: Robin van der Gracht
S
From: David Jander
countedX lines have different board names (YACO_x). And REV_ and BOARD_ pins
have multiple functions. So, use names exposed to the OS.
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 12 +++-
1 file changed, 7 in
From: David Jander
backlight_led is the dimmable backlight for the rubber border on the case. It
is also used to highlight the power- and some other buttons.
MX6QDL_PAD_SD4_DAT1__PWM3_OUT is also assigned as output for pwm3. Since
we need pwm3 for the backlight, we're forced to disable user spac
From: David Jander
The gpio1 0 pin is controlling CAN termination, not USB H1 VBUS. So,
remove wrong regulator and assign this gpio to new DT CAN termination
property.
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-victgo.dts | 12 ++--
1 file c
From: David Jander
We have two backlight sources on this boards. Use more specific name for
the LCD backlight to see the difference.
Signed-off-by: David Jander
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-victgo.dts | 4 ++--
arch/arm/boot
Hello Uwe,
21.02.2022 11:17, Uwe Kleine-König пишет:
>> @@ -344,7 +387,10 @@ static const struct of_device_id tegra_pwm_of_match[] =
>> {
>> MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
>>
>> static const struct dev_pm_ops tegra_pwm_pm_ops = {
>> -SET_SYSTEM_SLEEP_PM_OPS(tegra_pwm_suspend
Hi Stephen,
(CC'ing Jean-Michel)
On Fri, Feb 18, 2022 at 06:24:08PM -0800, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2022-02-14 01:45:56)
> > Hi Maxime and Stephen,
> >
> > We have recently posted a driver for the BCM2711 Unicam CSI-2 receiver
> > (see [1]) which is a perfect candidate for
Add device pointer so scheduler's printing can use
DRM_DEV_ERROR() instead, which makes life easier under multiple GPU
scenario.
v2: amend all calls of drm_sched_init()
v3: fill dev pointer for all drm_sched_init() calls
Signed-off-by: Jiawei Gu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |
Hi,
We have a bunch of functions that create planes properties that will take a
default value, but it isn't actually enforced in the plane state.
This leads to drivers having multiple strategies to work around that issue,
most of them being a variation of forcing a value at plane state reset time
komeda_plane_reset() does the state initialisation by copying a lot of
the code found in the __drm_atomic_helper_plane_reset(). Let's switch to
that helper and reduce the boilerplate.
Cc: Brian Starkey
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Signed-off-by: Maxime Ripard
-
tegra_plane_reset() does the state initialisation by copying a lot of
the code found in the __drm_atomic_helper_plane_reset(). Let's switch to
that helper and reduce the boilerplate.
Cc: linux-te...@vger.kernel.org
Cc: Jonathan Hunter
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
drivers
The amdgpu KMS driver calls drm_plane_create_color_properties() with a
default encoding set to BT709.
However, the core will ignore it and the driver doesn't force it in its
plane state reset hook, so the initial value will be 0, which represents
BT601.
Fix the mismatch by using an initial value
While the tegra_shared_plane_create() function calls
drm_plane_create_zpos_property() with an initial value of 0,
tegra_plane_reset() will force it to the plane index.
Fix the discrepancy by setting the initial zpos value to the plane index
in the function call.
Cc: linux-te...@vger.kernel.org
Cc
The exynos KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in exynos_drm_plane_reset(). However, the helpers have
been adjusted to set it properly at re
The tegra KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index.
Since the initial value wasn't carried over in the state, the driver had
to set it again in tegra_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is no
While the omap_plane_init() function calls
drm_plane_create_zpos_property() with an initial value of 0,
omap_plane_reset() will force it to another value depending on the plane
type.
Fix the discrepancy by setting the initial zpos value to the same value
in the drm_plane_create_zpos_property() cal
The mdp KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in mdp5_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so t
From: Dave Stevenson
The drm_plane_create_zpos_property() function asks for an initial value,
and will set the associated plane state variable with that value if a
state is present.
However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset hel
The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in rcar_du_plane_reset() and rcar_du_vsp_plane_reset().
However, the helpers have been adjusted
The omap KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index and the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in omap_plane_reset(). However, the helpers have been
adjusted to set it properly at res
The komeda KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index.
Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is
The sun4i KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in sun4i_backend_layer_reset().
However, the helpers have been adjusted to set it properly at res
The sti KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in sti_plane_reset().
However, the helpers have been adjusted to set it properly at reset, so
this
From: Dave Stevenson
Some functions to create properties (drm_plane_create_zpos_property or
drm_plane_create_color_properties for example) will ask for a range of
acceptable value and an initial one.
This initial value is then stored in the values array for that property.
Let's provide an helpe
The armada KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Limited Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in armada_overlay_reset(). However, the helpers have been
From: Dave Stevenson
The drm_plane_create_color_properties() function asks for an initial
value for the color encoding and range, and will set the associated
plane state variable with that value if a state is present.
However, that function is usually called at a time where there's no
state yet.
The nouveau KMS driver will call drm_plane_create_zpos_property() with
an init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in nv50_wndw_reset(). However, the helpers have been
adjusted to set it properly at reset, s
The imx KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in ipu_plane_state_reset(). However, the helpers have
been adjusted to set it properly at reset,
The komeda KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Limited Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
ad
The omap KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Full Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in omap_plane_reset(). However, the helpers have been
adjusted
The imx KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Limited Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in ipu_plane_state_reset(). However, the helpers have been
ad
On 21/02/2022 10:19, Sergei Shtylyov wrote:
> On 2/20/22 5:55 PM, Sui Jingfeng wrote:
>
>> From: suijingfeng
>>
>> The display controller is a pci device, its PCI vendor id is 0x0014
>> its PCI device id is 0x7a06.
>>
>> 1) In order to let the driver to know which chip the DC is contained
>>i
Workstation application ANSA/META get this error dmesg:
[drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)
This is caused by:
1. create a 256MB buffer in invisible VRAM
2. CPU map the buffer and access it causes vm_fault and try to move
it to visible VRAM
3. force visible VR
On Fri, 18 Feb 2022 12:03:58 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves
Am 21.02.22 um 10:57 schrieb Jiawei Gu:
Add device pointer so scheduler's printing can use
DRM_DEV_ERROR() instead, which makes life easier under multiple GPU
scenario.
v2: amend all calls of drm_sched_init()
v3: fill dev pointer for all drm_sched_init() calls
Signed-off-by: Jiawei Gu
Review
Am 21.02.22 um 11:12 schrieb Qiang Yu:
Workstation application ANSA/META get this error dmesg:
[drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)
This is caused by:
1. create a 256MB buffer in invisible VRAM
2. CPU map the buffer and access it causes vm_fault and try to mo
Hello,
On Fri, May 14, 2021 at 12:01:42PM +0200, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the select for I2C for the
Dear Qiang Yu,
Am 21.02.22 um 11:12 schrieb Qiang Yu:
Thank you for your patch. Reading the commit message summary, I have no
idea what “check vm ready by evicting” means. Can you please rephrase it?
Workstation application ANSA/META get this error dmesg:
What version, and how can this b
Hi Rob,
On 25/01/2022 10:24, Tvrtko Ursulin wrote:
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere that displays this info, that would be
useful for testing my implementation.
I have a patch to Intel specific intel_gp
Den 18.02.2022 16.11, skrev Noralf Trønnes:
> Add binding for MIPI DBI compatible SPI panels.
>
> v4:
> - There should only be two compatible (Maxime)
> - s/panel-dbi-spi/panel-mipi-dbi-spi/in compatible
>
> v3:
> - Move properties to Device Tree (Maxime)
> - Use contains for compatible (Maxim
Move parts of dcn20 code that uses FPU to dml folder. It aims to isolate
FPU operations as described by series:
drm/amd/display: Introduce FPU directory inside DC
https://patchwork.freedesktop.org/series/93042/
This patch moves the following functions from dcn20_resource to
dml/dcn20_fpu and call
On 2/19/22 19:48, Dmitry Osipenko wrote:
18.02.2022 14:39, Mikko Perttunen пишет:
...
+/*
+ * Due to an issue with T194 NVENC, only 38 bits can be used.
+ * Anyway, 256GiB of IOVA ought to be enough for anyone.
+ */
+static dma_addr_t context_device_dma_mask = DMA_BIT_MASK(38);
s/dma_addr_t/u6
On 2/19/22 19:52, Dmitry Osipenko wrote:
18.02.2022 14:39, Mikko Perttunen пишет:
+ for (index = 0; index < cdl->len; index++) {
+ struct iommu_fwspec *fwspec;
+
+ ctx = &cdl->devs[index];
+
+ ctx->host = host1x;
+
+ device_initialize
On 2/19/22 20:54, Dmitry Osipenko wrote:
19.02.2022 21:49, Dmitry Osipenko пишет:
18.02.2022 14:39, Mikko Perttunen пишет:
+static int vic_get_streamid_offset(struct tegra_drm_client *client)
+{
+ struct vic *vic = to_vic(client);
+ int err;
+
+ err = vic_load_firmware(vic);
Hi Sascha:
On 2/17/22 16:29, Sascha Hauer wrote:
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonsta
Am Montag, den 21.02.2022, 09:29 +0100 schrieb Boris Brezillon:
> Hello Christoph,
>
> On Sat, 19 Feb 2022 09:28:44 +
> Christoph Niedermaier wrote:
>
> > From: Max Krummenacher [mailto:max.oss...@gmail.com]
> > Sent: Wednesday, February 9, 2022 10:38 AM
> > > > If display timings were read
On 2/19/22 20:35, Dmitry Osipenko wrote:
18.02.2022 14:39, Mikko Perttunen пишет:
+ if (context->memory_context &&
context->client->ops->get_streamid_offset) {
^^^
+ int offset =
context->client->ops->get_streamid_offset(context->client);
+
+ if
When running the mock selftests we currently blow up with:
<6> [299.836278] i915: Running
i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages
<1> [299.836356] BUG: kernel NULL pointer dereference, address: 00c8
<1> [299.836361] #PF: supervisor read access in kernel mod
On Mon, Feb 21, 2022 at 09:56:19AM +0100, Maxime Ripard wrote:
> On Mon, Feb 21, 2022 at 08:37:57AM +0100, José Expósito wrote:
> > The function "drm_of_find_panel_or_bridge" has been deprecated in
> > favor of "devm_drm_of_get_bridge".
> >
> > Switch to the new function and reduce boilerplate.
>
On Mon, 21 Feb 2022 12:56:43 +0100
Max Krummenacher wrote:
> Am Montag, den 21.02.2022, 09:29 +0100 schrieb Boris Brezillon:
> > Hello Christoph,
> >
> > On Sat, 19 Feb 2022 09:28:44 +
> > Christoph Niedermaier wrote:
> >
> > > From: Max Krummenacher [mailto:max.oss...@gmail.com]
> > > S
On 10/02/2022 13:34, Vinod Koul wrote:
When DSC is enabled, we need to pass the DSC parameters to panel driver
as well, so add a dsc parameter in panel and set it when DSC is enabled
Also, fetch and pass DSC configuration for DSI panels to DPU encoder,
which will enable and configure DSC hardwar
On 18/02/2022 03:47, Kasireddy, Vivek wrote:
Hi Tvrtko,
On 17/02/2022 07:50, Vivek Kasireddy wrote:
While looking for next holes suitable for an allocation, although,
it is highly unlikely, make sure that the DECLARE_NEXT_HOLE_ADDR
macro is using a valid node before it extracts the rb_node
On 16/02/2022 10:36, Christian König wrote:
Am 15.02.22 um 23:23 schrieb Vivek Kasireddy:
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
all
Panels with higher refresh rate will need mdp clk above 300Mhz.
Select max frequency for mdp clock during bootup, dpu driver will
scale down the clock as per usecase when first update from the framework is
received.
Signed-off-by: Vinod Polimera
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
On Mon, 2022-02-21 at 12:11 +, Matthew Auld wrote:
> When running the mock selftests we currently blow up with:
>
> <6> [299.836278] i915: Running
> i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages
> <1> [299.836356] BUG: kernel NULL pointer dereference, address:
> 0
Hello,
On Mon, Feb 21, 2022 at 12:53:58PM +0300, Dmitry Osipenko wrote:
> 21.02.2022 11:17, Uwe Kleine-König пишет:
> >> @@ -344,7 +387,10 @@ static const struct of_device_id tegra_pwm_of_match[]
> >> = {
> >> MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
> >>
> >> static const struct dev_pm_o
Hi,
This series fixes a long standing issue with the VC4 driver when one was
moving the cursor on X11 along the edges of the monitor, if we had
overscan margins enabled.
The details are in the commit log of the last patch, but the main reason
was that moving along the edges with the overscan marg
During a commit, the core clock, which feeds the HVS, needs to run at
a minimum of 500MHz.
While doing that commit, we can also change the mode to one that
requires a higher core clock, so we take the core clock rate associated
to that new state into account for that boost.
However, the old state
Setting the DISPLISTx register needs to occur in every case, and we
don't need to protect the register using the event_lock, so we can just
move it after the if branches and simplify a bit the function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 9 +++--
1 file changed,
The assigned_channel field of our vc4_crtc_state structure is accessed
multiple times in vc4_hvs_atomic_flush, so let's move it to a variable
that can be used in all those places.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 9 +
1 file changed, 5 insertions(+), 4 del
In order to get the field currently being output, the driver has been
using the display FIFO frame count in the HVS, reading a 6-bit field at
the offset 12 in the DISPSTATx register.
While that field is indeed at that location for the FIFO 1 and 2, the
one for the FIFO0 is actually in the DISPSTAT
The vc4_hvs_update_dlist function mostly deals with setting up the
vblank events and setting up the dlist entry pointer to our current
active one.
We'll want to do the former separately from the vblank handling in later
patches, so let's move it to a function of its own.
Signed-off-by: Maxime Rip
atomic_flush will be called for each CRTC even if they aren't enabled.
The whole code we have there will thus run without a properly affected
channel, which can then result in all sorts of weird behaviour.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 3 +++
1 file changed, 3
Those macros are really about the HVS itself, and thus its associated
structure vc4_hvs, rather than the entire (virtual) vc4 device.
Let's change those macros to use the hvs pointer directly, and change
the calling sites accordingly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crt
During normal operations, the cursor position update is done through an
asynchronous plane update, which on the vc4 driver basically just
modifies the right dlist word to move the plane to the new coordinates.
However, when we have the overscan margins setup, we fall back to a
regular commit when
On 2022/2/21 17:19, Sergei Shtylyov wrote:
On 2/20/22 5:55 PM, Sui Jingfeng wrote:
From: suijingfeng
The display controller is a pci device, its PCI vendor id is 0x0014
its PCI device id is 0x7a06.
1) In order to let the driver to know which chip the DC is contained
in, the compatible
Hi Rob,
On Thu, Feb 10, 2022 at 06:54:13PM +0100, Lucas Stach wrote:
> Am Dienstag, dem 01.02.2022 um 11:35 -0600 schrieb Rob Herring:
> > On Fri, Jan 28, 2022 at 06:58:29PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote:
> > > > On Fri, Jan 28, 20
On 2022/2/21 18:01, Krzysztof Kozlowski wrote:
On 21/02/2022 10:19, Sergei Shtylyov wrote:
On 2/20/22 5:55 PM, Sui Jingfeng wrote:
From: suijingfeng
The display controller is a pci device, its PCI vendor id is 0x0014
its PCI device id is 0x7a06.
1) In order to let the driver to know which
On Mon, Feb 21, 2022 at 3:29 AM Eric Valette wrote:
>
> On 20/02/2022 16:48, Dominique Dumont wrote:
> > On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> >> Does the system actually suspend?
> >
> > Not really. The screens looks like it's going to suspend, but it does come
> > back a
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real n
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
Adds a bit of flexibility to support boards without CK/DE pol support
Signed-off-by: Guillaume Ranquet
s/board/SoC/g
After the change,
Reviewed-by: AngeloGioacchino Del Regno
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
Add flexibility by moving the dpi limits to the board config
s/board/SoC/g
After the change,
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Guillaume Ranquet
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not avai
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
Add flexibility by moving the dimension mask to the board config
s/board/SoC/g
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
dif
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
Add flexibility by moving the dimension mask to board config
You should really fix both title and description for this commit,
as this is moving hvsize_mask, not dimension_mask.
Also, s/board/SoC/g.
Signed-off-by: Guillaume Ranquet
---
driv
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
Add flexibility by moving the swap shift value to board config
Same board->SoC as all the other commits..
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
1 - 100 of 236 matches
Mail list logo
