[ Once again, quilt fails the MIME coding ]
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
[ Once again, quilt fails the MIME coding ]
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc:
Back in April, I posted an RFC patch set to help mitigate a common issue
where a timer gets armed just before it is freed, and when the timer
goes off, it crashes in the timer code without any evidence of who the
culprit was. I got side tracked and never finished up on that patch set.
Since this
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc:
Hi Linus,
This is the weekly fixes for rc4. Misc fixes across rockchip, imx,
amdgpu and i915. The biggest change is for amdkfd where the trap
handler needs an updated fw from a header which makes it a bit larger.
I hadn't noticed this particular file before so I'm going to figure
out what the
The driver is using gpiod API so it should include gpio/consumer.h and
not gpio.gh or of_gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
The driver has been switched to gpiod API, so it should include
gpio/consumer.h instead of gpio.h and of_gpio.h.
With of_gpio.h no longer included we need mod_devicetable.h for
of_device_id definition.
Signed-off-by: Dmitry Torokhov
---
With f048e8c1d169 ("omapfb: panel-lgphilips-lb035q02: Remove legacy boot
support") it is no longer possible to specify GPIO to control the
backlight. Remove code trying to request and toggle it.
Signed-off-by: Dmitry Torokhov
---
.../omapfb/displays/panel-lgphilips-lb035q02.c | 21
The driver does not use gpios, so there is no need to include gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
There are no users of panel_dpi_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++
include/video/omap-panel-data.h| 21
There are no users of connector_atv_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/connector-analog-tv.c| 60 +++---
include/video/omap-panel-data.h
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 ++
1 file changed, 16 insertions(+), 43
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 +++---
1 file changed, 22 insertions(+), 45
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++---
1 file changed, 14 insertions(+), 35
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
There are no users of panel_acx565akm_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 45 +++---
include/video/omap-panel-data.h
| 71 -
13 files changed, 170 insertions(+), 541 deletions(-)
---
base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd
change-id: 20221103-omapfb-gpiod-87ca2550bd90
--
Dmitry
No functional modification involved.
drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: expecting prototype for
Called whenever a 32-bit process running under a 64(). Prototype was for
nouveau_compat_ioctl() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2730
Reported-by:
Hello,
syzbot found the following issue on:
HEAD commit:b229b6ca5abb Merge tag 'perf-tools-fixes-for-v6.1-2022-10-..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14dddf5e88
kernel config: https://syzkaller.appspot.com/x/.config?x=a66c6c673fb555e8
On 11/3/22 5:56 PM, Alex Williamson wrote:
> On Wed, 2 Nov 2022 16:01:45 +0100
> Eric Farman wrote:
>
>> Hi all,
>>
>> Here is an update to the vfio-ccw lifecycle changes that have been discussed
>> in various forms over the past year [1][2] or so, and which I dusted off
>> recently.
>>
>>
On 11/2/22 11:01 AM, Eric Farman wrote:
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
>
> Signed-off-by: Eric
On 11/2/22 11:01 AM, Eric Farman wrote:
> Now that we have a reasonable separation of structs that follow
> the subchannel and mdev lifecycles, there's no reason we can't
> call the official vfio_alloc_device routine for our private data,
> and behave like everyone else.
>
> Signed-off-by: Eric
On 11/2/22 11:01 AM, Eric Farman wrote:
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
>
> Signed-off-by: Eric Farman
> Reviewed-by: Kevin Tian
Reviewed-by: Matthew Rosato
> ---
>
On 11/2/22 11:01 AM, Eric Farman wrote:
> Now that the mdev parent data is split out into its own struct,
> it is safe to move the remaining private data to follow the
> mdev probe/remove lifecycle. The mdev parent data will remain
> where it is, and follow the subchannel and the css driver
>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
include/drm/gpu_scheduler.h
between commit:
7b476affcccf ("drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flag")
from Linus' tree and commit:
4d5230b50dd4 ("drm/scheduler: add drm_sched_job_add_resv_dependencies")
On 11/2/22 11:01 AM, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will point
> to the private, for the
On 11/3/22 13:39, Oded Gabbay wrote:
> On Thu, Nov 3, 2022 at 3:31 PM Oded Gabbay wrote:
>>
>> On Thu, Nov 3, 2022 at 2:31 AM Greg Kroah-Hartman
>> wrote:
>>>
>>> On Wed, Nov 02, 2022 at 10:34:03PM +0200, Oded Gabbay wrote:
--- /dev/null
+++ b/drivers/accel/Kconfig
@@ -0,0
lays/panel-tpo-td028ttec1.c | 1 -
> .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++
> include/video/omap-panel-data.h| 71 -
> 13 files changed, 170 insertions(+), 541 deletions(-)
> ---
> base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd
> change-id: 20221103-omapfb-gpiod-87ca2550bd90
>
> --
> Dmitry
>
--
Dmitry
The driver does not use gpios, so there is no need to include gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
The driver is using gpiod API so it should include gpio/consumer.h and
not gpio.gh or of_gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
The driver is using gpiod API so it should include gpio/consumer.h and
not gpio.gh or of_gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
The driver has been switched to gpiod API, so it should include
gpio/consumer.h instead of gpio.h and of_gpio.h.
With of_gpio.h no longer included we need mod_devicetable.h for
of_device_id definition.
Signed-off-by: Dmitry Torokhov
---
There are no users of connector_atv_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/connector-analog-tv.c| 60 +++---
include/video/omap-panel-data.h
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
With f048e8c1d169 ("omapfb: panel-lgphilips-lb035q02: Remove legacy boot
support") it is no longer possible to specify GPIO to control the
backlight. Remove code trying to request and toggle it.
Signed-off-by: Dmitry Torokhov
---
.../omapfb/displays/panel-lgphilips-lb035q02.c | 21
There are no users of panel_dpi_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++
include/video/omap-panel-data.h| 21
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 ++
1 file changed, 16 insertions(+), 43
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 +++---
1 file changed, 22 insertions(+), 45
There are no users of panel_acx565akm_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 45 +++---
include/video/omap-panel-data.h
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++---
1 file changed, 14 insertions(+), 35
| 105 ++-
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++
include/video/omap-panel-data.h| 16 ---
7 files changed, 151 insertions(+), 333 deletions(-)
---
base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd
change-id: 20221103-omapfb
| 71 -
13 files changed, 170 insertions(+), 541 deletions(-)
---
base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd
change-id: 20221103-omapfb-gpiod-87ca2550bd90
--
Dmitry
On Thu, Nov 3, 2022 at 8:23 AM Mauro Carvalho Chehab
wrote:
>
> Hi,
>
> I'm facing a couple of issues when testing KUnit with the i915 driver.
>
> The DRM subsystem and the i915 driver has, for a long time, his own
> way to do unit tests, which seems to be added before KUnit.
>
> I'm now checking
On lunedì 17 ottobre 2022 11:37:19 CET Zhao Liu wrote:
> From: Zhao Liu
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
>
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
>
> In
Le mercredi 02 novembre 2022 à 12:18 +0100, Christian König a écrit :
> Am 01.11.22 um 22:09 schrieb Nicolas Dufresne:
> > [SNIP]
> > > > But the client is just a video player. It doesn't understand how to
> > > > allocate BOs for Panfrost or AMD or etnaviv. So without a universal
> > > >
On Wed, 2 Nov 2022 16:01:45 +0100
Eric Farman wrote:
> Hi all,
>
> Here is an update to the vfio-ccw lifecycle changes that have been discussed
> in various forms over the past year [1][2] or so, and which I dusted off
> recently.
>
> Patches 1-5 rework the behavior of the vfio-ccw driver's
On Thu, Nov 03, 2022 at 11:26:09AM +0800, Nancy.Lin wrote:
> Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
> the component exists in the path.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: CK Hu
> Tested-by: AngeloGioacchino Del
On Thu, Nov 03, 2022 at 11:26:05AM +0800, Nancy.Lin wrote:
[..]
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_ethdr.h
[..]
> +void mtk_ethdr_unregister_vblank_cb(struct device *dev);
> +void mtk_ethdr_enable_vblank(struct device *dev);
> +void mtk_ethdr_disable_vblank(struct device *dev);
>
On Thu, Nov 03, 2022 at 11:25:09AM +0800, Nancy.Lin wrote:
> Add mmsys for support 64 reset bits. It is a preparation for MT8195
> vdosys1 HW reset. MT8195 vdosys1 has more than 32 reset bits.
>
> 1. Add the number of reset bits in mmsys private data
> 2. move the whole "reset register code
On Thu, Nov 3, 2022 at 3:31 PM Oded Gabbay wrote:
>
> On Thu, Nov 3, 2022 at 2:31 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Nov 02, 2022 at 10:34:03PM +0200, Oded Gabbay wrote:
> > > --- /dev/null
> > > +++ b/drivers/accel/Kconfig
> > > @@ -0,0 +1,24 @@
> > > +# SPDX-License-Identifier:
On Thu, Nov 03, 2022 at 11:25:06AM +0800, Nancy.Lin wrote:
[..]
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
[..]
> +static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32 offset, u32
> mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp =
On Thu, Nov 03, 2022 at 11:25:07AM +0800, Nancy.Lin wrote:
> Add four mmsys config APIs. The config APIs are used for config
> mmsys reg. Some mmsys regs need to be set according to the
> HW engine binding to the mmsys simultaneously.
>
> 1. mtk_mmsys_merge_async_config: config merge async
On Thu, Nov 03, 2022 at 11:25:02AM +0800, Nancy.Lin wrote:
> Add vdosys1 mmsys compatible for MT8195 platform.
>
> For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
> 2 different power domains, different clock drivers and different
> mediatek-drm drivers.
>
> Signed-off-by:
On 11/3/2022 03:45, Jani Nikula wrote:
On Wed, 02 Nov 2022, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop caches
On 11/3/2022 02:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop caches
On giovedì 3 novembre 2022 17:51:23 CET Ira Weiny wrote:
> On Sat, Oct 29, 2022 at 01:17:03PM +0200, Fabio M. De Francesco wrote:
> > On lunedì 17 ottobre 2022 11:37:17 CEST Zhao Liu wrote:
> > > From: Zhao Liu
> > >
> > > The use of kmap_atomic() is being deprecated in favor of
> > >
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the
On Mon, Oct 17, 2022 at 05:37:23PM +0800, Zhao Liu wrote:
> From: Zhao Liu
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
>
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
>
> In
On Mon, Oct 31, 2022 at 03:00:07PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Some of the GuC state dump messages were adding extra line feeds. When
printing via a DRM printer to dmesg, for example, that messes up the
log formatting as it loses any prefixing from the printer.
On 11/3/22 18:27, Jagan Teki wrote:
On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut wrote:
On 11/3/22 10:39, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
[...]
@@ -1321,6 +1322,32 @@ static void
On Thu, Nov 03, 2022 at 11:45:57AM -0700, John Harrison wrote:
On 11/3/2022 04:31, Tvrtko Ursulin wrote:
On 02/11/2022 19:21, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The
On 11/3/2022 04:31, Tvrtko Ursulin wrote:
On 02/11/2022 19:21, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to
DM maps DRM CRTC degamma to DPP (pre-blending) degamma block, but DCE doesn't
support programmable degamma curve anywhere. Currently, a custom degamma is
accepted by DM but just ignored by DCE driver and degamma correction isn't
actually applied. There is no way to map custom degamma in DCE,
This workaround is added for Media tile of MTL A step. It is to help
pcode workaround which handles the hardware issue seen during package C2/C3
transitions due to RC6 entry/exit transitions on Media tile. As a part of
workaround pcode expect kmd to send mailbox message "media busy" when
On Thu, Nov 03, 2022 at 02:22:21PM -0400, Sean Anderson wrote:
> There is a common case where component_patch_add_release is called with
> component_release_of/component_compare_of and a device node. Add a
> helper and convert existing users.
The usual pattern here would be to split adding the
On 11/3/22 17:26, Randy Dunlap wrote:
[...]
>>
>> Randy, I think that it's more idiomatic though to it express as following:
>>
>> depends on DRM_RCAR_MIPI_DSI || !DRM_RCAR_MIPI_DSI
>
> I count just over 200 of each idiom (but my grep strings could be
> too crude). I guess that you want a v2
Every user of this function either uses component_compare_of or
something equivalent. Most of them immediately put the device node as
well. Convert these users to component_match_add_of and remove
drm_of_component_match_add.
Signed-off-by: Sean Anderson
---
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
drm_of_component_match_add, which allows for a custom compare function.
However, all existing users just
There is a common case where component_patch_add_release is called with
component_release_of/component_compare_of and a device node. Add a
helper and convert existing users.
Signed-off-by: Sean Anderson
---
drivers/iommu/mtk_iommu.c| 3 +--
drivers/iommu/mtk_iommu_v1.c | 3 +--
On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut wrote:
>
> On 11/3/22 10:39, Jagan Teki wrote:
> > On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote:
> >>
> >> On 10/5/22 17:13, Jagan Teki wrote:
> >>
> >> [...]
> >>
> >>> @@ -1321,6 +1322,32 @@ static void
> >>>
On Sat, Oct 29, 2022 at 01:17:03PM +0200, Fabio M. De Francesco wrote:
> On lunedì 17 ottobre 2022 11:37:17 CEST Zhao Liu wrote:
> > From: Zhao Liu
> >
> > The use of kmap_atomic() is being deprecated in favor of
> > kmap_local_page()[1].
> >
> > The main difference between atomic and local
On Mon, Oct 17, 2022 at 05:37:19PM +0800, Zhao Liu wrote:
> From: Zhao Liu
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
>
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
>
> In
Hi,
On 11/3/22 04:53, Javier Martinez Canillas wrote:
> Hello Kieran,
>
> On 11/3/22 11:59, Kieran Bingham wrote:
>> Hi Randy,
>>
>> Quoting Randy Dunlap (2022-11-03 06:06:45)
>>> ping. I have verified (on linux-next-20221103) that this is still needed.
&
On 11/3/22 08:40, Jagan Teki wrote:
On Mon, Oct 17, 2022 at 12:54 PM Marek Vasut wrote:
On 10/17/22 05:58, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
[...]
@@ -1321,6 +1322,32 @@ static void
On 11/3/22 10:39, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
[...]
@@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
}
+#define
On 03/11/2022 05:12, allen wrote:
> From: allen chen
>
> Currently there are no "upstream" users. So, no existing users to break.
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
Reviewed-by: Krzysztof Kozlowski
Best
Don't populate the read-only array en_di on the stack but instead
make it static. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/sti/sti_hdmi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
On 03/11/2022 11:17, Guillaume Ranquet wrote:
> On Thu, 03 Nov 2022 13:45, Krzysztof Kozlowski
>>> This is an i2c adapter, not a device.
>>> And as it lives inside the HDMI hw block, I've omitted using an address
>>> here.
>>>
>>> Is this valid? or should this be expressed differently?
>>
>> What
Hi,
I'm facing a couple of issues when testing KUnit with the i915 driver.
The DRM subsystem and the i915 driver has, for a long time, his own
way to do unit tests, which seems to be added before KUnit.
I'm now checking if it is worth start using KUnit at i915. So, I wrote
a RFC with some
The fbdev helpers implement a damage worker that forwards fbdev
updates to the DRM driver. The worker's update logic depends on
the generic fbdev emulation. Separate the two via function pointer.
The generic fbdev emulation sets struct drm_fb_helper_funcs.fb_dirty,
a new callback that hides the
On Thu, 03 Nov 2022 13:45, Krzysztof Kozlowski
wrote:
>On 02/11/2022 09:31, Guillaume Ranquet wrote:
>> On Fri, 14 Oct 2022 18:08, Krzysztof Kozlowski
>> wrote:
>>> On 14/10/2022 11:15, Guillaume Ranquet wrote:
Add mt8195 SoC bindings for hdmi and hdmi-ddc
Signed-off-by: Guillaume
Implement the fbdev's read/write helpers with the same functions. Use
the generic fbdev's code as template. Convert all drivers.
DRM's fb helpers must implement regular I/O functionality in struct
fb_ops and possibly perform a damage update. Handle all this in the
same functions and convert
Clarify documentation in the use of struct drm_driver.last_close and
struct drm_mode_config_funcs.output_poll_changed. Those callbacks should
not be said for fbdev implementations on top of struct drm_client_funcs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 6 --
Only include what we have to.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
include/drm/drm_fb_helper.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index
Include for devm_of_find_backlight().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
Uncouple the parameter drm_leak_fbdev_smem from the implementation by
setting a flag in struct drm_fb_helper. This will help to move the
generic fbdev emulation into its own source file, while keeping the
parameter in drm_fb_helper.c. No functional changes.
Signed-off-by: Thomas Zimmermann
---
Rename struct drm_fb_helper.fbdev to info. The current name is
misleading as it overlaps with generic fbdev naming conventions.
Adapt to the usual naming in fbdev drivers by calling the field
'info'. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as
part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
Initialize the generic fbdev emulation even if it has been disabled
on the kernel command line. The hotplug and mode initialization will
fail accordingly.
The kernel parameter can still be changed at runtime and the emulation
will initialize after hotplugging the connector.
Signed-off-by: Thomas
Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the
behavior of fbdev. Fbdev implementations of fb_read and fb_write in
struct fb_ops invoke fb_sync to synchronize with outstanding operations
before I/O. Doing the same in DRM implementations will allow us to use
them throughout DRM
Remove include statements for where it is not
required (i.e., most of them). In a few places include other header
files that are required by the source code.
v3:
* fix amdgpu include statements
* fix rockchip include statements
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Move the generic fbdev implementation into its own source and header
file. Adapt drivers. No functional changes, but some of the internal
helpers have been renamed to fit into the drm_fbdev_ naming scheme.
v3:
* rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h}
* rebase onto
Pull the test for fb_dirty into the caller to avoid extra work
if no callback has been set. In this case no damage handling is
required and no damage area needs to be computed. Print a warning
if the damage worker runs without getting an fb_dirty callback.
Signed-off-by: Thomas Zimmermann
Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info()
as part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
1 - 100 of 172 matches
Mail list logo
