With the latest pull, tests are running.
Regards,
S.Amarnath
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[10:39:23] = ttm_device (5 subtests) ==
[10:39:23] [PASSED] ttm_device_init_basic
[10:39:23] [PASSED] ttm_device_init_multiple
Hi,
Will someone be merging this patch?
thanks.
On 2/10/24 1:31 AM, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-02-09 at 21:39 -0800, Randy Dunlap wrote:
>> There is no reason to prohibit sh7760fb from being built as a
>> loadable module as suggested by Geert, so change the config symbol
>>
> On 9 Apr 2024, at 12:26 PM, Jacobe Zang wrote:
>
> This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
> designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
>
> Signed-off-by: Jacobe Zang
> ---
>
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_device_types.h
between commits:
ded402c7a044 ("drm/i915: move skl_preferred_vco_freq to display substruct")
8219ab6d6f0d ("drm/i915: move max_dotclk_freq to display substruct")
9aad73290686
On Mon, 08 Apr 2024 11:38:04 +0200 Julien Panis wrote:
> +static struct sk_buff *am65_cpsw_alloc_skb(struct am65_cpsw_rx_chn *rx_chn,
> +struct net_device *ndev,
> +unsigned int len,
> +
On Mon, 08 Apr 2024 11:38:03 +0200 Julien Panis wrote:
> goto gen_pool_create_fail;
> }
>
> + pool->desc_infos = kcalloc(pool->num_desc,
> +sizeof(*pool->desc_infos), GFP_KERNEL);
> + if (!pool->desc_infos) {
> + ret =
On 4/8/2024 2:38 AM, Julien Panis wrote:
> This patch adds XDP support to TI AM65 CPSW Ethernet driver.
>
> The following features are implemented: NETDEV_XDP_ACT_BASIC,
> NETDEV_XDP_ACT_REDIRECT, and NETDEV_XDP_ACT_NDO_XMIT.
>
> Zero-copy and non-linear XDP buffer supports are NOT
On Mon, Apr 08, 2024 at 02:31:45PM -0700, Abhinav Kumar wrote:
> On 3/28/2024 7:40 AM, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > The dp_audio read and write operations uses members in struct dp_catalog
> > for passing arguments and return values. This adds unnecessary
> >
Since vcpi has been moved into the atomic payload and
out of the port struct, the documentation of vcpi on
the port struct is no longer necessary, and is flagged
as a warning by make htmldocs
Vcpi is also documented elsewhere in this file, in the
atomic payload struct itself
Signed-off-by: Ruben
Use the same standard abbreviation KiB instead of incorrect variants.
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
This limit became a hard cap starting with the change referenced below.
Surface creation on the device will fail if the requested size is larger
than this limit so altering the value arbitrarily will expose modes that
are too large for the device's hard limits.
Fixes: 7ebb47c9f9ab ("drm/vmwgfx:
SVGA requires individual surfaces to fit within graphics memory
(max_mob_pages) which means that modes with a final buffer size that would
exceed graphics memory must be pruned otherwise creation will fail.
This fixes an issue where VMs with low graphics memory (< 64MiB) configured
with high
STDU has its own mode_valid function now so this logic can be removed from
the generic version.
Fixes: 935f795045a6 ("drm/vmwgfx: Refactor drm connector probing for display
modes")
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 ---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |
v2:
- Fix bug when not using 3D
- Remove STDU code from generic code path
- Always use KiB when logging kibibytes
Ian Forbes (4):
drm/vmwgfx: Filter modes which exceed graphics memory
drm/vmwgfx: 3D disabled should not effect STDU memory limits
drm/vmwgfx: Remove STDU logic from generic
On 09/04/2024 10:26, Jacobe Zang wrote:
> This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
> designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
>
> Signed-off-by: Jacobe Zang
> ---
> .../devicetree/bindings/display/panel/panel-simple-dsi.yaml |
On 4/9/24 12:15, Dmitry Baryshkov wrote:
On Tue, Apr 09, 2024 at 07:22:38PM +0530, Vignesh Raman wrote:
Hi Maíra,
On 09/04/24 15:10, Maíra Canal wrote:
On 4/9/24 05:13, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific tests to
testlist and skip driver-specific tests in
On Tue, 9 Apr 2024 at 21:33, Danilo Krummrich wrote:
>
> On 4/9/24 10:27, Lucas Stach wrote:
> > Am Dienstag, dem 09.04.2024 um 10:34 +1000 schrieb Dave Airlie:
> >> From: Dave Airlie
> >>
> >> Running a lot of VK CTS in parallel against nouveau, once every
> >> few hours you might see something
On 10/Apr/2024 Yuguo Pei wrote:
> Some screen sizes using st7789v chips are different from 240x320,
> and offsets need to be set to display all images properly.
>
> For those who use screens with offset, they only need to modify the values
> of size and offset, and do not need to a new
Hi
Reviewed-by: Thomas Zimmermann
for the series.
Best regards
Thomas
Am 09.04.24 um 19:02 schrieb Uwe Kleine-König:
Hello,
with some patches sent earlier[1], this series converts all platform
drivers below drivers/gpu to not use struct platform_device::remove()
any more.
See commit
On Tue, 9 Apr 2024 at 21:27, Konrad Dybcio wrote:
>
>
>
> On 4/9/24 20:15, Dmitry Baryshkov wrote:
> > On Tue, Apr 09, 2024 at 08:07:56PM +0200, Konrad Dybcio wrote:
> >>
> >>
> >> On 4/9/24 20:04, Dmitry Baryshkov wrote:
> >>> On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote:
> On
On 4/9/24 20:15, Dmitry Baryshkov wrote:
On Tue, Apr 09, 2024 at 08:07:56PM +0200, Konrad Dybcio wrote:
On 4/9/24 20:04, Dmitry Baryshkov wrote:
On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote:
On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
wrote:
On Tue, Apr 09, 2024 at
On Tue, Apr 09, 2024 at 08:07:56PM +0200, Konrad Dybcio wrote:
>
>
> On 4/9/24 20:04, Dmitry Baryshkov wrote:
> > On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote:
> > > On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
> > > wrote:
> > > >
> > > > On Tue, Apr 09, 2024 at 05:12:46PM
On 4/9/24 17:24, Dmitry Baryshkov wrote:
On Tue, Apr 09, 2024 at 05:13:15PM +0200, Konrad Dybcio wrote:
On 4/6/24 05:25, Dmitry Baryshkov wrote:
On Fri, Apr 05, 2024 at 10:41:33AM +0200, Konrad Dybcio wrote:
Add speebin data for A740, as found on SM8550 and derivative SoCs.
On Tue, Apr 09, 2024 at 04:29:42PM +0800, David Gow wrote:
> > +ifeq ($(CCONFIG_KUNIT_SUPPRESS_BACKTRACE),y)
>
> s/CCONFIG_/CONFIG_/ ?
>
>
Odd, I know I tested this (and it still works ;-).
The additional "C" must have slipped in at some point.
Thanks for noticing!
Guenter
Some screen sizes using st7789v chips are different from 240x320,
and offsets need to be set to display all images properly.
For those who use screens with offset, they only need to modify the values
of size and offset, and do not need to a new set_addr_win function.
Signed-off-by: Yuguo Pei
On 4/9/24 20:04, Dmitry Baryshkov wrote:
On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote:
On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
wrote:
On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote:
On 4/6/24 04:56, Dmitry Baryshkov wrote:
On Fri, Apr 05, 2024 at
On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote:
> On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
> wrote:
> >
> > On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote:
> > >
> > >
> > > On 4/6/24 04:56, Dmitry Baryshkov wrote:
> > > > On Fri, Apr 05, 2024 at 10:41:31AM +0200,
On Tue, 9 Apr 2024 17:49:25 +0200, Greg KH wrote:
> So you are now hard-coding the size?
Yes, the change just helps developers who want to adapt to different screen
sizes.
> Is this always going to be 0, if so, why need it at all?
Not sure. For example, when HEIGHT and WIDTH are 240 and 280,
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: a053fd3ca5d1b927a8655f239c84b0d790218fda Add linux-next specific
files for 20240409
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404091516.9h8idamm-...@intel.com
https
On Wed, Apr 10, 2024 at 01:28:06AM +0800, Yuguo Pei wrote:
> On Tue, 9 Apr 2024 17:49:25 +0200, Greg KH wrote:
> > So you are now hard-coding the size?
>
> Yes, the change just helps developers who want to adapt to different screen
> sizes.
So there is no change? I don't understand.
> > Is
On Tue, Apr 09, 2024 at 10:45:22AM -0600, Zeng, Oak wrote:
Oak - A few drive by comments...
> Hi Jason
>
> We are re-spinning this series based on the previous community feedback. I
> will send out a v2 soon. There were big changes compared to v1. So we would
> better to discuss this work
On Tue, Apr 09, 2024 at 04:45:22PM +, Zeng, Oak wrote:
> > I saw, I am saying this should not be done. You cannot unmap bits of
> > a sgl mapping if an invalidation comes in.
>
> You are right, if we register a huge mmu interval notifier to cover
> the whole address space, then we should use
On 4/7/2024 4:53 PM, Dmitry Baryshkov wrote:
The functions mipi_dsi_compression_mode() and
mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer
size. Follow example of other similar MIPI DSI functions and use int
return type instead of size_t.
Hi Dmitry,
Reviewed-by:
On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
wrote:
>
> On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote:
> >
> >
> > On 4/6/24 04:56, Dmitry Baryshkov wrote:
> > > On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote:
> > > > From: Neil Armstrong
> > > >
> > > >
On Tue, Apr 09, 2024 at 07:02:47PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> with some patches sent earlier[1], this series converts all platform
> drivers below drivers/gpu to not use struct platform_device::remove()
> any more.
I forgot to include footnote with the list of earlier patches.
Hello,
with some patches sent earlier[1], this series converts all platform
drivers below drivers/gpu to not use struct platform_device::remove()
any more.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The pull request you sent on Tue, 9 Apr 2024 13:29:41 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-04-09
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2c71fdf02a95b3dd425b42f28fd47fb2b1d22702
Thank you!
--
Deet-doot-dot, I am a bot.
On Tue, Apr 09, 2024 at 08:58:55AM -0700, Namhyung Kim wrote:
> Hello,
>
> On Tue, Apr 9, 2024 at 3:14 AM Jani Nikula
> wrote:
> >
> > On Tue, 09 Apr 2024, Ingo Molnar wrote:
> > > * Jani Nikula wrote:
> > >
> > >> On Mon, 08 Apr 2024, Namhyung Kim wrote:
> > >> > To pick up changes from:
>
On Mon, Apr 08, 2024 at 08:04:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow atmel-hlcdc to be built with COMPILE_TEST=y for greater
> coverage. Builds fine on x86/x86_64 at least.
>
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Signed-off-by: Ville Syrjälä
Acked-by: Sam
When using devm_clk_get_prepared() instead of devm_clk_get() the clock
is already returned prepared. So probe doesn't need to call
clk_prepare() and at remove time the call to clk_unprepare() can be
dropped. The latter makes the remove callback empty, so it can be
dropped, too.
Signed-off-by: Uwe
Hi Jason
We are re-spinning this series based on the previous community feedback. I will
send out a v2 soon. There were big changes compared to v1. So we would better
to discuss this work with v2.
See some reply inline.
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday,
On Tue, Apr 9, 2024 at 12:34 AM Rong Qianfeng <11065...@vivo.com> wrote:
>
>
> 在 2024/4/8 15:58, Christian König 写道:
> > Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
> >> [SNIP]
> >>> Am 13.11.21 um 07:22 schrieb Jianqun Xu:
> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf
Hello,
On Mon, Mar 04, 2024 at 10:05:56AM +0100, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
>
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v7:
* use drm_panic_gem_get_scanout_buffer() helper
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
v9:
* Revert to using get_scanout_buffer() (Sima)
*
Add a debugfs file, so you can test drm_panic without freezing
your machine. This is unsafe, and should be enabled only for
developer or tester.
To display the drm_panic screen on the device 0:
echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0
v9:
* Create a debugfs file for each plane in the
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v7
* Use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v8:
* Replace get_scanout_buffer() with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v5:
* Also check that the plane is visible and primary. (Thomas Zimmermann)
v7:
* use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* go back to get_scanout_buffer()
* move get_scanout_buffer() to plane helper functions
v12:
* Rename
drm/panic: Add a drm panic handler
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
This is one of the missing feature, when disabling VT/fbcon in the kernel:
Add support for the following formats:
DRM_FORMAT_RGB565
DRM_FORMAT_RGBA5551
DRM_FORMAT_XRGB1555
DRM_FORMAT_ARGB1555
DRM_FORMAT_RGB888
DRM_FORMAT_XRGB
DRM_FORMAT_ARGB
DRM_FORMAT_XBGR
DRM_FORMAT_XRGB2101010
DRM_FORMAT_ARGB2101010
v10:
* move and simplify the functions from the drm
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
v2
* Use get_scanout_buffer() instead of the drm client API.
(Thomas Zimmermann)
* Add the panic reason to the panic message (Nerdopolis)
From: Daniel Vetter
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add the sound node which is linked to the MT8365 SoC AFE and
> the MT6357 audio codec.
>
> Update the file header.
>
> Signed-off-by: Alexandre Mergnat
> ---
> arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 98
> +++--
> 1
Hello,
On Tue, Apr 9, 2024 at 3:14 AM Jani Nikula wrote:
>
> On Tue, 09 Apr 2024, Ingo Molnar wrote:
> > * Jani Nikula wrote:
> >
> >> On Mon, 08 Apr 2024, Namhyung Kim wrote:
> >> > To pick up changes from:
> >> >
> >> >b112364867499 ("drm/i915: Add GuC submission interface version
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add audio codec support of MT6357 PMIC.
> Update the file header.
Why?
>
> Signed-off-by: Alexandre Mergnat
> ---
> arch/arm64/boot/dts/mediatek/mt6357.dtsi | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add the audio codec sub-device. This sub-device is used to set required
> and optional voltage properties between the codec and the board.
>
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add MT8365 audio codec bindings to set required
> and optional voltage properties between the codec and the board.
> The properties are:
> - phandle of the requiered power supply.
typo
> - Setup of microphone bias voltage.
> - Setup of the speaker
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add soundcard bindings for the MT8365 SoC with the MT6357 audio codec.
>
> Signed-off-by: Alexandre Mergnat
> +patternProperties:
> + "^dai-link-[0-9]+$":
> +type: object
> +description:
> + Container for dai-link level properties
On Sat, Apr 06, 2024 at 12:57:47AM +0800, purofle wrote:
> Some screen sizes using st7789v chips are different from 240x320,
> and offsets need to be set to display all images properly.
>
> Signed-off-by: purofle
We need a semi-real name here please.
> ---
> drivers/staging/fbtft/fb_st7789v.c
On 09/04/2024 15:41, Alexandre Mergnat wrote:
> Add MT8365 audio front-end bindings
>
> Signed-off-by: Alexandre Mergnat
> ---
> +properties:
> + compatible:
> +const: mediatek,mt8365-afe-pcm
> +
> + reg:
> +maxItems: 1
> +
> + "#sound-dai-cells":
> +const: 0
> +
> + clocks:
> +
On Tue, 9 Apr 2024 at 18:41, AngeloGioacchino Del Regno
wrote:
>
> Il 09/04/24 17:20, Dmitry Baryshkov ha scritto:
> > On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> >> The display IPs in MediaTek SoCs support being interconnected with
> >> different instances of
Il 09/04/24 17:20, Dmitry Baryshkov ha scritto:
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for
On Tue, Apr 09, 2024 at 12:46:11PM +0300, Jani Nikula wrote:
> To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
> to the struct drm_edid based function to extract product id, and use the
> drm printer function to debug log it.
>
> The underlying assumption is that struct
Am 09.04.24 um 09:32 schrieb Rong Qianfeng:
在 2024/4/8 15:58, Christian König 写道:
Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
[SNIP]
Am 13.11.21 um 07:22 schrieb Jianqun Xu:
Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
offset and len.
You have not given an use case
Great to have this!
Reviewed-by: Martin Krastev
Regards,
Martin
On Wed, Apr 3, 2024 at 2:28 AM Zack Rusin wrote:
>
> vmwgfx never supported prime import of external buffers. Furthermore the
> driver exposes two different objects to userspace: vmw_surface's and
> gem buffers but prime
Hi Jani,
On Tue, Apr 9, 2024 at 1:13 PM Jani Nikula wrote:
> On Tue, 09 Apr 2024, Geert Uytterhoeven wrote:
> > On Tue, Apr 9, 2024 at 12:04 PM Jani Nikula
> > wrote:
> >> On Tue, 09 Apr 2024, Geert Uytterhoeven wrote:
> >> > The user should not need to know which helpers are needed for the
On Tue, Apr 09, 2024 at 05:13:15PM +0200, Konrad Dybcio wrote:
>
>
> On 4/6/24 05:25, Dmitry Baryshkov wrote:
> > On Fri, Apr 05, 2024 at 10:41:33AM +0200, Konrad Dybcio wrote:
> > > Add speebin data for A740, as found on SM8550 and derivative SoCs.
> > >
> > > Signed-off-by: Konrad Dybcio
> >
On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote:
>
>
> On 4/6/24 04:56, Dmitry Baryshkov wrote:
> > On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote:
> > > From: Neil Armstrong
> > >
> > > Usually, speedbin 0 is the "super SKU", a.k.a the one which can clock
> > >
On Fri, Apr 05, 2024 at 10:41:30AM +0200, Konrad Dybcio wrote:
> Introduce getters for SoC product and feature codes and export them.
>
Thought I commented on this already, but I don't see my reply...
Can you please elaborate on what this stuff is, such that we have a
track record in the
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color,
From: Andrew Davis
This new export type exposes to userspace the SRAM area as a DMA-BUF
Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
Tested-by: Pascal Fontain
---
drivers/misc/Kconfig | 7 +
On Tue, Apr 09, 2024 at 07:22:38PM +0530, Vignesh Raman wrote:
> Hi Maíra,
>
> On 09/04/24 15:10, Maíra Canal wrote:
> > On 4/9/24 05:13, Vignesh Raman wrote:
> > > Uprev IGT and add amd, v3d, vc4 and vgem specific tests to
> > > testlist and skip driver-specific tests in *-skips.txt.
> > > Also
On 4/6/24 05:25, Dmitry Baryshkov wrote:
On Fri, Apr 05, 2024 at 10:41:33AM +0200, Konrad Dybcio wrote:
Add speebin data for A740, as found on SM8550 and derivative SoCs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 14 ++
1 file changed, 14
On 4/6/24 04:56, Dmitry Baryshkov wrote:
On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote:
From: Neil Armstrong
Usually, speedbin 0 is the "super SKU", a.k.a the one which can clock
the highest. Falling back to it when things go wrong is largely
suboptimal, as more often than
On Wed, Apr 3, 2024 at 2:28 AM Zack Rusin wrote:
>
> The conditional was supposed to prevent enabling of a crtc state
> without a set primary plane. Accidently it also prevented disabling
> crtc state with a set primary plane. Neither is correct.
>
> Fix the conditional and just driver-warn when
On Wed, Apr 3, 2024 at 2:28 AM Zack Rusin wrote:
>
> crc checksums are used to validate the output. Normally they're part
> of the actual display hardware but on virtual stack there's nothing
> to automatically generate them.
>
> Implement crc generation for the vmwgfx stack. This works only on
>
On 4/6/24 04:21, Dmitry Baryshkov wrote:
On Fri, Apr 05, 2024 at 10:41:30AM +0200, Konrad Dybcio wrote:
Introduce getters for SoC product and feature codes and export them.
Signed-off-by: Konrad Dybcio
---
[...]
+ /* Ensure the value makes sense */
+ if (raw_code >=
On Mon, Apr 08, 2024 at 10:06:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life easier by providing a function that hands
> out the the correct drm_vblank_crtc for a given a drm_crtc.
>
> Also abstract the lower level internals of the vblank
> code in a similar fashion.
>
>
On Mon, Apr 08, 2024 at 09:33:01PM -0500, Bjorn Andersson wrote:
> On Tue, Apr 09, 2024 at 01:07:57AM +0300, Dmitry Baryshkov wrote:
> > On Tue, 9 Apr 2024 at 00:23, Abhinav Kumar
> > wrote:
> > > On 4/8/2024 2:12 PM, Dmitry Baryshkov wrote:
> > > > On Mon, 8 Apr 2024 at 22:43, Abhinav Kumar
>
On 4/9/24 7:06 AM, Pascal FONTAIN wrote:
From: Andrew Davis
This new export type exposes to userspace the SRAM area as a DMA-BUF
Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
Tested-by: Pascal Fontain
arse.BooleanOptionalAction)
subparsers = parser.add_subparsers(required=True)
---
base-commit: ab556156cafa24ec7de9e89bc18fa15637c21a59
change-id: 20240409-fd-fix-lxml-eecc6949f64e
Best regards,
--
Dmitry Baryshkov
On Fri, 2024-04-05 at 17:47 +0200, Arnd Bergmann wrote:
> On Fri, Apr 5, 2024, at 17:43, Niklas Schnelle wrote:
> > In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
> > compile time. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> >
On 09/04/2024 10:21, Thomas Zimmermann wrote:
Hi
Am 28.03.24 um 13:03 schrieb Jocelyn Falempe:
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
*
Hi,
On 09/04/2024 10:30, Thomas Zimmermann wrote:
Hi
Am 28.03.24 um 13:03 schrieb Jocelyn Falempe:
+/**
+ * struct drm_scanout_buffer - DRM scanout buffer
+ *
+ * This structure holds the information necessary for drm_panic to
draw the
+ * panic screen, and display it.
+ */
+struct
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Allows initialization as CLOCKSOURCE.
>
> Signed-off-by: Yoshinori Sato
Thanks for your patch!
> --- a/drivers/clocksource/sh_tmu.c
> +++ b/drivers/clocksource/sh_tmu.c
> @@ -495,7 +514,12 @@ static int
Hi Maíra,
On 09/04/24 15:10, Maíra Canal wrote:
On 4/9/24 05:13, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific tests to
testlist and skip driver-specific tests in *-skips.txt.
Also add testlist to the MAINTAINERS file and update xfails.
A better approach would be to
From: Nicolas Belin
Add the support of MT6357 PMIC audio codec.
Signed-off-by: Nicolas Belin
Signed-off-by: Alexandre Mergnat
---
sound/soc/codecs/Kconfig |7 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/mt6357.c | 1898 +
Add audio front end support of MT8365 SoC.
Update the file header.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365.dtsi | 46 +---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
Add audio codec support of MT6357 PMIC.
Update the file header.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt6357.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt6357.dtsi
Enable the MediaTek MT8365-EVK sound support.
The audio feature is handled by the MT8365 SoC and
the MT6357 PMIC codec audio.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig
Add the audio codec sub-device. This sub-device is used to set required
and optional voltage properties between the codec and the board.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
Add the sound node which is linked to the MT8365 SoC AFE and
the MT6357 audio codec.
Update the file header.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 98 +++--
1 file changed, 94 insertions(+), 4 deletions(-)
diff --git
- Add specific config to enable:
- MT8365 sound support
- MT6357 audio codec support
- Add the mt8365 directory and all drivers under it.
Signed-off-by: Alexandre Mergnat
---
sound/soc/mediatek/Kconfig | 20
sound/soc/mediatek/Makefile| 1 +
Add mt8365 platform driver.
Signed-off-by: Alexandre Mergnat
---
sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 2275
1 file changed, 2275 insertions(+)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
new file
1 - 100 of 226 matches
Mail list logo
