Hi Ilia,
On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin wrote:
> On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> wrote:
> > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > index 953bf95492ee150c..42d75d700700dc3d 100644
> > --- a/tests/util/pattern.c
> > +++
On Tue, Mar 8, 2022 at 12:20 AM Robert Foss wrote:
>
> Signed-off-by: Robert Foss
Reviewed-by: Chen-Yu Tsai
I think we need to send this directly to the soc maintainers to get it
picked up before the final 5.17 release?
>
> On Mon, 7 Mar 2022 at 16:46, Robert Foss wrote:
> >
> > This
Hi :
On 3/5/22 07:55, Dmitry Osipenko wrote:
On 3/4/22 17:22, Sascha Hauer wrote:
On Wed, Mar 02, 2022 at 12:25:28PM +0100, Sascha Hauer wrote:
On Tue, Mar 01, 2022 at 01:39:31PM +, Robin Murphy wrote:
On 2022-02-28 14:19, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 02:11:54PM +0100,
On Sat, Mar 05, 2022 at 10:49:05PM +0100, Krzysztof Kozlowski wrote:
> On 04/03/2022 01:03, Joel Stanley wrote:
> > Convert the bindings to yaml and add the ast2600 compatible string.
> >
> > The legacy mfd description was put in place before the gfx bindings
> > existed, to document the
On Fri, 04 Mar 2022 01:24:56 +0100, Marek Vasut wrote:
> It is necessary to specify the number of connected/used DSI data lanes when
> using the DSI input port of this bridge. Document the 'data-lanes' property
> of the DSI input port.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc:
Hi,
On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
wrote:
>
> @@ -1264,6 +1321,14 @@ static int ti_sn_bridge_probe(struct auxiliary_device
> *adev,
> return PTR_ERR(pdata->next_bridge);
> }
>
> + pdata->no_hpd = of_property_read_bool(np, "no-hpd");
> + if
Hi,
On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
wrote:
>
> From: Laurent Pinchart
>
> Despite the SN65DSI86 being an eDP bridge, on some systems its output is
> routed to a DisplayPort connector. Enable DisplayPort mode when the next
> component in the display pipeline is detected as a
Hi,
On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
wrote:
>
> From: Laurent Pinchart
>
> Now that the driver supports the connector-related bridge operations,
> make the connector creation optional. This enables usage of the
> sn65dsi86 with the DRM bridge connector helper.
>
> Signed-off-by:
On Thu, 03 Mar 2022 14:57:24 +0800, Rex-BC Chen wrote:
> Add MT8186 SoC binding to AAL, CCORR, COLOR, DITHER, GAMMA, MUTEX,
> OVL, POSTMASK and RDMA.
>
> Signed-off-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 4
>
On Thu, 03 Mar 2022 14:57:23 +0800, Rex-BC Chen wrote:
> All single entry cases in mutex can be merged as a single enum.
>
> Signed-off-by: Rex-BC Chen
> ---
> .../display/mediatek/mediatek,mutex.yaml | 24 +++
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
On Thu, 03 Mar 2022 14:57:22 +0800, Rex-BC Chen wrote:
> There won't be more than 1 fallback for these bindings, so we modify
> them to use const instead of enum.
>
> Signed-off-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 3 +--
>
On Thu, 03 Mar 2022 14:57:21 +0800, Rex-BC Chen wrote:
> Add aal binding for MT8183.
>
> Signed-off-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
From: Christoph Hellwig
> Sent: 07 March 2022 15:57
>
> On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > So what would you suggest to sort out the issue? I'm happy to go with
> > ioctl if nothing else is acceptable.
>
> PLenty of drivers treat all mmaps as if MAP_POPULATE was
Don't populate the read-only array div1_vals on the stack but
instead make it static const. Also makes the object code a little
smaller.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven wrote:
> diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> index 953bf95492ee150c..42d75d700700dc3d 100644
> --- a/tests/util/pattern.c
> +++ b/tests/util/pattern.c
> @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
>
On Mon, Mar 7, 2022 at 8:07 PM Sam Ravnborg wrote:
>
> Hi Thomas,
>
> One comment below.
>
> On Sun, Mar 06, 2022 at 09:36:15PM +0100, Thomas Zimmermann wrote:
> > The current implementation of psb_gtt_init() also does resume
> > handling. Move the resume code into its own helper.
> >
> >
Hi all,
When starting to use modetest, I was a bit surprised to discover the
default XR24 format wasn't displayed correctly on my work-in-progress
Atari DRM driver, which runs on a big-endian system.
This RFC patch series fixes some endianness issues in libdrm.
It has been tested on
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
does define __sparc__, hence replace the check for SPARC by a check
for __sparc__,
- powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
but does define __BIG_ENDIAN__.
DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel
values need to take endianness into account.
Introduce a cpu_to_le32() helper to convert 32-bit values from
CPU-endian to little-endian, and use them in the various pattern
Traditionally, the first channel has been called the "red" channel, but
the fourcc values for single-channel "red" formats can also be used for
other light-on-dark displays, like grayscale.
Signed-off-by: Geert Uytterhoeven
---
RFC, as I have no immediate need for these formats.
v2:
- New.
Introduce fourcc codes for single-channel light-on-dark frame buffer
formats with two, four, and sixteen intensity levels.
As the number of bits per pixel is less than eight, these rely on proper
block handling for the calculation of bits per pixel and pitch.
Signed-off-by: Geert Uytterhoeven
As Rn is light-on-dark, and Cn can be any colors, there are currently
no fourcc codes to describe dark-on-light displays.
Introduce fourcc codes for a single-channel dark-on-light frame buffer
format with two, four, sixteen, or 256 darkness levels.
As the number of bits per pixel may be less
Hi all,
A long outstanding issue with the DRM subsystem has been the lack of
support for low-color displays, as used typically on older desktop
systems, and on small embedded displays.
This patch series adds support for color-indexed frame buffer formats
with 2, 4, and 16 colors. It has
Add a helper to retrieve the actual number of bits per pixel for a
plane, taking into account the number of characters and pixels per
block for tiled formats.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Move up.
---
drivers/gpu/drm/drm_fourcc.c | 19 +++
Introduce fourcc codes for color-indexed frame buffer formats with two,
four, and sixteen colors, and provide a mapping from bit per pixel and
depth to fourcc codes.
As the number of bits per pixel is less than eight, these rely on proper
block handling for the calculation of bits per pixel and
Add a flag to struct drm_format_info to indicate if a format is
color-indexed, similar to the existing .is_yuv flag.
This way generic code and drivers can just check this flag, instead of
checking against a list of fourcc formats.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
When userspace queries the properties of a frame buffer, the number of
bits per pixel is derived from the deprecated drm_format_info.cpp[]
field, which does not take into account block sizes.
Fix this by using the actual number of bits per pixel instead.
Signed-off-by: Geert Uytterhoeven
---
Add support for drawing the SMPTE pattern in a buffer using the C4
indexed format.
Note that this still uses 256 instead of 16 as the CLUT size, as
DRM_IOCTL_MODE_SETGAMMA enforces that the size matches against the
(fixed) gamma size, while the CLUT size depends on the format.
Signed-off-by:
The color LUT for the SMPTE pattern in indexed mode contains 22 entries,
although only 13 are non-unique.
Reduce the size of the color LUT by dropping duplicate entries, so it
can be reused for formats supporting e.g. 16 colors. Rename
util_smpte_c8_gamma() to util_smpte_index_gamma()
Add fourcc codes for color-indexed frame buffer formats with two, four,
and sixteen colors. Add support for creating buffers using these
formats.
Signed-off-by: Geert Uytterhoeven
---
include/drm/drm_fourcc.h | 5 -
tests/modetest/buffers.c | 15 +++
tests/util/format.c |
Add support for color-indexed frame buffer formats with two, four, and
sixteen colors to the DRM framebuffer helper functions:
1. Add support for 1, 2, and 4 bits per pixel to the damage helper,
2. For color-indexed modes, the length of the color bitfields must be
set to the color depth,
The AFBC helpers derive the number of bits per pixel from the deprecated
drm_format_info.cpp[] field, which does not take into account block
sizes.
Fix this by using the actual number of bits per pixel instead.
Signed-off-by: Geert Uytterhoeven
---
RFC, as this code path was untested.
v2:
-
Hi all,
A long outstanding issue with the DRM subsystem has been the lack of
support for low-color displays, as used typically on older desktop
systems, and on small embedded displays.
This patch series adds support for color-indexed frame buffer formats
with 2, 4, and 16 colors. It has
When allocating a frame buffer, the number of bits per pixel needed is
derived from the deprecated drm_format_info.cpp[] field. While this
works for formats using less than 8 bits per pixel, it does lead to a
large overallocation.
Reduce memory consumption by using the actual number of bits per
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm
The first patch is a drm core patch that replaces the for loop in
drm_mm_insert_node_in_range() with the iterator and would not
cause any functional changes. The second patch is a i915 driver
specific patch that also uses the iterator but solves a different
problem.
v2:
- Added a new patch to
VM_BIND und related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 176 +++
1 file changed, 176 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
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: Updated design and uapi, more documentation.
Signed-off-by: Niranjana Vishwanathapura
Niranjana Vishwanathapura (2):
drm/doc/rfc: VM_BIND feature
VM_BIND design document with description of intended use cases.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.rst | 210 +
Documentation/gpu/rfc/index.rst| 4 +
2 files changed, 214 insertions(+)
create mode 100644
On 07.03.2022 00:04, Andi Shyti wrote:
Hi Andrzej,
[...]
+bool is_object_gt(struct kobject *kobj)
+{
+ return !strncmp(kobj->name, "gt", 2);
+}
It looks quite fragile, at the moment I do not have better idea:) maybe
after reviewing the rest of the patches.
yeah... it's not pretty,
Hi Dave, Daniel,
Same PR as last week, just fixed up a bad Fixes tag.
The following changes since commit 38a15ad9488e21cad8f42d3befca20f91e5b2874:
Merge tag 'amd-drm-next-5.18-2022-02-25' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-03-01 16:19:02
+1000)
are available
Hi,
On Mon, Mar 7, 2022 at 10:00 AM Kieran Bingham
wrote:
>
> From: Laurent Pinchart
>
> Implement the bridge connector-related .get_edid() operation, and report
> the related bridge capabilities and type.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Stephen Boyd
> Reviewed-by: Douglas
On Mon, 7 Mar 2022 at 18:41, Ville Syrjälä
wrote:
>
> On Mon, Mar 07, 2022 at 06:26:32PM +, Matthew Auld wrote:
> > On 07/03/2022 17:06, Ville Syrjälä wrote:
> > > On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote:
> > >> On 04/03/2022 19:33, Ville Syrjälä wrote:
> > >>> On Fri,
Hi Thomas,
One comment below.
On Sun, Mar 06, 2022 at 09:36:15PM +0100, Thomas Zimmermann wrote:
> The current implementation of psb_gtt_init() also does resume
> handling. Move the resume code into its own helper.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/gma500/gtt.c
On Mon, Mar 07, 2022 at 06:26:32PM +, Matthew Auld wrote:
> On 07/03/2022 17:06, Ville Syrjälä wrote:
> > On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote:
> >> On 04/03/2022 19:33, Ville Syrjälä wrote:
> >>> On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote:
> The
On 07/03/2022 17:06, Ville Syrjälä wrote:
On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote:
On 04/03/2022 19:33, Ville Syrjälä wrote:
On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote:
The offset we get looks to be the exact start of DSM, but the
inital_plane_vma
The pointer connector is being assigned a value that is never read,
it is being re-assigned in the following statement. The assignment
is redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/rockchip/rockchip_rgb.c:153:2: warning: Value stored
to 'connector' is never
Hi Paul, it should in theory, but doesn't work in practice, the
display doesn't like having that bit set outside of the init sequence.
Feel free to experiment if you think you can make it work though, you
should have that panel on 1 or 2 devices I think.
KR
CB
On Wed, Mar 2, 2022 at 12:22 PM
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() operation, and report
the related bridge capabilities and type.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Signed-off-by: Kieran Bingham
---
Changes since v1:
- The
When the SN65DSI86 is used in DisplayPort mode, its output is likely
routed to a DisplayPort connector, which can benefit from hotplug
detection. Support it in such cases, with polling mode only for now.
The implementation is limited to the bridge operations, as the connector
operations are
From: Laurent Pinchart
Now that the driver supports the connector-related bridge operations,
make the connector creation optional. This enables usage of the
sn65dsi86 with the DRM bridge connector helper.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v1:
-
From: Laurent Pinchart
Despite the SN65DSI86 being an eDP bridge, on some systems its output is
routed to a DisplayPort connector. Enable DisplayPort mode when the next
component in the display pipeline is detected as a DisplayPort
connector, and disable eDP features in that case.
Implement support for non eDP connectors on the TI-SN65DSI86 bridge, and
provide IRQ based hotplug detect to identify when the connector is
present.
no-hpd is extended to be the default behaviour for non DisplayPort
connectors.
This series is based on top of José Expósito's patch [0]
On Mon, Mar 7, 2022 at 11:11 AM Laurent Pinchart
wrote:
>
> On Mon, Mar 07, 2022 at 05:57:47PM +0100, Robert Foss wrote:
> > On Mon, 7 Mar 2022 at 17:38, Rob Herring wrote:
> > >
> > > On Mon, Mar 07, 2022 at 04:45:57PM +0100, Robert Foss wrote:
> > > > This reverts commit
On Mon, Mar 07, 2022 at 05:57:47PM +0100, Robert Foss wrote:
> On Mon, 7 Mar 2022 at 17:38, Rob Herring wrote:
> >
> > On Mon, Mar 07, 2022 at 04:45:57PM +0100, Robert Foss wrote:
> > > This reverts commit a43661e7e819b100e1f833a35018560a1d9abb39.
> >
> > S-o-b and reason for the revert?
> >
> >
On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote:
> On 04/03/2022 19:33, Ville Syrjälä wrote:
> > On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote:
> >> The offset we get looks to be the exact start of DSM, but the
> >> inital_plane_vma expects the address to be relative.
>
[+virtualization list, which I forgot to CC when posting v5]
Hi Thomas, other x86 maintainers,
On 2/25/22 2:23 PM, Srivatsa S. Bhat wrote:
> This series updates a few maintainer entries for VMware-maintained
> subsystems and cleans up references to VMware's private mailing lists
> to make it
On Mon, 7 Mar 2022 at 17:38, Rob Herring wrote:
>
> On Mon, Mar 07, 2022 at 04:45:57PM +0100, Robert Foss wrote:
> > This reverts commit a43661e7e819b100e1f833a35018560a1d9abb39.
>
> S-o-b and reason for the revert?
>
> > ---
> > .../display/bridge/analogix,anx7625.yaml | 65
Ah Thanks for the great feedback!
@Lucas or @Matt, could you please chime in?
Michael Cheng
On 2022-03-02 11:10 a.m., Robin Murphy wrote:
On 2022-03-02 15:55, Michael Cheng wrote:
Thanks for the feedback Robin!
Sorry my choices of word weren't that great, but what I meant is to
understand
On Mon, Mar 07, 2022 at 05:14:59PM +0100, Christian König wrote:
> Pushed to drm-misc-next. Just one nit below.
>
> Am 07.03.22 um 15:54 schrieb Arunpravin:
> > Reviewed-by:Arunpravin
>
> Some people are picky about using the full name here.
>
Signed-off-by is like signing a legal document to
On Mon, Mar 07, 2022 at 04:45:58PM +0100, Robert Foss wrote:
> This reverts commit 32568ae37596b529628ac09b875f4874e614f63f.
> ---
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On 07/03/2022 14:37, Arunpravin wrote:
place BUG_ON(order < min_order) outside do..while
loop as it fails Unigine Heaven benchmark.
Unigine Heaven has buffer allocation requests for
example required pages are 161 and alignment request
is 128. To allocate the remaining 33 pages, continues
the
On Mon, Mar 07, 2022 at 04:45:57PM +0100, Robert Foss wrote:
> This reverts commit a43661e7e819b100e1f833a35018560a1d9abb39.
S-o-b and reason for the revert?
> ---
> .../display/bridge/analogix,anx7625.yaml | 65 +--
> 1 file changed, 2 insertions(+), 63 deletions(-)
>
>
From: Zack Rusin
SVGAv3 deprecates legacy interrupts and adds support for MSI/MSI-X. With
MSI the driver visible side remains largely unchanged but with MSI-X
each interrupt gets delivered on its own vector.
Add support for MSI/MSI-X while preserving the old functionality for
SVGAv2. Code
On Mon, 7 Mar 2022 at 19:05, Vinod Polimera wrote:
>
> > WARNING: This email originated from outside of Qualcomm. Please be wary
> > of any links or attachments, and do not enable macros.
> >
> > On Sat, 5 Mar 2022 at 00:49, Doug Anderson
> > wrote:
> > > On Thu, Mar 3, 2022 at 4:16 PM Dmitry
On Sun, Mar 6, 2022 at 9:36 PM Thomas Zimmermann wrote:
>
> Refactor and simplify various parts of the memory management. This
> includes locking, initialization and finalizer functions, and code
> organization.
>
> Tested on Atom N2800 hardware.
Hi Thomas, nice cleanups!
All patches are:
On Mon, 7 Mar 2022 at 16:46, Robert Foss wrote:
>
> This reverts commit a43661e7e819b100e1f833a35018560a1d9abb39.
> ---
> .../display/bridge/analogix,anx7625.yaml | 65 +--
> 1 file changed, 2 insertions(+), 63 deletions(-)
>
> diff --git
>
Signed-off-by: Robert Foss
On Mon, 7 Mar 2022 at 16:46, Robert Foss wrote:
>
> This reverts commit 32568ae37596b529628ac09b875f4874e614f63f.
> ---
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
Reviewed-by: Simon Ser
On Mon, Mar 07, 2022 at 06:30:18PM +0530, Naresh Kamboju wrote:
> drivers/gpu/drm/mediatek/mtk_dsi.c: In function 'mtk_dsi_host_attach':
> drivers/gpu/drm/mediatek/mtk_dsi.c:858:28: error: implicit declaration
> of function 'devm_drm_of_get_bridge'; did you mean
> 'devm_drm_panel_bridge_add'?
Pushed to drm-misc-next. Just one nit below.
Am 07.03.22 um 15:54 schrieb Arunpravin:
Reviewed-by:Arunpravin
Some people are picky about using the full name here.
And you I think we should volunteer you for maintaining that stuff :)
So you might want to get commit rights for drm-misc-next
From: Geert Uytterhoeven
Fix various grammar mistakes in the kerneldoc comments documenting the
drm_mode_fb_cmd2 structure:
- s/is/are/,
- s/8 bit/8-bit/.
Signed-off-by: Geert Uytterhoeven
Acked-by: Sam Ravnborg
---
v2:
- Add Acked-by,
- Rebase on top of commit a3574119826d9a4e ("drm:
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> On Sat, 5 Mar 2022 at 00:49, Doug Anderson
> wrote:
> > On Thu, Mar 3, 2022 at 4:16 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On Fri, 4 Mar 2022 at 02:56,
On Mon, Mar 07, 2022 at 07:56:53AM -0800, Christoph Hellwig wrote:
> On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > So what would you suggest to sort out the issue? I'm happy to go with
> > ioctl if nothing else is acceptable.
>
> PLenty of drivers treat all mmaps as if
>
> From: Benoit Parrot
>
> If the drm_plane has a source width that's greater than the max width
> supported by a single hw overlay, then we assign a 'r_overlay' to it in
> omap_plane_atomic_check().
>
> Both overlays should have the capabilities required to handle the source
> framebuffer.
Am 07.03.22 um 15:37 schrieb Arunpravin:
place BUG_ON(order < min_order) outside do..while
loop as it fails Unigine Heaven benchmark.
Unigine Heaven has buffer allocation requests for
example required pages are 161 and alignment request
is 128. To allocate the remaining 33 pages, continues
the
Hi Rob,
Thank you for the patch.
On Mon, Mar 07, 2022 at 04:45:56PM +0100, Robert Foss wrote:
> An issue[1] related to how the V4L2_FWNODE_BUS_TYPE_PARALLEL flag is mis-used
> was found in recent addition to the anx7625 driver.
>
> In order to not introduce this issue into the ABI, let's revert
On Mon, Mar 07, 2022 at 03:33:52PM +0100, David Hildenbrand wrote:
> On 07.03.22 15:22, Jarkko Sakkinen wrote:
> > On Mon, Mar 07, 2022 at 11:12:44AM +0100, David Hildenbrand wrote:
> >> On 06.03.22 06:32, Jarkko Sakkinen wrote:
> >>> For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does
On Mon, 7 Mar 2022 at 07:12, Chen-Yu Tsai wrote:
>
> On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
> > Hello Xin,
> >
> > (Question for Rob below, and I'm afraid this is urgent as we need to
> > merge a fix in v5.17).
> >
> > On Fri, Nov 05, 2021 at 11:19:03AM +0800, Xin Ji
Moves FPU-related structs and dcn316_update_bw_bounding_box from dcn316
driver to dml/dcn31 that centralize FPU operations for DCN 3.1x
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn316/Makefile| 26 --
.../amd/display/dc/dcn316/dcn316_resource.c | 231 +-
Moves related structs and dcn315_update_bw_bounding_box from dcn315
driver code to dml/dcn31_fpu that centralizes FPU code for DCN 3.1x.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn315/Makefile| 26 --
.../amd/display/dc/dcn315/dcn315_resource.c | 232 +-
Creates FPU files in dml/dcn31 folder to centralize FPU operations
from 3.1x drivers and moves all FPU-associated code from dcn31 driver
to there. It includes the struct _vcs_dpi_ip_params_st and
_vcs_dpi_soc_bounding_box_st and functions:
- dcn31_calculate_wm_and_dlg_fp()
-
This series moves FPU code from DCN 3.1x drivers to dml/dcn31 folder to
isolate FPU operations. For this, it creates dcn31_fpu files to centralize
FPU operations and structs from dcn31x drivers, that include:
- _vcs_dpi_ip_params_st and _vcs_dpi_soc_bounding_box_st structs
-
This reverts commit 32568ae37596b529628ac09b875f4874e614f63f.
---
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
index
This reverts commit a43661e7e819b100e1f833a35018560a1d9abb39.
---
.../display/bridge/analogix,anx7625.yaml | 65 +--
1 file changed, 2 insertions(+), 63 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
An issue[1] related to how the V4L2_FWNODE_BUS_TYPE_PARALLEL flag is mis-used
was found in recent addition to the anx7625 driver.
In order to not introduce this issue into the ABI, let's revert the changes
to the anx7625 dt-binding related to this.
[1]
On Mon, Mar 07, 2022 at 07:29:22AM -0800, Dave Hansen wrote:
> On 3/7/22 03:27, Jarkko Sakkinen wrote:
> > But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets
> > filtered out and never reach that function.
> >
> > I don't know unorthodox that'd be but could we perhaps have a VM
>
On Mon, Mar 07, 2022 at 02:37:48PM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 03:41:54PM -0800, Dave Hansen wrote:
> > In short: page faults stink. The core kernel has lots of ways of
> > avoiding page faults like madvise(MADV_WILLNEED) or mmap(MAP_POPULATE).
> > But, those only work
The documentation for render nodes indicates that only "PRIME-related"
ioctls are valid on render nodes, but the documentation does not clarify
what that means. If the reader is not familiar with PRIME, they may
beleive this to be only the ioctls with "PRIME" in the name and not other
ioctls such
On 07/03/2022 13:40, Ramalingam C wrote:
On Xe-HP and later devices, dedicated compression control state (CCS)
stored in local memory is used for each surface, to support the
3D and media compression formats.
The memory required for the CCS of the entire local memory is 1/256 of
the local
On 3/7/22 03:27, Jarkko Sakkinen wrote:
> But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets
> filtered out and never reach that function.
>
> I don't know unorthodox that'd be but could we perhaps have a VM
> flag for SGX?
SGX only works on a subset of the chips from one vendor
On Wed, Mar 2, 2022 at 5:22 PM Marek Vasut wrote:
>
> On 3/2/22 15:21, Maxime Ripard wrote:
> > Hi,
>
> Hi,
>
> > Please try to avoid top posting
Sorry.
> >
> > On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote:
> >> The goal here is to set the element bus_format in the struct
>
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
On Mon, Mar 07, 2022 at 06:30:18PM +0530, Naresh Kamboju wrote:
> On Mon, 7 Mar 2022 at 15:07, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.15.27 release.
> > There are 262 patches in this series, all will be posted as a response
> > to this one. If
On 3/4/2022 6:22 AM, Rob Clark wrote:
From: Rob Clark
Some clever folks figured out a way to use performance counters as a
side-channel[1]. But, other than the special case of using the perf
counters for system profiling, we can reset the counters across context
switches to protect against
On 3/5/2022 11:04 PM, Rob Clark wrote:
From: Rob Clark
Fixes: f6d62d091cfd ("drm/msm/a6xx: add support for Adreno 660 GPU")
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Updating this API is risky because some places rely on the old behavior
and not all of them have been updated. Here are some additional places
you might want to change.
drivers/usb/host/uhci-q.c:466 link_async() warn: iterator used outside loop:
'pqh'
drivers/infiniband/core/mad.c:968
On 3/7/2022 7:01 PM, Dan Carpenter wrote:
These casts need to happen before the shift. The only time it would
matter would be if "rev.core" is >= 128. In that case the sign bit
would be extended and we do not want that.
Fixes: afab9d91d872 ("drm/msm/adreno: Expose speedbin to userspace")
On Mon, 07 Mar 2022, Arunpravin wrote:
> place BUG_ON(order < min_order) outside do..while
> loop as it fails Unigine Heaven benchmark.
>
> Unigine Heaven has buffer allocation requests for
> example required pages are 161 and alignment request
> is 128. To allocate the remaining 33 pages,
1 - 100 of 142 matches
Mail list logo
