On Thu, 2022-06-30 at 22:57 +0200, Marek Vasut wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF
> variant")
>
On Thu, 2022-06-30 at 22:57 +0200, Marek Vasut wrote:
> Update debug print to report bridge timings over connector ones.
> Drop missed comment commit from mxsfb.
>
> Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF
> variant")
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
>
On Thu, 2022-06-30 at 22:57 +0200, Marek Vasut wrote:
> Drop the crtc_ prefix from mode, consistently use the plane one.
s/plane/plain/
Otherwise:
Reviewed-by: Liu Ying
If you want to add my 'Reported-by: Liu Ying '
tag, you may add it.
>
> Fixes: 9db35bb349a0e ("drm: lcdif: Add support for
On Thu, 2022-06-30 at 22:57 +0200, Marek Vasut wrote:
> Drop unneeded headers, sort rest alphabetically, no functional
> change.
>
> Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF
> variant")
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Liu
On Thu, 2022-06-30 at 22:47 +0200, Marek Vasut wrote:
> On 6/30/22 10:30, Liu Ying wrote:
> > Hi Marek,
>
> Hi,
>
> > > drivers/gpu/drm/Makefile | 2 +-
> > > drivers/gpu/drm/mxsfb/Kconfig | 16 +
> > > drivers/gpu/drm/mxsfb/Makefile | 2 +
> > >
Rather than examining the suspend target, examine what the system is
configured to use. This should be no functional change, just improves
readability by taking the helper instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 ++--
1 file changed, 2
Drop the direct check from the FADT and use the helper instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
On Thu, Jun 30, 2022 at 05:01:01PM -0400, Rodrigo Siqueira Jordao wrote:
>
>
> On 2022-06-18 19:27, Guenter Roeck wrote:
> > ppc:allmodconfig builds fail with the following error.
> >
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >
This is the i915 driver VM_BIND feature design RFC patch series along
with the required uapi definition and description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
Remove all compute related uapi, vm_bind/unbind queue support and
only support a timeline out fence
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
documentation for
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
Reviewed-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 205
1 file changed,
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
v3: Expand documentation on dma-resv usage, TLB flushing and
execbuf3.
v4: Remove vm_bind tlb flush request support.
v5: Update TLB flushing documentation.
v6: Update out of order
Hi Rob,
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, July 1, 2022 8:18 AM
> To: ���α�/Tizen Platform Lab(SR)/�Ｚ
> Cc: 'Krzysztof Kozlowski' ; 'Seung-Woo Kim'
> ; 'Kyungmin Park'
> ; 'David Airlie' ; 'Daniel
> Vetter' ; 'Krzysztof Kozlowski'
> ;
The pull request you sent on Fri, 1 Jul 2022 09:50:09 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-07-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a175eca0f3d747599f1fdfac04cc9195b71ec996
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Linus,
Bit quieter this week, the main thing is it pulls in the fixes for the
sysfb resource issue you were seeing. these had been queued for next
so should have had some decent testing.
Otherwise amdgpu, i915 and msm each have a few fixes, and vc4 has one.
Just to reiterate, I'm out next
On Thu, Jun 30, 2022 at 4:21 PM Stephen Boyd wrote:
>
> Quoting Prashant Malani (2022-06-28 13:56:22)
> > On Tue, Jun 28, 2022 at 1:40 PM Stephen Boyd wrote:
> > >
> > > I suppose none of those things matter though as long as there is some
> > > typec switch registered here so that the driver
Quoting Hsin-Yi Wang (2022-06-30 10:33:29)
> If CONFIG_OF is not enabled, default of_get_display_timing() returns an
> errno, so include the header.
>
> Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for
> !CONFIG_OF")
> Suggested-by: Stephen Boyd
> Signed-off-by: Hsin-Yi Wang
Quoting Prashant Malani (2022-06-28 13:56:22)
> On Tue, Jun 28, 2022 at 1:40 PM Stephen Boyd wrote:
> >
> > I suppose none of those things matter though as long as there is some
> > typec switch registered here so that the driver can be informed of the
> > pin assignment. Is it right that the
On Thu, Jun 30, 2022 at 01:16:14PM +0900, ���α�/Tizen Platform Lab(SR)/�Ｚ
wrote:
>
>
> > -Original Message-
> > From: Krzysztof Kozlowski [mailto:krzysztof.kozlow...@linaro.org]
> > Sent: Monday, June 27, 2022 1:33 AM
> > To: Inki Dae ; Seung-Woo Kim
> > ; Kyungmin Park ; David
> >
On Fri, 24 Jun 2022 11:09:33 +0800, Bo-Chen Chen wrote:
> Strings replacement:
> - s/mediatek/MediaTek/ in title.
> - s/Mediatek/MediaTek/ in description.
>
> Signed-off-by: Bo-Chen Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dpi.yaml| 4 ++--
> 1 file changed, 2
On Fri, 24 Jun 2022 11:09:32 +0800, Bo-Chen Chen wrote:
> From: Markus Schneider-Pargmann
>
> DP_INTF is similar to DPI but does not have the exact same feature set
> or register layouts.
>
> DP_INTF is the sink of the display pipeline that is connected to the
> DisplayPort controller and
On Wed, Jun 29, 2022 at 07:43:34PM +0100, Conor Dooley wrote:
> From: Conor Dooley
>
> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA
> controller, but according to the documentation & devicetree it has 6
> interrupts rather than the standard one. Support the 6 interrupt
>
On Thu, 23 Jun 2022 19:56:22 +0800, ChiaEn Wu wrote:
> From: ChiYuan Huang
>
> Add mt6370 backlight binding documentation.
>
> Signed-off-by: ChiYuan Huang
> ---
>
> v3
> - Rename "mediatek,bled-pwm-hys-input-threshold-steps" to
> "mediatek,bled-pwm-hys-input-th-steps"
> - Refine
Some variables from the struct vba_vars_st are not referenced in any
other place on the codebase. As they are not used, this commit removes
those variables.
Signed-off-by: Maíra Canal
---
Unused variables from structs are not warned by compilers, so they are a bit
harder to find. In order to
On Wed, Jun 29, 2022 at 07:43:37PM +0100, Conor Dooley wrote:
> From: Conor Dooley
>
> The timers on the k210 have non standard interrupt configurations,
> which leads to dtbs_check warnings:
>
> k210_generic.dtb: timer@502d: interrupts: [[14], [15]] is too long
> From schema:
On Wed, Jun 29, 2022 at 07:43:33PM +0100, Conor Dooley wrote:
> From: Conor Dooley
>
> Most users of dw-apb-ssi use spi-{r,t}x-bus-width of 1, however the
> Canaan k210 is wired up for a width of 4.
> Quoting Serge:
> The modern DW APB SSI controllers of v.4.* and newer also support the
>
On 6/30/22 14:01, Rodrigo Siqueira Jordao wrote:
On 2022-06-18 19:27, Guenter Roeck wrote:
ppc:allmodconfig builds fail with the following error.
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
On 2022-06-18 19:27, Guenter Roeck wrote:
ppc:allmodconfig builds fail with the following error.
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".
Switch to the new function and reduce boilerplate.
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Drop the crtc_ prefix from mode, consistently use the plane one.
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Martyn Welch
Cc: Peng Fan
Cc:
Update debug print to report bridge timings over connector ones.
Drop missed comment commit from mxsfb.
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Lucas Stach
Cc: Marek Vasut
Drop unneeded headers, sort rest alphabetically, no functional change.
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Martyn Welch
Cc: Peng Fan
On 30.06.22 13:44, Alistair Popple wrote:
>
> David Hildenbrand writes:
>
>> On 29.06.22 05:54, Alex Sierra wrote:
>>> This case is used to migrate pages from device memory, back to system
>>> memory. Device coherent type memory is cache coherent from device and CPU
>>> point of view.
>>>
>>>
On 6/30/22 10:30, Liu Ying wrote:
Hi Marek,
Hi,
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/mxsfb/Kconfig | 16 +
drivers/gpu/drm/mxsfb/Makefile | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 341
drivers/gpu/drm/mxsfb/lcdif_drv.h | 44
On 6/30/22 22:22, Dmitry Osipenko wrote:
Hello Thomas,
On 6/30/22 23:15, Thomas Hellström (Intel) wrote:
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of
Hello Thomas,
On 6/30/22 23:15, Thomas Hellström (Intel) wrote:
> Hi, Dmitry,
>
> On 6/30/22 22:04, Dmitry Osipenko wrote:
>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
>> handle imported dma-bufs properly, which results in mapping of something
>> else than the imported
The function CalculateBytePerPixelAnd256BBlockSizes was defined four
times: on display_mode_vba_30.c, display_rq_dlg_calc_30.c,
display_mode_vba_31.c and display_rq_dlg_calc_31.c. In order to avoid
code duplication, the CalculateBytePerPixelAnd256BBlockSizes is defined
on display_mode_vba_30.h and
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when
userspace writes to the
On 6/30/22 22:00, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Thu, Jun 30, 2022 at 9:46 PM Helge Deller wrote:
>> On 6/30/22 21:36, Geert Uytterhoeven wrote:
>>> On Thu, Jun 30, 2022 at 9:31 PM Helge Deller wrote:
On 6/30/22 21:00, Geert Uytterhoeven wrote:
> On Wed, Jun 29, 2022 at
Unlock reservations in the error code path of virtio_gpu_object_create()
to silence debug warning splat produced by ww_mutex_destroy(>lock)
when GEM is released with the held lock.
Cc: sta...@vger.kernel.org
Fixes: 30172efbfb84 ("drm/virtio: blob prep: refactor getting pages and
attaching
Change the order of SHMEM initialization and reservation locking
to make code cleaner and to prepare for transitioning of the common
GEM SHMEM code to use the GEM's reservation lock instead of the
shmem.page_lock.
There is no need to lock reservation during allocation of the SHMEM pages
because
Don't return -1 in error cases, return proper error code. The returned
error codes propagate to error messages and to userspace and it's always
good to have a meaningful error number for debugging purposes.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 6 +++---
1
Unlock reservations on dma_resv_reserve_fences() error to fix recursive
locking of the reservations when this error happens.
Cc: sta...@vger.kernel.org
Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory
v4")
Reviewed-by: Thomas Hellström
Signed-off-by: Dmitry Osipenko
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
GPU
Use common dev_is_pci() helper to replace the strcmp("pci") used by driver.
Suggested-by: Robin Murphy
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core
wants to clean up and not the current plane's state. Normally the older
atomic state is cleaned up, but the newer state could also be cleaned up
in case of aborted commits.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry
Transferred 2D BO always must be a shmem BO. Add check for that to prevent
NULL dereference if userspace passes a VRAM BO.
Cc: sta...@vger.kernel.org
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1
This series fixes few problem found in the VirtIO-GPU driver and makes
couple improvements. The "DMA API usage improvement" patch will be needed
later on when we will be about to add memory shrinker support to the driver,
it also cleans up code nicely.
Changelog:
v7: - Factored out VirtIO fixes
Previous commit fixed checking of the ERR_PTR value returned by
drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages,
which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of
the shmem->pages.
Fixes: c24968734abf ("drm/virtio: Fix NULL vs IS_ERR checking in
Calling madvise IOCTL twice on BO causes memory shrinker list corruption
and crashes kernel because BO is already on the list and it's added to
the list again, while BO should be removed from the list before it's
re-added. Fix it.
Cc: sta...@vger.kernel.org
Fixes: 013b65101315 ("drm/panfrost: Add
When panfrost_mmu_map_fault_addr() fails, the BO's mapping should be
unreferenced and not the shmem object which backs the mapping.
Cc: sta...@vger.kernel.org
Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
This series fixes two minor bugs in the Panfrost driver.
Changelog:
v7: - Factored out Panfrost fixes from [1] since I'll be working on
the dma-buf locking in a separate patchset now.
[1]
https://lore.kernel.org/all/20220526235040.678984-1-dmitry.osipe...@collabora.com/
Dmitry Osipenko
Use ww_acquire_fini() in the error code paths. Otherwise lockdep
thinks that lock is held when lock's memory is freed after the
drm_gem_lock_reservations() error. The ww_acquire_context needs to be
annotated as "released", which fixes the noisy "WARNING: held lock freed!"
splat of VirtIO-GPU
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when
userspace writes to the memory mapping of a dma-buf that was imported into
Tegra's
This patchset fixes two problems in the common GEM code. First fixed problem
is the bogus lockdep splat that complicates debugging of DRM drivers. Second
problem is the inconsistency in behaviour and improper handling of mapping
the imported GEMs by some drivers, to fix it we will prohibit to map
The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM
mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM
before erroring out.
Cc: sta...@vger.kernel.org
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and
convert GEM backends")
drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
Correct the doc comment which says that it returns NULL on error.
Acked-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
1 file changed, 4 insertions(+), 2
This series fixes two minor problems in the DRM-SHMEM helper.
Changelog:
v7: - Factored out DRM-SHMEM fixes from [1] since I'll be working on
the dma-buf locking in a separate patchset now.
[1]
https://lore.kernel.org/all/20220526235040.678984-1-dmitry.osipe...@collabora.com/
Dmitry
Hi Helge,
On Thu, Jun 30, 2022 at 9:46 PM Helge Deller wrote:
> On 6/30/22 21:36, Geert Uytterhoeven wrote:
> > On Thu, Jun 30, 2022 at 9:31 PM Helge Deller wrote:
> >> On 6/30/22 21:00, Geert Uytterhoeven wrote:
> >>> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> The virtual
From: Ville Syrjälä
drm_crtc.h has no need for linux/i2c.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching linux/i2c.h.
Quite a few placs do currently depend on linux/i2c.h without
actually including it directly. All of those need to be
fixed up.
v2: imx and
From: Ville Syrjälä
drm_crtc.h has no need for linux/fb.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching linux/fb.h.
Quite a few placs do currently depend on linux/fb.h or other
headers pulled in by it without actually including any of it
directly. All of
From: Ville Syrjälä
drm_crtc.h has no need for linux/media-bus-format.h, so don't
include it. Avoids useless rebuilds of the entire universe when
touching linux/media-bus-format.h.
Quite a few placs do currently depend on linux/media-bus-format.h
without actually including it directly. All of
From: Ville Syrjälä
Stop using the 'TRUE' define. This ultimately gets defined by
acpi/actypes.h that gets included here via a convoluted chain of
other headers. drm_crtc.h is part of that chain, and I'm trying
to eliminate all unnecessary includes from it to avoid pointless
rebuilds.
v2: Split
From: Ville Syrjälä
Eliminate unnecessary includes from drm_crtc.h to avoid
pointless rebuilds of the entire universe when touching
some random header.
v2: Half the series already merged
Fix up a few allmodconfig fails not spotted earlier
Split the vmwgfx change into its own patch to
On 6/30/22 21:36, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Thu, Jun 30, 2022 at 9:31 PM Helge Deller wrote:
>> On 6/30/22 21:00, Geert Uytterhoeven wrote:
>>> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
The virtual screen size can't be smaller than the physical screen size.
On 6/30/22 21:09, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
>> We need to prevent that users configure a screen size which is smaller than
>> the
>> currently selected font size. Otherwise rendering chars on the screen will
>> access memory
Hi Helge,
On Thu, Jun 30, 2022 at 9:17 PM Helge Deller wrote:
> On 6/30/22 21:11, Geert Uytterhoeven wrote:
> > On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> >> Prevent that drivers configure a virtual screen resolution smaller than
> >> the physical screen resolution. This is
Hi Helge,
On Thu, Jun 30, 2022 at 9:31 PM Helge Deller wrote:
> On 6/30/22 21:00, Geert Uytterhoeven wrote:
> > On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> >> The virtual screen size can't be smaller than the physical screen size.
> >> Based on the general rule that we round up
On 6/30/22 21:00, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
>> The virtual screen size can't be smaller than the physical screen size.
>> Based on the general rule that we round up user-provided input if
>> neccessary, adjust the virtual screen
Hi Sasha,
On Tue, Jun 28, 2022 at 4:32 AM Sasha Levin wrote:
> From: Yihao Han
>
> [ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
>
> clk_put() already checks the clk ptr using !clk and IS_ERR()
While I think that is true for all clock implementations in v5.19-rc4,
it is not true
On 6/30/22 20:51, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
>> Prevent that users set a font size which is bigger than the physical screen.
>> It's unlikely this may happen (because screens are usually much larger than
>> the
>> fonts and each
Hi Helge,
On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> Use the fbcon_info_from_console() wrapper which was added to kernel
> v5.19 with commit 409d6c95f9c6 ("fbcon: Introduce wrapper for
> console->fb_info lookup").
>
> Signed-off-by: Helge Deller
Thanks for your patch!
I guess you
Hi Helge,
On Thu, Jun 30, 2022 at 9:09 PM Geert Uytterhoeven wrote:
> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> > We need to prevent that users configure a screen size which is smaller than
> > the
> > currently selected font size. Otherwise rendering chars on the screen will
> >
On 6/30/22 21:11, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
>> Prevent that drivers configure a virtual screen resolution smaller than
>> the physical screen resolution. This is important, because otherwise we
>> may access memory outside of
Hi Helge,
On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> Prevent that drivers configure a virtual screen resolution smaller than
> the physical screen resolution. This is important, because otherwise we
> may access memory outside of the graphics memory area.
>
> Signed-off-by: Helge
Hi Naresh,
thanks for your report.
Am 30.06.22 um 18:11 schrieb Naresh Kamboju:
The following kernel warning found on Rpi4 while booting linux next-20220630.
Boot log details [1] & [2].
i think this is related to this:
https://lists.freedesktop.org/archives/dri-devel/2022-June/362244.
Hi Helge,
On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> We need to prevent that users configure a screen size which is smaller than
> the
> currently selected font size. Otherwise rendering chars on the screen will
> access memory outside the graphics memory region.
> This patch adds a
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
> When converting from .txt to .yaml we missed this one.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Signed-off-by: Bryan O'Donoghue
>
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> Add in missing clock and clock-names declarations to the 28nm DSI PHY.
> When converting from .txt to .yaml we missed these.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Signed-off-by: Bryan O'Donoghue
>
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml dt-binding descriptions we appear to
> have missed some of the previous detail on the number and names of
> permissible clocks.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
On 30/06/2022 19:30, Bryan O'Donoghue wrote:
> On 30/06/2022 18:16, Dmitry Baryshkov wrote:
>>
>> All three descriptions are the same. This looks like a c issue
>
> Those are what the previous values were.
>
No, original TXT had different descriptions:
-- vdd-supply: phandle to vdd regulator
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml we didn't include descriptions for the
> existing regulator supplies.
>
> - vdd
> - vdda
> - vddio
>
> Add those descriptions into the yaml now as they were prior to the
> conversion.
>
> Fixes: 4dbe55c97741
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> The existing msm8916.dtsi does not depend on nor require power-domains.
> Drop from the list of required.
That's not good reason. The bindings are about hardware so the question
is whether being a part of power domain or toggling power domain on/off
Hi Helge,
On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> The virtual screen size can't be smaller than the physical screen size.
> Based on the general rule that we round up user-provided input if
> neccessary, adjust the virtual screen size as well if needed.
>
> Signed-off-by: Helge
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> The existing msm8916.dtsi does not depend on nor require operating points.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Signed-off-by: Bryan O'Donoghue
> ---
Acked-by: Krzysztof Kozlowski
Best
On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> The driver doesn't care about the name of the phy in DTS. msm8916 has since
> 2016 named the phy "dsi-phy" with later SoCs taking the name "dsi".
>
> There's no reason to have a constraint on the name here, simply to have a
> name. Remove the
The function Calculate256BBlockSizes always returns true, regardless of
the parameters. As any file checks the return of the function, this
commit changes the return value to void.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 3 +--
Hi Helge,
On Wed, Jun 29, 2022 at 10:00 PM Helge Deller wrote:
> Prevent that users set a font size which is bigger than the physical screen.
> It's unlikely this may happen (because screens are usually much larger than
> the
> fonts and each font char is limited to 32x32 pixels), but it may
On 6/30/22 4:40 PM, Mark Brown wrote:
> On Thu, Jun 30, 2022 at 08:47:54AM +0530, Vijendar Mukunda wrote:
>
>> +static int st_es8336_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params)
>> +{
>> +int ret = 0;
>> +struct
On Thu, Jun 30, 2022 at 10:45:12AM -0500, Jason Ekstrand wrote:
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura
wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
On Thu, Jun 30, 2022 at 10:12:47AM -0700, Zanoni, Paulo R wrote:
On Thu, 2022-06-30 at 09:18 -0700, Niranjana Vishwanathapura wrote:
On Wed, Jun 29, 2022 at 11:39:52PM -0700, Zanoni, Paulo R wrote:
> On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> > On Wed, Jun 29, 2022 at
On 6/30/22 4:41 PM, Mark Brown wrote:
> On Thu, Jun 30, 2022 at 08:47:55AM +0530, Vijendar Mukunda wrote:
>
>> +depends on SND_SOC_AMD_ACP && I2C && ACPI
>
> The code treated ACPI as optional so you could relax the ACPI dependency
> ot be "ACPI || COMPILE_TEST" (I think the same applies to
ed any of this in
> >>> action. Since I sent v1, I tried to buy some since it's cheap - but could
> >>> out of the limited stockists none seemed to want to deliver to Ireland :(
> >>> I based the series on next-20220617.
> >>>
> >>
> >> I
nce I sent v1, I tried to buy some since it's cheap - but could
> > out of the limited stockists none seemed to want to deliver to Ireland :(
> > I based the series on next-20220617.
> >
>
> I first tried to apply your series on top of next-20220630,
> but was greeted b
The DE inversion is implemented in LCDIFv3 driver and is no longer
needed in the LDB bridge which does not invert the DE signal. Drop
the inversion.
Fixes: 463db5c2ed4ae ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB
bridge")
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc:
If CONFIG_OF is not enabled, default of_get_display_timing() returns an
errno, so include the header.
Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF")
Suggested-by: Stephen Boyd
Signed-off-by: Hsin-Yi Wang
---
include/video/of_display_timing.h | 2 ++
1 file
Hello Sam,
On 5/29/22 21:05, Svyatoslav Ryhel wrote:
> This series adds support for Sharp LQ101R1SX03 and HannStar HSD101PWW2
> display panels that are used by Asus Transformer tablets, which we're
> planning to support since 5.17 kernel.
The tablets now supported since 5.17 and awaiting for the
On 30 June 2022 15:08:43 GMT+03:00, Bryan O'Donoghue
wrote:
>When converting from .txt to .yaml dt-binding descriptions we appear to
>have missed some of the previous detail on the number and names of
>permissible clocks.
>
>Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for
On 30 June 2022 15:08:44 GMT+03:00, Bryan O'Donoghue
wrote:
>Add in missing clock and clock-names declarations to the 28nm DSI PHY.
>When converting from .txt to .yaml we missed these.
>
>Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
>bindings")
>Signed-off-by: Bryan
On 30 June 2022 15:08:42 GMT+03:00, Bryan O'Donoghue
wrote:
>When converting from .txt to .yaml we didn't include descriptions for the
>existing regulator supplies.
>
>- vdd
>- vdda
>- vddio
>
>Add those descriptions into the yaml now as they were prior to the
>conversion.
>
>Fixes:
1 - 100 of 171 matches
Mail list logo
