On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/11/16 19:19, Dmitry Baryshkov wrote:
> > On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> On 2023/11/16 17:30, Dmitry Baryshkov wrote:
> >>> On Thu, 16 Nov 2023 at 11:14, Sui Jingfeng wrote:
> H
When kzalloc() for smu_table->ecc_table fails, we should free
the previously allocated resources to prevent memleak.
Fixes: edd794208555 ("drm/amd/pm: add message smu to get ecc_table v2")
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 5 -
1 file changed
Am 23.11.23 um 02:22 schrieb Lu Yao:
For 'AMDGPU_FAMILY_SI' family cards, in 'si_common_early_init' func, init
'didt_rreg' and 'didt_wreg' to 'NULL'. But in func
'amdgpu_debugfs_regs_didt_read/write', using 'RREG32_DIDT' 'WREG32_DIDT'
lacks of relevant judgment. And other 'amdgpu_ip_block_version
Hi
Am 23.11.23 um 08:16 schrieb Heiner Kallweit:
On 23.11.2023 07:56, Thomas Zimmermann wrote:
Hi
Am 20.11.23 um 22:46 schrieb Heiner Kallweit:
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-ba
On 23.11.2023 09:19, Thomas Zimmermann wrote:
> Hi
>
> Am 23.11.23 um 08:16 schrieb Heiner Kallweit:
>> On 23.11.2023 07:56, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 20.11.23 um 22:46 schrieb Heiner Kallweit:
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_d
Hi
Am 18.11.23 um 12:10 schrieb Javier Martinez Canillas:
Ard Biesheuvel writes:
Hello Ard,
On Fri, 17 Nov 2023 at 00:09, Rob Herring wrote:
[...]
This could also lead to an interesting scenario. As simple-framebuffer
can define its memory in a /reserved-memory node, but that is ignore
Hi
Am 23.11.23 um 09:34 schrieb Heiner Kallweit:
On 23.11.2023 09:19, Thomas Zimmermann wrote:
Hi
Am 23.11.23 um 08:16 schrieb Heiner Kallweit:
On 23.11.2023 07:56, Thomas Zimmermann wrote:
Hi
Am 20.11.23 um 22:46 schrieb Heiner Kallweit:
After removal of the legacy EEPROM driver and I2C_C
On Thu, 23 Nov 2023 01:04:56 +0300
Dmitry Osipenko wrote:
> On 11/10/23 13:53, Boris Brezillon wrote:
> > Hm, there was no drm_gem_shmem_get_pages_sgt() call here, why should we
> > add a drm_gem_shmem_get_pages()? What we should do instead is add a
> > drm_gem_shmem_get_pages() for each drm_gem_
On Thu, 23 Nov 2023 01:30:24 +0300
Dmitry Osipenko wrote:
> On 11/13/23 12:54, Boris Brezillon wrote:
> > On Mon, 30 Oct 2023 02:02:01 +0300
> > Dmitry Osipenko wrote:
> >
> >> Don't free refcounted shmem object to prevent use-after-free bug that
> >> is worse than a memory leak.
> >>
> >> Si
> Am 22.11.2023 um 20:34 schrieb Maxime Ripard :
>
> Hi,
>
> On Wed, Nov 22, 2023 at 04:34:21PM +, Donald Robson wrote:
>> This patch series adds the initial DRM driver for Imagination Technologies
>> PowerVR
>> GPUs, starting with those based on our Rogue architecture. It's worth
>> poi
Hello Doug, hello Bjorn,
On Tue, Nov 21, 2023 at 08:14:14AM -0800, Doug Anderson wrote:
> On Tue, Nov 21, 2023 at 8:05 AM Uwe Kleine-König
> wrote:
> > On Tue, Nov 21, 2023 at 07:15:51AM -0800, Doug Anderson wrote:
> > > > @@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
> >
On 22/11/2023 16:32, Aravind Iddamsetty wrote:
> On 11/10/23 17:54, Tomer Tayar wrote:
>> On 20/10/2023 18:58, Aravind Iddamsetty wrote:
>>> Define the netlink registration interface and commands, attributes that
>>> can be commonly used across by drm drivers. This patch intends to use
>>> the gene
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
Hi Uwe,
(CC'ing Bartosz)
Thank you for the patch.
On Tue, Nov 21, 2023 at 02:50:43PM +0100, Uwe Kleine-König wrote:
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical c
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
is partial, as this driver currently supports using only one
core group and that's reflected on all parts of
Il 25/10/23 12:49, AngeloGioacchino Del Regno ha scritto:
While the commit that was sent to the mailing lists was fine, something
happened during merge and the mtk_gamma_set() function got broken as
a writel() was turned into a readl().
Fix that by changing that back to the expected writel().
F
This patch introduces an initial KUnit test suite for GEM objects
backed by shmem buffers.
Suggested-by: Javier Martinez Canillas
Signed-off-by: Marco Pagani
v4:
- Add missing MMU dependency for DRM_GEM_SHMEM_HELPER (kernel test robot)
v3:
- Explicitly cast pointers in the helpers
- Removed unu
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. When "intel_dp->aux.name" is NULL,
these error messages will trigger the null pointer dereference issue.
Signed-off-by: Kunwu Chan
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 12 ++--
1 f
Hello Laurent,
On Thu, Nov 23, 2023 at 11:46:52AM +0200, Laurent Pinchart wrote:
> (CC'ing Bartosz)
I'm already in discussion with Bart :-)
> On Tue, Nov 21, 2023 at 02:50:43PM +0100, Uwe Kleine-König wrote:
> > This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> > the pwm c
From: Andy Yan
Hi:
I get a use-after-free KASAN report on a psr enabled system as bellow:
It seems there is a race happens like this:
task 6074: userspace
suspend_devices_and_enter+0xa20/0xba0
Add Evervision VGG644804 5.7" 640x480 LVDS panel compatible string.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Document
Timings taken from the datasheet, although sometimes there are just
typical values and it's not clear if they are no min and max values or
if you must use the typical value exactly. To make things worse, there
is no back porch but only a combined sync and back porch length.
Unfortunately, there is
On Thu, 23 Nov 2023 10:53:20 +0100
AngeloGioacchino Del Regno
wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver cu
On 23/11/2023 10:53, AngeloGioacchino Del Regno wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver currently supports
Il 23/11/23 11:39, Krzysztof Kozlowski ha scritto:
On 23/11/2023 10:53, AngeloGioacchino Del Regno wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
The lowest supported clock frequency of the PHY is 125MHz (see also
mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the
wrong minimal value, which will make the .enable() op return -EINVAL on
low frequencies. Fix the minimal clamping value.
Fixes: efda51a58b4a ("drm/mediatek: add
Hi Heiner,
On Thu, Nov 23, 2023 at 10:40:35AM +0100, Heiner Kallweit wrote:
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be
Il 23/11/23 11:35, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 10:53:20 +0100
AngeloGioacchino Del Regno
wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU
Il 23/11/23 12:02, Michael Walle ha scritto:
The lowest supported clock frequency of the PHY is 125MHz (see also
mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the
wrong minimal value, which will make the .enable() op return -EINVAL on
low frequencies. Fix the minimal clamping v
On 11/23/23 04:33, Kunwu Chan wrote:
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Fixes: a9e2559c931d ("drm/msm/gpu: Move zap shader loading to adreno")
Signed-off-by: Kunwu
Il 23/11/23 12:15, AngeloGioacchino Del Regno ha scritto:
Il 23/11/23 11:35, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 10:53:20 +0100
AngeloGioacchino Del Regno
wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 f
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
is partial, as this driver currently supports using only one
core group and that's reflected on all parts of
On 23/11/2023 12:50, AngeloGioacchino Del Regno wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver currently supports
Il 23/11/23 12:57, Krzysztof Kozlowski ha scritto:
On 23/11/2023 12:50, AngeloGioacchino Del Regno wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
is partial, as this driver currently supports using only one
core group and that's reflected on all parts of
Hi Dave, Daniel,
Lots of small fixes for various drivers.
Cheers,
~Maarten
drm-misc-fixes-2023-11-23:
Fixes for v6.7-rc3:
- Panel fixes for innolux and auo,b101uan08.3 panel.
- Fix ivpu MMIO reset.
- AST fix on connetor disconnection.
- nouveau gsp fix.
- rockchip color fix.
- Fix Himax83102-j0
On Thu, Nov 23, 2023 at 06:04:31PM +0800, Kunwu Chan wrote:
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. When "intel_dp->aux.name" is NULL,
> these error messages will trigger the null pointer dereference issue.
How did you reach that conclusio
On 11/23/23 12:05, Boris Brezillon wrote:
> On Thu, 23 Nov 2023 01:04:56 +0300
> Dmitry Osipenko wrote:
>
>> On 11/10/23 13:53, Boris Brezillon wrote:
>>> Hm, there was no drm_gem_shmem_get_pages_sgt() call here, why should we
>>> add a drm_gem_shmem_get_pages()? What we should do instead is add
If we're given a malformed entity in drm_sched_entity_init()--shouldn't
happen, but we verify--with out-of-bounds priority value, we set it to an
allowed value. Fix the expression which sets this limit.
Signed-off-by: Luben Tuikov
Fixes: 56e449603f0ac5 ("drm/sched: Convert the GPU scheduler to va
On 11/23/23 12:08, Boris Brezillon wrote:
> On Thu, 23 Nov 2023 01:30:24 +0300
> Dmitry Osipenko wrote:
>
>> On 11/13/23 12:54, Boris Brezillon wrote:
>>> On Mon, 30 Oct 2023 02:02:01 +0300
>>> Dmitry Osipenko wrote:
>>>
Don't free refcounted shmem object to prevent use-after-free bug th
On 23/11/2023 13:05, AngeloGioacchino Del Regno wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver currently supports
Il 23/11/23 13:43, Krzysztof Kozlowski ha scritto:
On 23/11/2023 13:05, AngeloGioacchino Del Regno wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
On 11/20/23 18:06, Heiko Stuebner wrote:
> Hi Johan,
>
> Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker:
>> The Rk3066 hdmi output format is hard coded to RGB. Remove
>> all useless code related to colorimetry and enc_out_format.
>>
>> Signed-off-by: Johan Jonker
>
> I gu
Hi,
Here's this week drm-misc-next PR.
It's been fairly calm, but there's one big change: the IMG GPU driver is
now merged!
Maxime
drm-misc-next-2023-11-23:
drm-misc-next for 6.8:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Drop deprecated drm_kms_helper.edid_firmware module par
On Thu, 23 Nov 2023 12:15:01 +0100
AngeloGioacchino Del Regno
wrote:
> Il 23/11/23 11:35, Boris Brezillon ha scritto:
> > On Thu, 23 Nov 2023 10:53:20 +0100
> > AngeloGioacchino Del Regno
> > wrote:
> >
> >> Some SoCs may be equipped with a GPU containing two core groups
> >> and this is exac
Hi,
On 2023/11/23 15:48, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 07:37, Sui Jingfeng wrote:
Hi,
On 2023/11/16 21:00, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 14:18, Sui Jingfeng wrote:
Hi,
On 2023/11/15 00:06, Dmitry Baryshkov wrote:
On Tue, 14 Nov 2023 at 17:09, Sui Jing
> > + if (!vgpu->msi_trigger)
> > + return;
> > + eventfd_signal(vgpu->msi_trigger, 1);
> > }
>
> I think it's a little simpler to write as
> if (vgpu->msi_trigger)
> eventfd_signal(vgpu->msi_trigger, 1);
Good point. I folded that suggestion into the patch.
On Thu, 23 Nov 2023 13:05:21 +0100
AngeloGioacchino Del Regno
wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver cu
> > * eventfd_signal - Adds @n to the eventfd counter.
>
> This still refers to @n here, and in patch 4.
Fixed and folded. Thanks!
Il 23/11/23 13:59, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 12:15:01 +0100
AngeloGioacchino Del Regno
wrote:
Il 23/11/23 11:35, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 10:53:20 +0100
AngeloGioacchino Del Regno
wrote:
Some SoCs may be equipped with a GPU containing two cor
Il 23/11/23 14:13, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 13:05:21 +0100
AngeloGioacchino Del Regno
wrote:
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU
Add support for a DSI output on VDOSYS0. Luckily, there is a new
feature to support dynamic selections of the output (connector).
Use it to add support for a DSI output.
Apart from that, this is pretty straghtforward by just adding new
compatibles and add the correct DSI nodes to the SoC dtsi.
Th
Add the compatible string for MediaTek MT8195 SoC, using the same MIPI
D-PHY block as the MT8183.
Signed-off-by: Michael Walle
---
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-ph
Add the compatible string for MediaTek MT8195 SoC, using the same DSI
block as the MT8183.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/me
Add the two DSI controller node and the associated DPHY nodes.
Individual boards have to enable them in the board device tree.
Signed-off-by: Michael Walle
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/d
With the latest dynamic selection of the output component, we can now
support different outputs. Move current output component into the
dynamic routes array and add the new DSI0 output.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
1 file changed, 7 insert
On 23/11/2023 09:08, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng wrote:
Hi,
On 2023/11/16 19:19, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng wrote:
Hi,
On 2023/11/16 17:30, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 11:14, Sui Jingfeng
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already. And if the IOMMU *is* entirely
absent, then attempting to go ahead with CMA and either suceeding or
failing decisively
Xinlei Lee's mail is bouncing:
: host mailgw02.mediatek.com[216.200.240.185] said:
550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to
RCPT TO command)
Remove it.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1
On Thu, 23 Nov 2023 14:24:57 +0100
AngeloGioacchino Del Regno
wrote:
> >>
> >> So, while I agree that it'd be slightly more readable as a diff if those
> >> were two different commits I do have reasons against splitting.
> >
> > If we just need a quick fix to avoid PWRTRANS interrupts from
On Thu, 23 Nov 2023 14:30:08 +0100
AngeloGioacchino Del Regno
wrote:
> Il 23/11/23 14:13, Boris Brezillon ha scritto:
> > On Thu, 23 Nov 2023 13:05:21 +0100
> > AngeloGioacchino Del Regno
> > wrote:
> >
> >> Some SoCs may be equipped with a GPU containing two core groups
> >> and this is exac
Dear Jani,
Thank you for your reply.
Am 22.11.23 um 11:38 schrieb Jani Nikula:
On Tue, 21 Nov 2023, Paul Menzel wrote:
Connecting a USB Type-C port replicator [1] to the only USB Type-C port
of the Dell XPS 13 9360 with Debian sid/unstable and Debian’s Linux
kernel 6.10.5, and then connecti
On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
> RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other
> architectures. Enabling hardware FP requires overriding the ISA string
> for the relevant compilation units.
Ah yes, bringing the joy of frame-larger-than warnings
On Thu, 23 Nov 2023 15:24:32 +0300
Dmitry Osipenko wrote:
> On 11/23/23 12:05, Boris Brezillon wrote:
> > On Thu, 23 Nov 2023 01:04:56 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 11/10/23 13:53, Boris Brezillon wrote:
> >>> Hm, there was no drm_gem_shmem_get_pages_sgt() call here, why
> >>
On Mon, 30 Oct 2023 02:01:54 +0300
Dmitry Osipenko wrote:
> To simplify the drm-shmem refcnt handling, we're moving away from
> the implicit get_pages() that is used by get_pages_sgt(). From now on
> drivers will have to pin pages while they use sgt. Panfrost's shrinker
> doesn't support swapping
On Thu, 16 Nov 2023 11:53:17 +0100, Flavio Suligoi wrote:
> This patchset (rebased on v6.7.0-rc1 kernel version):
>
> - includes and updates the mps,mp3309c.yaml dt bindings file:
> - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> Note: the patch related to this file w
Il 23/11/23 14:51, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 14:24:57 +0100
AngeloGioacchino Del Regno
wrote:
So, while I agree that it'd be slightly more readable as a diff if those
were two different commits I do have reasons against splitting.
If we just need a quick fix to avo
On Sat, 18 Nov 2023, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
>
> int pwm_apply_cansleep(struct pwm *, struct pwm_state *);
> int pwm_apply_atomic(struct pwm *, struct pwm_state *)
Hi, Michael:
Michael Walle 於 2023年11月21日 週二 下午10:44寫道：
>
> Hi,
>
> > mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> > always have the CRTC with id 0, the ext id 1 and the third id 2. This
> > is only true if the paths are all available. But paths are optional
> > (see
> >
On Fri, 17 Nov 2023 13:06:25 +0100, Alexander Stein wrote:
> Use dev_err_probe to simplify error paths. Also let dev_err_probe handle
> the -EPROBE_DEFER case and add an entry to
> /sys/kernel/debug/devices_deferred when deferred.
>
>
Applied, thanks!
[1/1] backlight: pwm_bl: Use dev_err_probe
Hi,
> mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> always have the CRTC with id 0, the ext id 1 and the third id 2. This
> is only true if the paths are all available. But paths are optional
> (see
> also comment in mtk_drm_kms_init()), e.g. the main path might not be
>
On Thu, 23 Nov 2023 16:14:12 +0100
AngeloGioacchino Del Regno
wrote:
> Il 23/11/23 14:51, Boris Brezillon ha scritto:
> > On Thu, 23 Nov 2023 14:24:57 +0100
> > AngeloGioacchino Del Regno
> > wrote:
> >
>
> So, while I agree that it'd be slightly more readable as a diff if those
> >
Hi,
On 2023/11/23 16:08, Dmitry Baryshkov wrote:
The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined,
No, they are not. Semantics are pretty simple: do not create the
drm_connector instance. Pass the flag to the next bridge in the chain.
Then, my problem is that do we
On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/11/23 16:08, Dmitry Baryshkov wrote:
> >> The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined,
> > No, they are not. Semantics are pretty simple: do not create the
> > drm_connector instance. Pass the fl
Hi,
On 2023/11/23 21:39, Neil Armstrong wrote:
On 23/11/2023 09:08, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng
wrote:
Hi,
On 2023/11/16 19:19, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng
wrote:
Hi,
On 2023/11/16 17:30, Dmitry Baryshkov w
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
Em 23/11/2023 13:24, Simon Ser escreveu:
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
Thank you!
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
ops :)
Hi,
On 2023/11/24 00:06, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote:
Hi,
On 2023/11/23 16:08, Dmitry Baryshkov wrote:
The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined,
No, they are not. Semantics are pretty simple: do not create the
d
Hi Dave & Sima -
drm-intel-fixes-2023-11-23:
drm/i915 fixes for v6.7-rc3:
- Fix race between DP MST connectore registration and setup
- Fix GT memory leak on probe error path
BR,
Jani.
The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263:
Linux 6.7-rc2 (2023-11-19 15:
Hi,
On 2023/11/23 16:08, Dmitry Baryshkov wrote:
The host can not specify the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And
it can not omit the flag (as otherwise the first bridge will create a
connector, without consulting the second bridge).
The semantics of DRM_BRID
1 - 100 of 174 matches
Mail list logo
