If the device is already in a runtime PM enabled state
pm_runtime_get_sync() will return 1, so a test for negative
value should be used to check for errors.
Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
1 file changed, 1 ins
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-devel@lists.freedesktop.org
Cc: nouv
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
From: Thomas Zimmermann
commit 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 upstream.
OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
>
> But a
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
> add to the schema the properties and examples for OLED devices under SPI.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Mark Brown
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The current compatible strings for SSD130x I2C controllers contain an "fb"
> and "-i2c" suffixes. These have been deprecated and more correct ones were
> added, that don't encode a subsystem or bus used to interface the
From: Thomas Zimmermann
commit 0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 upstream.
OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-devel@lists.freedesktop.org
Cc: nouv
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote:
> > Reviewed-by: George Shen
> > Acked-by: Alex Hung
> > Signed-off-by: Martin Leung
>
> Shouldn’t the Signed-off-by line by the author go first?
No, this is the correct order.
thanks,
greg k-h
Hi Javier,
Thanks for your patch!
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> These are declared in the ssd130x-i2c transport driver but the information
> is not I2C specific, and could be used by other SSD130x transport drivers.
>
> Move them to the ssd130x core driver an
D130x-OLED-displays-SPI-support/20220412-051518
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a001-20220411
(https://download.01.org/0day-ci/archive/20220412/202204121542.au2biyxn-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/ll
-base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
base:d12d7e1cfe38e0c36d28c7a9fbbc436ad0d17c14
config: i386-randc
-base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Osipenko/Add-generic-memory-shrinker-to-VirtIO-GPU-and-Panfrost-DRM-drivers/20220412-060325
base:d12d7e1cfe38e0c36d28c7a9fbbc436ad0d17c14
config: hexagon-randc
Hi Javier,
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over SPI.
>
> There is a difference in the communication protocol when using
On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> this is DRI state when there is no any Qt.vars overwrites.
> (so all is autodetected/setup like in other working SoCs; VOP2 gives here
> black screen UI):
>
> 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:
Hello Geert,
On 4/12/22 09:16, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
>> add to the schema the properties and examples for OLED devices under SPI.
On 4/12/22 09:19, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> The current compatible strings for SSD130x I2C controllers contain an "fb"
>> and "-i2c" suffixes. These have been deprecated and more correct ones were
>> added, tha
On 4/12/22 09:23, Geert Uytterhoeven wrote:
> Hi Javier,
>
> Thanks for your patch!
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> These are declared in the ssd130x-i2c transport driver but the information
>> is not I2C specific, and could be used by other SSD130x tran
Hi Javier,
On Tue, Apr 12, 2022 at 10:01 AM Javier Martinez Canillas
wrote:
> On 4/12/22 09:16, Geert Uytterhoeven wrote:
> > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > wrote:
> >> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
> >> add to the schem
On 4/12/22 09:31, Geert Uytterhoeven wrote:
[snip]
>> +
>> + t->spi = spi;
>> +
>> + t->dc = ssd130x_spi_get_dc(&spi->dev);
>> + if (IS_ERR(t->dc))
>> + return PTR_ERR(t->dc);
>
> This can be simplified (no need for the PTR_ERR(ERR_PTR(...) dance)
> by open-coding
Am Dienstag, dem 12.04.2022 um 09:50 +0200 schrieb Sascha Hauer:
> On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> > this is DRI state when there is no any Qt.vars overwrites.
> > (so all is autodetected/setup like in other working SoCs; VOP2 gives here
> > black screen UI):
>
On 4/12/22 10:07, Geert Uytterhoeven wrote:
> Hi Javier,
[snip]
>>
>> Do you have any hints here on how I should enforce this in the schema ?
>>
>> Or if you think that a comment is enough, then I will add it in v3.
>
> I don't know how to make it required for SPI, if possible at all.
>
I see.
Hi Javier,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220412]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next tegra-drm/drm/tegra/for-next linus/master linux/master
airlied
On Mon, 11 Apr 2022 at 19:51, Arunpravin Paneer Selvam
wrote:
>
> Add a set of drm buddy test cases to validate the
> drm/drm_buddy.c memory allocator.
>
> v2: sorted in alphabetical order
>
> Signed-off-by: Arunpravin Paneer Selvam
> Reviewed-by: Matthew Auld
Tests look to be passing in CI sha
On Tue, Apr 12, 2022 at 3:48 AM James Hilliard
wrote:
>
> On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson
> wrote:
> >
> > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard
> > wrote:
> > >
> > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson
> > > wrote:
> > > >
> > > > On Sun, Apr 10, 2022 a
On Mon, 28 Mar 2022 10:04, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> Signed-off-by: Guillaume Ranquet
>> ---
>> include/drm/drm_edid.h | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/drm/drm_edid.h b/i
On Mon, 28 Mar 2022 10:09, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, 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
On Mon, 28 Mar 2022 10:20, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> From: Markus Schneider-Pargmann
>>
>> This is a new driver that supports the integrated DisplayPort phy for
>> mediatek SoCs, especially the mt8195. The phy is integrated into the
>>
On Mon, 28 Mar 2022 10:38, Rex-BC Chen wrote:
>Hello Guillaume,
>
>Thanks for your patch, but I have some questions for this patch:
>
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> dpintf is the displayport interface hardware unit. This unit is
>> similar
>> to dpi and can reuse m
On Tue, 29 Mar 2022 05:16, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, 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. Mai
The IS_ERR_OR_NULL() check in vmw_translate_mob_ptr() should just be
an IS_ERR() check.
The NULL check is confusing because vmw_user_bo_noref_lookup() can never
return NULL. A NULL return here would only lead to bugs and crashing.
For example, Smatch complains that it would lead to an uninitializ
Hi Zack,
Reviewed-by: Christian König for the entire
series.
One nit pick is that I want to get rid of using ttm_manager_type() in
drivers and use pointers to the members directly. But that's something
for a later cleanup anyway.
Thanks,
Christian.
Am 12.04.22 um 05:35 schrieb Zack Rusin
deobuf2_dma_contig lcdif crct10dif_ce
phy_fsl_samsung_hdmi v4l2_mem2mem imx_sdma flexcan imx8mm_thermal can_dev caam
error pwm_fan fuse ipv6
CPU: 2 PID: 151 Comm: kworker/u8:7 Not tainted 5.18.0-rc2-next-20220412+ #165
d226098cac46ded24901c7090f909ca8f5098eb0
Hardware name: TQ
> Wiadomość napisana przez Sascha Hauer w dniu
> 12.04.2022, o godz. 09:50:
>
>
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application sho
On Mon, 28 Mar 2022 10:49, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> Add a mtk_dpi_matrix_sel() helper to update the DPI_MATRIX_SET
>> register depending on the color format.
>>
>> Signed-off-by: Guillaume Ranquet
>> ---
>> drivers/gpu/drm/mediatek/mtk_dp
_atomic_helper.c:1529
> drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc
> Modules linked in: caamhash_desc caamalg_desc crypto_engine rng_core mcp320x
> dw_hdmi_cec authenc libdes dw100 videobuf2_dma_contig lcdif crct10dif_ce
> phy_fsl_samsung_hdmi v4l2_mem2mem imx_sdma flexcan imx8
Hi Jagan,
On 08.04.2022 18:20, Jagan Teki wrote:
> Samsung MIPI DSIM controller is common DSI IP that can be used in various
> SoCs like Exynos, i.MX8M Mini/Nano.
>
> In order to access this DSI controller between various platform SoCs, the
> ideal way to incorporate this in the drm stack is via t
On Mon, 28 Mar 2022 11:14, AngeloGioacchino Del Regno
wrote:
>Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It supports the mt8195, the embedded DisplayPort units. It offers
>> Disp
On Tue, 29 Mar 2022 05:34, Rex-BC Chen wrote:
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It supports the mt8195, the embedded DisplayPort units. It offers
>> DisplayP
On 08.04.2022 18:20, Jagan Teki wrote:
> In order to make a common Samsung DSIM bridge driver some platform specific
> glue code needs to maintain separately as it is hard to maintain platform
> specific glue and conventional component_ops on the drm bridge drivers side.
>
> This patch is trying
Hi Samuel,
I love your patch! Yet something to improve:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on drm/drm-next linus/master v5.18-rc2 next-20220412]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Hi Biju,
On Wed, Mar 16, 2022 at 2:11 PM Biju Das wrote:
> Extend the Renesas DU display bindings to support the r9a07g044l
> DU module found on RZ/G2L LCDC.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> +++ b/Documentati
On Tue, 29 Mar 2022 07:41, Rex-BC Chen wrote:
>Hello Guillaume,
>
>Thanks for your patch.
>I add some comments below:
>
>On Mon, 2022-03-28 at 00:39 +0200, Guillaume Ranquet wrote:
>> From: Markus Schneider-Pargmann
>>
>> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>>
>> It
On Wed, 30 Mar 2022 00:58, Rob Herring wrote:
>On Mon, Mar 28, 2022 at 12:39:08AM +0200, Guillaume Ranquet wrote:
>> This phy controller is embedded in the Display Port Controller on mt8195
>> SoCs.
>
>Sorry, but I think you need to go back to what you had in v8. While yes,
>the phy and controlle
> Wiadomość napisana przez Lucas Stach w dniu
> 12.04.2022, o godz. 10:10:
>
> This could be both a Mesa/Panfrost or application issue. The
> application is supposed to try to allocate with a arbitrary chosen
> format and the valid modifiers queried from the plane it wants to put
> the surfac
On 2022-04-11 15:44, Karol Herbst wrote:
> commit 7938f4218168 ("dma-buf-map: Rename to iosys-map") already renamed
> this file, but it got brought back by a merge.
>
> Delete it for real this time.
>
> Fixes: 30424ebae8df ("Merge tag 'drm-intel-gt-next-2022-02-17' of
> git://anongit.freedesktop
Hi Geert,
Thanks for the feedback
> Subject: Re: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document
> r9a07g044l bindings
>
> Hi Biju,
>
> On Wed, Mar 16, 2022 at 2:11 PM Biju Das
> wrote:
> > Extend the Renesas DU display bindings to support the r9a07g044l DU
> > module found on RZ/G2L
On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
> On 4/12/22 09:23, Geert Uytterhoeven wrote:
> > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > wrote:
...
> >> - ssd130x->device_info = device_get_match_data(dev);
> >> +
> >> + variant = (enum
On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
> > On 4/12/22 09:23, Geert Uytterhoeven wrote:
> > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > > wrote:
...
> > >> - ssd130x->de
On Mon, Apr 11, 2022 at 11:12:39PM +0200, Javier Martinez Canillas wrote:
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
>
On Tue, 12 Apr 2022 at 11:14, Piotr Oniszczuk wrote:
> > Wiadomość napisana przez Lucas Stach w dniu
> > 12.04.2022, o godz. 10:10:
> > 1. The application feeds a wrong modifier list to the GBM
> > implementation, as it may have queried another plane in the assumption
> > that supported modifier
On Tue, Apr 12, 2022 at 5:12 AM Javier Martinez Canillas
wrote:
>
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
>
> But
On 11/04/2022 13:39, Christian König wrote:
Am 11.04.22 um 10:56 schrieb Matthew Auld:
If we hit the sync case, like when skipping clearing for kernel internal
objects, or when falling back to cpu clearing, like in i915, we end up
trying to add a NULL fence, but with some recent changes in this
Dear All,
On 07.04.2022 13:24, Marek Szyprowski wrote:
> On 31.03.2022 16:22, Robert Foss wrote:
>> On Fri, 25 Mar 2022 at 17:04, Adam Ford wrote:
>>> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski
>>> wrote:
On 03.03.2022 17:36, Jagan Teki wrote:
> Updated series about drm bridge co
Hello Andy,
Thanks for your feedback.
On 4/12/22 13:21, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
>> On 4/12/22 09:23, Geert Uytterhoeven wrote:
>>> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
>>> wrote:
>
> ...
>
-
On 4/12/22 13:22, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote:
>> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
>>> On 4/12/22 09:23, Geert Uytterhoeven wrote:
On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
>>>
Hello Maxime,
On 4/12/22 13:28, Maxime Ripard wrote:
> On Mon, Apr 11, 2022 at 11:12:39PM +0200, Javier Martinez Canillas wrote:
[snip]
>>
>>reg:
>> maxItems: 1
>> @@ -136,7 +147,7 @@ allOf:
>>properties:
>> compatible:
>>contains:
>> -const: s
Hello Chen-Yu,
On 4/12/22 14:07, Chen-Yu Tsai wrote:
> On Tue, Apr 12, 2022 at 5:12 AM Javier Martinez Canillas
> wrote:
[snip]
>
> I think you can just drop this one, since it was just merged and isn't
> part of any release yet. It's not even in -rc.
>
I believe you are correct and we could
On Mon, Apr 11, 2022 at 08:47:30PM +, Sean Paul wrote:
> From: Sean Paul
>
> This patch moves the hdcp atomic check from i915 to drm_hdcp so other
> drivers can use it. No functional changes, just cleaned up some of the
> code when moving it over.
Reviewed-by: Rodrigo Vivi
>
> Acked-by:
On Mon, Apr 11, 2022 at 08:47:31PM +, Sean Paul wrote:
> From: Sean Paul
>
> Instead of forcing a modeset in the hdcp atomic check, simply return
> true if the content protection value is changing and let the driver
> decide whether a modeset is required or not.
>
> Acked-by: Jani Nikula
>
Hi,
On Mon, Apr 11, 2022 at 11:35:08PM -0500, Samuel Holland wrote:
> Now that the HDMI PHY is using a platform driver, it can use device-
> managed resources. Use these, as well as the dev_err_probe helper, to
> simplify the probe function and get rid of the remove function.
>
> Signed-off-by: S
On Mon, Apr 11, 2022 at 08:47:32PM +, Sean Paul wrote:
> From: Sean Paul
>
> This patch updates the connector's property value in 2 cases which were
> previously missed:
>
> 1- Content type changes. The value should revert back to DESIRED from
>ENABLED in case the driver must re-authenti
On Mon, Apr 11, 2022 at 08:47:35PM +, Sean Paul wrote:
> From: Sean Paul
>
> The shim functions return error codes, but they are discarded in
> intel_hdcp.c. This patch plumbs the return codes through so they are
> properly handled.
Reviewed-by: Rodrigo Vivi
>
> Acked-by: Jani Nikula
> S
On Mon, Apr 11, 2022 at 08:47:34PM +, Sean Paul wrote:
> From: Sean Paul
>
> Stick all of the setup for HDCP into a dedicated function. No functional
> change, but this will facilitate moving HDCP logic into helpers.
Reviewed-by: Rodrigo Vivi
>
> Acked-by: Jani Nikula
> Signed-off-by:
On Mon, Apr 11, 2022 at 08:47:29PM +, Sean Paul wrote:
> From: Sean Paul
>
> Rebased set from November. Fixed a nit from Stephen in the msm patch and
> moved hdcp registers into the trogdor dtsi file to avoid differences
> with sc7180-based windows devices. The set is 4 patches lighter since
On Tue, Apr 12, 2022 at 3:42 AM James Hilliard
wrote:
>
> Extracted from various sources such EMGD releases.
>
> Signed-off-by: James Hilliard
Hi James,
These registers are documented in the Intel 965/G35 and G45
documentation [1]. I don't see a clear benefit of duplicating the
names of the regi
Hi,
On 14/03/2022 13:37, Devarsh Thakkar wrote:
Soft reset the display subsystem controller on startup and wait for
the reset to complete. This helps the scenario where display was
already in use by some other core before the linux was booted.
The reason the omapdrm doesn't do a reset is that
Le lundi 11 avril 2022 à 11:41 +0800, yunfei.d...@mediatek.com a écrit :
> Hi Nicolas,
>
> On Thu, 2022-03-31 at 16:48 -0400, Nicolas Dufresne wrote:
> > Hi Yunfei,
> >
> > thanks for the update, I should be testing this really soon.
> >
> > Le jeudi 31 mars 2022 à 10:47 +0800, Yunfei Dong a écr
On Wed, Apr 6, 2022 at 1:31 PM Xiaomeng Tong wrote:
>
> Instead of exiting the loop as expected when an entry is found, the
> list_for_each_entry() continues until the traversal is complete. To
> avoid potential executing 'ret = gma_backlight_init(dev);' repeatly,
> goto outside the loop when the
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
video/display output, Intel Alder Lake based systems will hang during
suspend
This series refactors i915's stolen memory region to use ttm.
v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes
testing
dmesg warning regressions.
Robert Beckett (5):
drm/i915: instantiate ttm range
stolen regions are not page backed or considered iomem.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_mo
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++-
2 files changed, 27 insertio
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specif
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/driver
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd
From: Bas Nieuwenhuizen
[ Upstream commit 021830d24ba55a578f602979274965344c8e6284 ]
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Ai
On Tue, Apr 12, 2022 at 2:52 AM Paul Menzel wrote:
>
> [Cc: +dri-devel@lists.freedesktop.org, +Daniel Vetter, +Alexander
> Deucher, +Greg KH]
>
>
> Dear Alex,
>
>
> I am a little confused and upset about how Display Core patches are
> handled in the Linux kernel.
>
>
> Am 25.03.22 um 23:53 schrieb
On Tue, Apr 12, 2022 at 10:59 AM Richard Gong wrote:
>
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that won't work
> with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
> video/display
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the vfio_device pointer
vfio_mdev.c puts in the drv_data.
Sign
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
---
.../drive
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
---
drivers/g
Nothing references this struct member any more, delete it completely.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
inde
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 44 +++--
drivers/s390/cio/vfio_ccw_cp.h | 4 +--
drivers
try_module_get() must be undone if kvmgt_guest_init() fails or we leak the
module reference count on the failure path since the close_device op is
never called in this case.
Fixes: 9bdb073464d6 ("drm/i915/gvt: Change KVMGT as self load module")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/
When the open_device() op is called the container_users is incremented and
held incremented until close_device(). Thus, so long as drivers call
functions within their open_device()/close_device() region they do not
need to worry about the container_users.
These functions can all only be called bet
Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
reason to use a group interface here, kvmgt has easy access to a
vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
Now that callers have been updated to use the vfio_device APIs the driver
facing group interface is no longer used, delete it:
- vfio_group_get_external_user_from_dev()
- vfio_group_pin_pages()
- vfio_group_unpin_pages()
- vfio_group_iommu_domain()
Signed-off-by: Jason Gunthorpe
---
drivers/vfi
Prior series have transformed other parts of VFIO from working on struct
device or struct vfio_group into working directly on struct
vfio_device. Based on that work we now have vfio_device's readily
available in all the drivers.
Update the rest of the driver facing API to use vfio_device as an inp
Hello,
This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
support for SSD130x OLED controllers that can be accessed over a SPI bus.
The driver is quite similar to existing ssd130x-i2c driver that is used by
I2C controllers, but there is a difference in the protocol used by
The current compatible strings for SSD130x I2C controllers contain both an
"fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
and also that are for devices that can be accessed over an I2C bus.
But a DT is supposed to describe the hardware and not Linux implementation
detai
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Add a comment to the properties
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-b
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific, and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that could be used to lookup the correct device info from an array.
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI
instead of I2C. For the latter, a control byte that contains a D/C# field
On 2022-04-11 18:15, Dmitry Osipenko wrote:
Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
mutex when job is released, and thus, that code can sleep. This results
into "BUG: scheduling while atomic" if locks are contented while job is
freed. There is no good reason for
1 - 100 of 146 matches
Mail list logo
