On Thu, Sep 23, 2021 at 12:22 PM Oded Gabbay wrote:
>
> On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote:
> >
> > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote:
> > >
> > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote:
> > > > On Thu, Sep 16, 2021 at 02:31:34PM +0200,
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> Now that SCM can be a loadable module, we have to add another
> dependency to avoid link failures when ipa or adreno-gpu are
> built-in:
>
> aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
> ipa_main.c:(.text+0xfc4): undefine
On Tue, Sep 28, 2021 at 9:05 AM Kalle Valo wrote:
> Arnd Bergmann writes:
> > From: Arnd Bergmann
> I assume I can continue to build test ATH10K_SNOC with x86 as before?
> That's important for me. If yes, then:
>
> Acked-by: Kalle Valo
>
> --
> https://patchwork.kernel.org/project/linux-wireles
From: Joel Stanley
The values for the threshold and scan line size come from the ASPEED
SDK.
The DAC register is SCUC0 in the AST2600 datasheet. It has the same
layout as the previous generations.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx_dr
From: Joel Stanley
The 2600 uses this register differently. THis is a TODO to come up with
a method of handling that.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/driver
Both hardware and driver can communicate DDC over i2c bus.
Fixes warnings as:
arch/arm/boot/dts/tegra20-paz00.dt.yaml: panel: 'ddc-i2c-bus' does not match
any of the regexes: 'pinctrl-[0-9]+'
From schema:
/home/runner/work/linux/linux/Documentation/devicetree/bindings/display/panel/panel
From: Joel Stanley
The GFX device is present in the AST2600 SoC.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
ind
From: Joel Stanley
The AST2600 will run at 1024x868.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed
Add ast2600-gfx description for gfx driver.
Signed-off-by: tommy-huang
---
Documentation/devicetree/bindings/gpu/aspeed-gfx.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
b/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
index 9
Add AST2600 GFX support first.
Joel Stanley (5):
ARM: dts: aspeed: Add GFX node to AST2600
ARM: dts: aspeed: ast2600-evb: Enable GFX device
drm/aspeed: Add AST2600 support
HACK: drm/aspeed: INTR_STS hadndling
HACK: drm/aspeed: Paramterise modes
tommy-huang (1):
dt-bindings: gpu: Add A
From: Joel Stanley
Enable the GFX device with a framebuffer memory region.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
b/arch/ar
On Sat, Sep 25, 2021 at 03:47:00PM +0200, Greg Kroah-Hartman wrote:
> In order to better track where in the kernel the dma-buf code is used,
> put the symbols in the namespace DMA_BUF and modify all users of the
> symbols to properly import the namespace to not break the build at the
> same time.
>
Hey guys:
After some investigation, I found the root cause this problem ("i915"
module loading will be stuck with Christoph's refactor patches), which
can be reproduced by building both i915 and kvmgt as kernel module and
the loading i915.
The root cause is: in Linux kernel loading, before a k
Hi Dave,
Just one clean up to use helper function.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:
Linux 5.15-rc1 (2021-09-12 16:28:37 -0700)
are available in the Git repository at:
git://
On Tue, Sep 28, 2021 at 09:31:45AM +0200, Daniel Vetter wrote:
> On Sat, Sep 25, 2021 at 03:47:00PM +0200, Greg Kroah-Hartman wrote:
> > In order to better track where in the kernel the dma-buf code is used,
> > put the symbols in the namespace DMA_BUF and modify all users of the
> > symbols to pro
From: Arnd Bergmann
Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'
On Mon, 27 Sep 2021 07:36:05 -0700
Rob Clark wrote:
> On Mon, Sep 27, 2021 at 1:42 AM Pekka Paalanen wrote:
> >
> > On Fri, 3 Sep 2021 11:47:59 -0700
> > Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > The initial purpose is for igt tests, but this would also be useful for
> > > comp
Hi Daniel,
On Sat, Sep 25, 2021 at 12:50:17AM +0200, Daniel Vetter wrote:
> On Fri, Sep 24, 2021 at 3:30 PM Maxime Ripard wrote:
> >
> > On Wed, Sep 22, 2021 at 01:25:21PM -0700, Linus Torvalds wrote:
> > > On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee
> > > wrote:
> > > >
> > > > I added some
Convert upcasts from struct drm_gem_object to struct gtt_range to
to_gtt_range(). Some places used container_of() directly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c | 4 ++--
drivers/gpu/drm/gma500/gma_display.c | 7 +++
2 files changed, 5 insertions(+), 6 de
Support private objects for stolen memory in psb_gem_create() and
convert users to psb_gem_create(). For stolen memory, psb_gem_create()
now initializes the GEM object via drm_gem_private_object_init().
In the fbdev setup, replace the open-coded initialization of struct
gtt_range with a call to ps
Allocation and pinning helpers for struct gtt_range are GEM functions,
so move them to gem.c. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 1 -
drivers/gpu/drm/gma500/gem.c | 133 +--
drivers/gpu/drm/gma500/g
Bring GEM code up to current standards and untangle the connection to
GTT helpers.
The allocation and pinning helpers for struct gtt_range are located in
the GTT code, but actually part of the GEM implementation. The patchset
moves them to GEM code and refactors much of the implementation. Most
of
struct gtt_range represents a GEM object and should not be used for GTT
setup. Change psb_gtt_insert() and psb_gtt_remove() to receive all
necessary parameters from their caller. This also eliminates possible
failure from psb_gtt_insert().
There's one exception in psb_gtt_restore(), which requires
Caching of the GEM object's backing pages are unrelated to GTT
management. Move the respective calls from GTT code to GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c | 9 -
drivers/gpu/drm/gma500/gtt.c | 17 ++---
drivers/gpu/drm/gma500/gtt.h | 2
Rename psb_gtt_pin() to psb_gem_pin() to reflect the semantics of the
function. Same for psb_gtt_unpin(). No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c | 8
drivers/gpu/drm/gma500/gem.h | 4 ++--
drivers/gpu/drm/gma500/gma_dis
psb_gtt_attach_pages() are not GTT functions but deal with the GEM
object's SHMEM pages. The only callers of psb_gtt_attach_pages() and
psb_gtt_detach_pages() are the GEM pin helpers. Inline the calls and
cleanup the resulting code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem
Implement psb_gem_create() for general use. Create the GEM handle in
psb_gem_create_dumb(). Allows to use psb_gem_create() for creating all
of the GEM objects.
While at it, clean-up drm_gem_dumb_create() to make it more readable.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c
psb_gtt_alloc_range() allocates struct gtt_range, create the GTT resource
and performs some half-baked initialization. Inline the function into its
only caller psb_gem_create(). For creating the GTT resource, introduce a
new helper, psb_gtt_alloc_resource() that hides the details of the GTT.
For p
struct gtt_range represents a GEM object. Rename the structure to struct
psb_gem_object and update all users. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 9 +-
drivers/gpu/drm/gma500/gem.c | 106 +++--
d
Hi Laurent,
On Mon, Aug 23, 2021 at 4:54 PM Laurent Pinchart
wrote:
> On Mon, Aug 23, 2021 at 02:25:32PM +0200, Geert Uytterhoeven wrote:
> > On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart wrote:
> > > On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> > > even when LVDS
Hi,
> Am 27.09.2021 um 19:07 schrieb max...@cerno.tech:
>
> Hi,
>
> On Mon, Sep 27, 2021 at 06:44:21PM +0200, H. Nikolaus Schaller wrote:
>> From: Sam Ravnborg
>>
>> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
>> Based on .txt binding from Zubair Lutfullah Kakakhel
>>
>> S
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge i
Arnd Bergmann wrote:
> gcc-11 with the kernel address sanitizer prints a warning for this
> driver:
>
> In function 'ath11k_peer_assoc_h_vht',
> inlined from 'ath11k_peer_assoc_prepare' at
> drivers/net/wireless/ath/ath11k/mac.c:1632:2:
> drivers/net/wireless/ath/ath11k/mac.c:1164:13: error
On 9/28/21 10:55 AM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxs
On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote:
> >> +properties:
> >> + compatible:
> >> +items:
> >> + - const: ingenic,jz4780-dw-hdmi
> >
> > This can just be a const, there's no need for the items
>
> Maybe starting with an enum is better if more compatible str
Hi,
On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> On 9/28/21 10:55 AM, Guido Günther wrote:
> > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> > that case.
> >
> > This unbreaks
On 9/28/21 11:19 AM, Guido Günther wrote:
Hi,
On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
On 9/28/21 10:55 AM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
th
Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> Hi,
> On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > > returned. Fallback to a reasonable d
On Sun, Sep 26, 2021 at 10:31:53PM +0800, Kevin Tang wrote:
> Maxime Ripard 于2021年9月17日周五 下午11:40写道：
> > > +static void sprd_dsi_encoder_mode_set(struct drm_encoder *encoder,
> > > + struct drm_display_mode *mode,
> > > + struct drm_display
> Am 28.09.2021 um 11:18 schrieb Maxime Ripard :
>
> On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote:
+properties:
+ compatible:
+items:
+ - const: ingenic,jz4780-dw-hdmi
>>>
>>> This can just be a const, there's no need for the items
>>
>> M
Hi Nikolaus / Paul,
Le lun., sept. 27 2021 at 18:44:20 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS
On 2021-09-27 14:19, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang-14 points out that comparing an 'unsigned int' against a large
> 64-bit constantn is pointless:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of
> comparison of constant 4294967296 with expression
Hi,
Le lun., sept. 27 2021 at 18:44:28 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
The jz4780 has some features which need initialization
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv
Hi Paul,
> Am 28.09.2021 um 11:58 schrieb Paul Cercueil :
>
> Hi,
>
> Le lun., sept. 27 2021 at 18:44:28 +0200, H. Nikolaus Schaller
> a écrit :
>> From: Paul Boddie
>> The jz4780 has some features which need initialization
>> according to the vendor kernel.
>> Signed-off-by: Paul Boddie
>>
On 9/28/21 11:27 AM, Lucas Stach wrote:
Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
Hi,
On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
On 9/28/21 10:55 AM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. F
Hi,
> Am 28.09.2021 um 11:35 schrieb Paul Cercueil :
>
> Hi Nikolaus / Paul,
>
> Le lun., sept. 27 2021 at 18:44:20 +0200, H. Nikolaus Schaller
> a écrit :
>> From: Paul Boddie
>> Add support for the LCD controller present on JZ4780 SoCs.
>> This SoC uses 8-byte descriptors which extend the c
On Wed, 22 Sep 2021 10:54:32 +0200,
Kai Vehmanen wrote:
(snip)
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master,
> return 0;
> }
>
> - if (!devres_open_group(master->parent, NULL
On 27/09/2021 16:10, Thomas Hellström wrote:
We may end up in i915_ttm_bo_destroy() in an error path before the
object is fully initialized. In that case it's not correct to call
__i915_gem_free_object(), because that function
a) Assumes the gem object refcount is 0, which it isn't.
b) frees the
On Tue, 14 Sep 2021 12:17:22 +0200, Maxime Ripard wrote:
> The documentation of the drm_helper_hpd_irq_event() function didn't
> document the value that function was returning. Add that part as well.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, 14 Sep 2021 12:17:23 +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that iteration, it will call each connector detect function and
> figure out if its status changed.
>
> Finally,
On Tue, 14 Sep 2021 12:17:24 +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() documentation states that this function
> is "useful for drivers which can't or don't track hotplug interrupts for
> each connector." and that "Drivers which support hotplug interrupts for
> each connector ind
Hey,
On Tue, 28 Sep 2021, Takashi Iwai wrote:
> On Wed, 22 Sep 2021 10:54:32 +0200, Kai Vehmanen wrote:
> > --- a/drivers/base/component.c
> > +++ b/drivers/base/component.c
> > @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master,
> > return 0;
> > }
> >
Reviewed-by: Karol Herbst
and queued
On Fri, Mar 26, 2021 at 10:41 PM Lyude Paul wrote:
>
> Reviewed-by: Lyude Paul
>
> On Wed, 2020-12-02 at 19:02 -0500, Jeremy Cline wrote:
> > nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
> > back to the caller. On failures, ttm_b
Reviewed-by: Karol Herbst
On Sat, Aug 21, 2021 at 10:46 AM CGEL wrote:
>
> From: Luo penghao
>
> In order to keep the code style consistency of the whole file,
> the 'ret' assignments should be deleted.
>
> The clang_analyzer complains as follows:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvm
Reviewed-by: Karol Herbst
but I will remove the unnecessary brackets as well
On Sat, Aug 21, 2021 at 10:46 AM CGEL wrote:
>
> From: Luo penghao
>
> In order to keep the code style consistency of the whole file,
> the 'inst' assignments should be deleted.
>
> The clang_analyzer complains as fol
Reviewed-by: Karol Herbst
On Sat, Sep 11, 2021 at 9:45 AM Yang Yingliang wrote:
>
> When using single_open() for opening, single_release() should be
> called, otherwise the 'op' allocated in single_open() will be leaked.
>
> Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
> Report
Reviewed-by: Karol Herbst
On Sat, Sep 11, 2021 at 9:45 AM Yang Yingliang wrote:
>
> When using single_open() for opening, single_release() should be
> called, otherwise the 'op' allocated in single_open() will be leaked.
>
> Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate int
> Am 28.09.2021 um 12:06 schrieb H. Nikolaus Schaller :
>
>>>
>>> +
>>> + /* RGB output control may be superfluous. */
>>> + if (soc_info->has_rgbc)
>>> + regmap_write(priv->map, JZ_REG_LCD_RGBC,
>>> +JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
>>> +
On 22/08/2021 01:36, Laurent Pinchart wrote:
> On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> even when LVDS outputs are not used. For this reason, the rcar-lvds
> driver probes successfully on those platforms even if no further bridge
> or panel is connected to the LVDS
Hi Paul,
> Am 28.09.2021 um 12:21 schrieb H. Nikolaus Schaller :
>
>>> @@ -1492,10 +1555,16 @@ static int ingenic_drm_init(void)
>>> {
>>> int err;
>>> + if (IS_ENABLED(CONFIG_DRM_INGENIC_DW_HDMI)) {
>>> + err = platform_driver_register(ingenic_dw_hdmi_driver_ptr);
>>> +
commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present") added bus format probing to mxsfb this exposed several issues in the
display stack as used on the Librem 5:
The nwl bridge and the panels didn't bother to set any media bus formats and in
that case mxsfb would no
media-bus-formats.h has them in hexadecimal as well so matching with
that file saves one conversion when debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially outp
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge i
Hi,
On Tue, Sep 28, 2021 at 11:27:49AM +0200, Lucas Stach wrote:
> Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> > Hi,
> > On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > > If a bridge doesn't do any bus format
On 9/28/21 2:16 PM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsf
On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
> Signed-off-by: Ez
https://bugzilla.kernel.org/show_bug.cgi?id=212425
Grzegorz Kowal (custos.men...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
This patch series adds support for the MDP and DSI PHY as found on the
MSM8953 platform (APQ8053, SDM450, SDA450, SDM625, SDM626). All the SoCs
on this platform use the adreno 506 GPU.
Changes since v2:
- Changed dt-bindings to use enum instead of oneOf
Changes since v1:
- Split the dsi phy doc c
SoCs based on the MSM8953 platform use the 14nm DSI PHY driver
Signed-off-by: Sireesh Kodali
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
b/Documentation/de
From: Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only
difference from existing configurations are io_start addresses.
Signed-off-by: Vladimir Lypak
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sireesh Kodali
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2
From: Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant
difference being presence of second DSI interface. MDP v1.16 is found on
SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506).
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
driver
On 9/28/21 2:50 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): und
Hi Neil,
> Am 28.09.2021 um 15:02 schrieb Neil Armstrong :
>
> On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
>> From: Paul Boddie
>>
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and configuration
On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
> Hey guys:
>
> After some investigation, I found the root cause this problem ("i915"
> module loading will be stuck with Christoph's refactor patches), which
> can be reproduced by building both i915 and kvmgt as kernel module and
>
Hi Nikolaus & Paul,
Le lun., sept. 27 2021 at 18:44:24 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780
HDMI support. This requires a new driver, plus device tree and
configuration
modifications.
Signed-of
On 9/27/2021 8:59 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun
nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack
From: Arnd Bergmann
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect() etc
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor patches), which
>> can be reproduced by build
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> Yes. I was thinking of the possibility of putting off some work later so
> that we don't need to make a lot of changes. GVT-g needs to take a
> snapshot of GPU registers as the initial virtual states for other vGPUs,
> which require
On 2021-09-27 15:23, Fangzhi Zuo wrote:
> Include FEC, DSC, Link Training related headers.
>
> Change since v2
> - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
>
> Signed-off-by: Fangzhi Zuo
Reviewed-by: Harry Wentland
Harry
> ---
> This patch is based on top of the other DP2
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
CC||christian.koe...@amd.co
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 299007
--> https://bugzilla.kernel.org/attachment.cgi?id=299007&action=edit
final bisect.log
--
You may reply to this email to add a comment.
You are receiving this
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 error: synchronous external abort: 9610 [#1] PREEMPT SMP
> > Modules linked in: snd_seq_dummy snd_seq snd_seq_d
On 9/28/21 12:23 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20210927:
on x86_64:
ERROR: modpost: "devm_drm_of_get_bridge" [drivers/gpu/drm/vc4/vc4.ko] undefined!
Full randconfig file is attached.
--
~Randy
config-r5051.gz
Description: application/gzip
Only signal audio when disconnected detected at dp_pm_resume since
connected status will be signaled to audio at next plugin handler.
Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
W dniu 23.09.2021 o 02:29, Laurent Pinchart pisze:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
>> Display drivers so far need to have a lot of boilerplate to first
>> r
On 28/09/2021 19:28, Rob Clark wrote:
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog
On Sat 25 Sep 16:25 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Fri, Sep 24, 2021 at 05:04:41PM -0500, Bjorn Andersson wrote:
> > On Fri 24 Sep 02:54 CDT 2021, Uwe Kleine-K?nig wrote:
> > > > +static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
> > > > +
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/d
On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> /* HL_MEM_OP_* */
> __u32 op;
> - /* HL_MEM_* flags */
> + /* HL_MEM_* flags.
> + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field holds the
> + * DMA-BUF file/FD flags.
> + */
> __u32 fla
On 2021-08-27 10:14, Bjorn Andersson wrote:
On Fri 27 Aug 00:20 CDT 2021, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-08-25 16:42:31)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
> index 2c7de43f655a..4a6132c18e57 100644
> --- a/drivers/gpu/drm
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch expands upon the HDCP helper library to manage HDCP
> > enable, disable, and check.
> >
> > Previous to this patch, the majority of the state ma
On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> From: Tomer Tayar
>
> Implement the calls to the dma-buf kernel api to create a dma-buf
> object backed by FD.
>
> We block the option to mmap the DMA-BUF object because we don't support
> DIRECT_IO and implicit P2P.
This statement
[AMD Official Use Only]
> -Original Message-
> From: Harry Wentland
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Zuo, Jerry
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
> nat...@kernel.org; intel-...@lists.freedesktop.org; dri-
> d
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > helpers.
> >
> > Cc: Stephen Boyd
> > Signed-off-by: Sean Paul
> > Link:
> >
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org wrote:
> Hi Sean
>
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > Hello again,
> > This is the second version of the HDCP helper patchset. See version 1
> > here: https://patchwork.freedesktop.org/series/94623
1 - 100 of 163 matches
Mail list logo
