Add VM_PFNMAP to vm_flags in the mmap handler to ensure that
the mappings would be managed without using struct page.
And, in the vm_fault handler, use vmf_insert_pfn to share the
page's pfn to userspace instead of directly sharing the page
(via struct page *).
Cc: David Hildenbrand
Cc: Daniel
Since the memfd pages associated with a udmabuf may be migrated
as part of udmabuf create, we need to verify the data coherency
after successful migration. The new tests added in this patch try
to do just that using 4k sized pages and also 2 MB sized huge
pages for the memfd.
Successful
For drivers that would like to longterm-pin the folios associated
with a memfd, the memfd_pin_folios() API provides an option to
not only pin the folios via FOLL_PIN but also to check and migrate
them if they reside in movable zone or CMA block. This API
currently works with memfds but it should
Using memfd_pin_folios() will ensure that the pages are pinned
correctly using FOLL_PIN. And, this also ensures that we don't
accidentally break features such as memory hotunplug as it would
not allow pinning pages in the movable zone.
Using this new API also simplifies the code as we no longer
This is mainly a preparatory patch to use memfd_pin_folios() API
for pinning folios. Using folios instead of pages makes sense as
the udmabuf driver needs to handle both shmem and hugetlb cases.
And, using the memfd_pin_folios() API makes this easier as we no
longer need to separately handle shmem
A user or admin can configure a VMM (Qemu) Guest's memory to be
backed by hugetlb pages for various reasons. However, a Guest OS
would still allocate (and pin) buffers that are backed by regular
4k sized pages. In order to map these buffers and create dma-bufs
for them on the Host, we first need
Currently, some drivers (e.g, Udmabuf) that want to longterm-pin
the pages/folios associated with a memfd, do so by simply taking a
reference on them. This is not desirable because the pages/folios
may reside in Movable zone or CMA block.
Therefore, having drivers use memfd_pin_folios() API
This helper is the folio equivalent of check_and_migrate_movable_pages().
Therefore, all the rules that apply to check_and_migrate_movable_pages()
also apply to this one as well. Currently, this helper is only used by
memfd_pin_folios().
This patch also includes changes to rename and convert the
From: Arnd Bergmann
There is no !CONFIG_MMU version of vmf_insert_pfn():
arm-linux-gnueabi-ld: drivers/dma-buf/udmabuf.o: in function `udmabuf_vm_fault':
udmabuf.c:(.text+0xaa): undefined reference to `vmf_insert_pfn'
Fixes: d1d00dd1fd2f ("udmabuf: use vmf_insert_pfn and VM_PFNMAP for handling
These helpers are the folio versions of unpin_user_page/unpin_user_pages.
They are currently only useful for unpinning folios pinned by
memfd_pin_folios() or other associated routines. However, they could
find new uses in the future, when more and more folio-only helpers
are added to GUP.
We
>
> Following up to see if anything else is needed from me.
> Hoping to see this in linux-next :)
I just pushed this into drm-next.
Thanks,
Dave.
On Sun, Jun 23, 2024 at 01:11:48PM +0200, Krzysztof Kozlowski wrote:
> On 23/06/2024 13:06, Akhil P Oommen wrote:
> > This series adds support for the Adreno X1-85 GPU found in Qualcomm's
> > compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
> > naming scheme for Adreno GPU, 'X'
Hi,
On 15/03/24 22:50, Rob Clark wrote:
On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula wrote:
On Thu, 14 Mar 2024, Rob Clark wrote:
When we first merged drm/ci I was unsure if it would need it's own
-next branch. But after using it for a couple releases, a few times
I've found myself wanting
On Mon, Jun 24, 2024 at 03:30:29AM GMT, Caleb Connolly wrote:
> This is a 1080x2400 120hz panel used on the OnePlus 8T. It uses DSC but
> uses non-standard DCS commands.
Please add a note regarding the panel using long packets for all the
commands.
Also the cover letter had a mention of the
On Mon, Jun 24, 2024 at 03:30:28AM GMT, Caleb Connolly wrote:
> Some panels like the Samsung AMB655X use long write commands for all
> non-standard messages and do not work when trying to use the appropriate
> command type.
>
> Support these panels by introducing a new helper to send commands of
On Mon, Jun 24, 2024 at 03:30:24AM GMT, Caleb Connolly wrote:
> Add bindings for the SM8250 OnePlus devices, a common devicetree,
> touchscreen and display drivers, and a dts for the OnePlus 8T (kebab).
>
> The OnePlus 8 series is made up of 3 flagship smartphones from 2019,
> featuring the
On 24/06/2024 03:30, Caleb Connolly wrote:
> Add bindings for the OnePlus 8, 8 Pro, and 8T devices.
>
> Signed-off-by: Caleb Connolly
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Use of macro ARRAY_SIZE to calculate array size minimizes
the redundant code and improves code reusability.
./drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c:164:45-46: WARNING: Use
ARRAY_SIZE.
./drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c:183:47-48: WARNING: Use
ARRAY_SIZE.
On Mon, 24 Jun 2024 03:30:26 +0200, Caleb Connolly wrote:
> Document the Synaptics TCM oncell series of touchscreens, starting with
> the s3908.
>
> Signed-off-by: Caleb Connolly
> ---
> .../input/touchscreen/syna,tcm-oncell.yaml | 66
> ++
> 1 file changed, 66
The function are defined in the ltdc.c file, but not called
anywhere, so delete the unused function.
drivers/gpu/drm/stm/ltdc.c:494:35: warning: unused function 'encoder_to_ltdc'.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9403
Signed-off-by: Jiapeng Chong
The function are defined in the amdgpu_dm.c file, but not called
anywhere, so delete the unused function.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:371:20: warning:
unused function 'reverse_planes_order'.
Reported-by: Abaci Robot
Closes:
Use existing swap() function rather than duplicating its implementation.
./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_pmo/dml2_pmo_dcn4_fams2.c:1171:103-104:
WARNING opportunity for swap().
./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_pmo/dml2_pmo_dcn4_fams2.c:1231:99-100:
KOE TX26D202VM0BWA panel spec indicates the DE signal is active high in
timing chart, so add DISPLAY_FLAGS_DE_HIGH flag in display timing flags.
This aligns display_timing with panel_desc.
Fixes: 8a07052440c2 ("drm/panel: simple: Add support for KOE TX26D202VM0BWA
panel")
Signed-off-by: Liu Ying
On 6/23/24 7:20 PM, Conor Dooley wrote:
On Sun, Jun 23, 2024 at 04:48:47PM +0200, Marek Vasut wrote:
On 6/22/24 1:56 PM, Conor Dooley wrote:
On Fri, Jun 21, 2024 at 05:53:53PM +0200, Marek Vasut wrote:
Document default DP port preemphasis configurable via new DT property
On 6/21/24 21:31, Mina Almasry wrote:
On Mon, Jun 17, 2024 at 9:36 AM Pavel Begunkov wrote:
On 6/13/24 02:35, Mina Almasry wrote:
The pages awaiting freeing are stored in the newly added
sk->sk_user_frags, and each page passed to userspace is get_page()'d.
This reference is dropped once the
On 6/21/24 19:48, Mina Almasry wrote:
On Mon, Jun 17, 2024 at 7:17 AM Pavel Begunkov wrote:
...
static inline unsigned long netmem_to_pfn(netmem_ref netmem)
{
+ if (netmem_is_net_iov(netmem))
+ return 0;
IIRC 0 is a valid pfn. Not much of a concern since it's
used only
Remove MDP_CAP_SRC_SPLIT from msm8x53_config because
it is not referenced in downstream.
Fixes: fb25d4474fa0 ("drm/msm/mdp5: Add configuration for MDP v1.16")
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
On Sun, Jun 23, 2024 at 10:30:37PM GMT, Barnabás Czémán wrote:
> From: Daniil Titov
>
> Add the mdp5_cfg_hw entry for MDP5 version v1.14 found on msm8937.
>
> Signed-off-by: Daniil Titov
> Signed-off-by: Barnabás Czémán
> ---
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 88
>
On Sun, Jun 23, 2024 at 01:11:48PM GMT, Krzysztof Kozlowski wrote:
> On 23/06/2024 13:06, Akhil P Oommen wrote:
> > This series adds support for the Adreno X1-85 GPU found in Qualcomm's
> > compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
> > naming scheme for Adreno GPU, 'X'
On Sun, Jun 23, 2024 at 04:36:30PM GMT, Akhil P Oommen wrote:
> Add the necessary dt nodes for gpu support in X1E80100.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 195 +
> 1 file changed, 195 insertions(+)
>
> diff --git
On Sun, Jun 23, 2024 at 04:36:29PM GMT, Akhil P Oommen wrote:
> Add support in drm/msm driver for the Adreno X185 gpu found in
> Snapdragon X1 Elite chipset.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 19 +++
>
On Sun, Jun 23, 2024 at 12:48:53PM GMT, Barnabás Czémán wrote:
> On Sun, Jun 23, 2024 at 7:59 AM Dmitry Baryshkov
> wrote:
> >
> > On Sun, Jun 23, 2024 at 01:25:52AM GMT, Barnabás Czémán wrote:
> > > From: Daniil Titov
> > >
> > > Add the mdp5_cfg_hw entry for MDP5 version v1.14 found on
On Sun, Jun 23, 2024 at 07:17:09AM GMT, Keith Zhao wrote:
> Hi Dmitry:
>
> > On Tue, May 21, 2024 at 06:58:17PM +0800, keith wrote:
> > > +
> > > "starfive,syscon",
> > > + 2,
On Sun, Jun 23, 2024 at 07:16:57AM GMT, Keith Zhao wrote:
> > On Tue, May 21, 2024 at 06:58:15PM +0800, keith wrote:
> > > Add vs DRM master driver for JH7110 SoC ADD DMA GEM driver
> > >
> > > Signed-off-by: keith
> > > ---
> > > drivers/gpu/drm/verisilicon/Makefile | 3 +-
> > >
On Sun, Jun 23, 2024 at 03:40:06PM -0500, Bjorn Andersson wrote:
> On Sun, Jun 23, 2024 at 08:46:30PM GMT, Akhil P Oommen wrote:
> > On Sun, Jun 23, 2024 at 02:53:17PM +0200, Krzysztof Kozlowski wrote:
> > > On 23/06/2024 14:28, Akhil P Oommen wrote:
> > > > On Sun, Jun 23, 2024 at 01:17:16PM
On Sun, Jun 23, 2024 at 07:17:04AM GMT, Keith Zhao wrote:
> > On Tue, May 21, 2024 at 06:58:14PM +0800, keith wrote:
> > > add crtc funs and helper funs
> > >
> > > Signed-off-by: keith
> > > ---
> > > drivers/gpu/drm/verisilicon/Makefile | 3 +-
> > > drivers/gpu/drm/verisilicon/vs_crtc.c |
Hi,
On 6/23/24 10:20 PM, Mario Limonciello wrote:
> On 6/23/2024 03:51, Thomas Weißschuh wrote:
>> Panels using a PWM-controlled backlight source without an do not have a
>> standard way to communicate their valid PWM ranges.
>> On x86 the ranges are read from ACPI through driver-specific tables.
On Sun, Jun 23, 2024 at 07:17:07AM GMT, Keith Zhao wrote:
> >
> > On Tue, May 21, 2024 at 06:58:13PM +0800, keith wrote:
> > > add plane funs and helper funs
> > > add vs drm common struct and funs
> > >
> > > Signed-off-by: keith
> > > ---
> > > drivers/gpu/drm/verisilicon/Makefile | 3 +-
On Sun, Jun 23, 2024 at 07:17:01AM GMT, Keith Zhao wrote:
> Hi Dmitry:
>
> > -Original Message-
> > From: Dmitry Baryshkov
Please drop such headers from your replies. A simple "On 1st of January
John Doe wrote" is more than enough.
--
With best wishes
Dmitry
Hi Keith,
On Sun, Jun 23, 2024 at 07:16:47AM GMT, Keith Zhao wrote:
> > On Tue, May 21, 2024 at 06:58:11PM +0800, keith wrote:
> > > +}
> > > +
> > > +static inline void dc_set_clear(struct dc_hw *hw, u32 reg, u32 set, u32
> > > clear)
> > > +{
> > > + u32 value = dc_read(hw, reg);
> > > +
> > >
On Sun, Jun 23, 2024 at 08:46:30PM GMT, Akhil P Oommen wrote:
> On Sun, Jun 23, 2024 at 02:53:17PM +0200, Krzysztof Kozlowski wrote:
> > On 23/06/2024 14:28, Akhil P Oommen wrote:
> > > On Sun, Jun 23, 2024 at 01:17:16PM +0200, Krzysztof Kozlowski wrote:
> > >> On 23/06/2024 13:06, Akhil P Oommen
From: Daniil Titov
Add phy configuration for 28nm dsi phy found on MSM8937 SoC. Only
difference from existing msm8916 configuration is number of phy
and io_start addresses.
Signed-off-by: Daniil Titov
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Barnabás Czémán
---
The MSM8937 SoC uses a slightly different 28nm dsi phy. Add a new
compatible for it.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Barnabás Czémán
---
Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 1 +
Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 +
From: Daniil Titov
Add the mdp5_cfg_hw entry for MDP5 version v1.14 found on msm8937.
Signed-off-by: Daniil Titov
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 88
1 file changed, 88 insertions(+)
diff --git
Add the compatible for the MDP5 found on MSM8937.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Barnabás Czémán
---
Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
This patch series adds support for the MDP and DSI PHY as found on the
MSM8937 platform.
Signed-off-by: Barnabás Czémán
---
Changes in v2:
- Remove MDP_CAP_SRC_SPLIT from mdp5_cfg
- Link to v1: https://lore.kernel.org/r/20240623-dsi-v1-0-4ab560eb5...@gmail.com
---
Barnabás Czémán (2):
On 6/23/2024 03:51, Thomas Weißschuh wrote:
Panels using a PWM-controlled backlight source without an do not have a
standard way to communicate their valid PWM ranges.
On x86 the ranges are read from ACPI through driver-specific tables.
The built-in ranges are not necessarily correct, or may
On Fri, Jun 21, 2024 at 05:52:32PM GMT, Daniel Vetter wrote:
> On Fri, Jun 21, 2024 at 09:40:09AM -0600, Jeffrey Hugo wrote:
> > On 6/21/2024 5:19 AM, Dmitry Baryshkov wrote:
> > > On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson
> > > wrote:
> > > >
> > > > On Wed, Jun 12, 2024 at 09:28:39PM GMT,
On 23/06/2024 17:16, Akhil P Oommen wrote:
> On Sun, Jun 23, 2024 at 02:53:17PM +0200, Krzysztof Kozlowski wrote:
>> On 23/06/2024 14:28, Akhil P Oommen wrote:
>>> On Sun, Jun 23, 2024 at 01:17:16PM +0200, Krzysztof Kozlowski wrote:
On 23/06/2024 13:06, Akhil P Oommen wrote:
> Add the
We expect each schema with variable number of clocks, to have the widest
constrains in top-level "properties:". This is more readable and also
makes binding stricter, if there is no "if:then:" block for given
variant.
Acked-by: Conor Dooley
Signed-off-by: Krzysztof Kozlowski
---
dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
given binding validation if the schema contains compatible list with
pattern and a const fallback. This leads to binding being a no-op - not
being applied at all. Issue should be fixed in the dtschema but for now
add a
Regex for newer Adreno compatibles can be simpler.
Suggested-by: Conor Dooley
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
All devices should (and actually do) have same order of entries, if
possible. That's the case for reg/reg-names, so define the reg-names in
top-level to enforce that.
Acked-by: Conor Dooley
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 5 -
Changes since v1:
1. Add tags
2. New patches #3 and #4
3. Drop previous patch "dt-bindings: display/msm/gpu: constrain
reg/reg-names per variant", because I need to investigate more.
v1: dt-bindings: display/msm/gpu: constrain reg/reg-names per variant
Best regards,
Krzysztof
---
Krzysztof
The SM8150 MTP board does not have magically different GPU than the
SM8150, so it cannot use amd,imageon compatible, also pointed by
dtbs_check:
sm8150-mtp.dtb: gpu@2c0: compatible: 'oneOf' conditional failed, one must
be fixed:
['qcom,adreno-640.1', 'qcom,adreno', 'amd,imageon'] is
Commit f30ac26def18 ("arm64: dts: qcom: add sm8150 GPU nodes") re-used
amd,imageon compatible for the SM8150 just to enable headless mode due
to missing display controller nodes. This work-around was later
narrowed to the SM8150 MTP board in commit 1642ab96efa4 ("arm64: dts:
qcom: sm8150: Don't
…
> Signed-off-by: keith
Should the personal name be more unique
(according to the Developer's Certificate of Origin)?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc4#n438
…
> +++
On 6/3/2024 9:55 AM, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/agp/amd64-agp.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/agp/intel-agp.o
> WARNING: modpost: missing MODULE_DESCRIPTION()
On Sun, Jun 23, 2024 at 04:48:47PM +0200, Marek Vasut wrote:
> On 6/22/24 1:56 PM, Conor Dooley wrote:
> > On Fri, Jun 21, 2024 at 05:53:53PM +0200, Marek Vasut wrote:
> > > Document default DP port preemphasis configurable via new DT property
> > > "toshiba,pre-emphasis". This is useful in case
On 6/22/24 1:56 PM, Conor Dooley wrote:
On Fri, Jun 21, 2024 at 05:53:53PM +0200, Marek Vasut wrote:
Document default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis
On 23/06/2024 16:13, Conor Dooley wrote:
> On Sun, Jun 23, 2024 at 02:00:26PM +0200, Krzysztof Kozlowski wrote:
>> MMIO address space is known per each variant of Adreno GPU, so we can
>> constrain the reg/reg-names entries for each variant. There is no DTS
>> for A619, so that part is not
On 20/06/2024 21:18, Doug Anderson wrote:
Hi,
On Thu, Jun 20, 2024 at 11:12 AM Tejas Vipin wrote:
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for
On Sun, Jun 23, 2024 at 02:53:17PM +0200, Krzysztof Kozlowski wrote:
> On 23/06/2024 14:28, Akhil P Oommen wrote:
> > On Sun, Jun 23, 2024 at 01:17:16PM +0200, Krzysztof Kozlowski wrote:
> >> On 23/06/2024 13:06, Akhil P Oommen wrote:
> >>> Add the necessary dt nodes for gpu support in X1E80100.
>
> > If there is no netdev, what is the point of putting it into loopback?
> > How do you send packets which are to be looped back? How do you
> > receive them to see if they were actually looped back?
> >
> > Andrew
>
> To run RDMA test in loopback.
What is special about your RDMA? Why do
On 6/20/24 22:14, Andrew Lunn wrote:
> On Thu, Jun 20, 2024 at 06:51:35AM -0700, Jakub Kicinski wrote:
>> On Thu, 20 Jun 2024 08:43:34 + Omer Shpigelman wrote:
You support 400G, you really need to give the user the ability
to access higher pages.
>>>
>>> Actually the 200G and 400G
> > But what about when the system is under memory pressure? You say it
> > allocates memory. What happens if those allocations fail. Does
> > changing the MTU take me from a working system to a dead system? It is
> > good practice to not kill a working system under situations like
> > memory
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the
Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and
pass it down the display pipeline to obtain exactly this frequency on input
into this bridge.
The precise input frequency that matches the Pixel
This reverts commit 01338bb82fed40a6a234c2b36a92367c8671adf0.
With clock improvements in place, this seems to be no longer
necessary. Set the CLRSIPO to default setting recommended by
manufacturer.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej
The MIPI_DSI_CLOCK_NON_CONTINUOUS causes visible artifacts in high
resolution modes, disable it. Namely, in DSI->DP mode 1920x1200 24
bpp 59.95 Hz, with DSI bus at maximum 1 Gbps per lane setting, the
image contains jittering empty lines.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc:
This line_pixel_subtract is no longer needed now that the bridge can
request and obtain specific pixel clock on input to the bridge, with
clock frequency that matches the Pixel PLL frequency.
The line_pixel_subtract is now always 0, so drop it entirely.
The line_pixel_subtract was not reliable
The only information in the datasheet regarding this divider is a note
in SYS_PLLPARAM register documentation which states that when LSCLK is
270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when
LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test
confirms using
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL
parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc()
and then configures the Pixel PLL register.
This is a preparatory patch for further rework, where tc_pxl_pll_calc()
will also be used to find out the
On Sun, Jun 23, 2024 at 02:00:24PM +0200, Krzysztof Kozlowski wrote:
> We expect each schema with variable number of clocks, to have the widest
> constrains in top-level "properties:". This is more readable and also
> makes binding stricter, if there is no "if:then:" block for given
> variant.
>
On Sun, Jun 23, 2024 at 02:00:25PM +0200, Krzysztof Kozlowski wrote:
> All devices should (and actually do) have same order of entries, if
> possible. That's the case for reg/reg-names, so define the reg-names in
> top-level to enforce that.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by:
On Sun, Jun 23, 2024 at 02:00:26PM +0200, Krzysztof Kozlowski wrote:
> MMIO address space is known per each variant of Adreno GPU, so we can
> constrain the reg/reg-names entries for each variant. There is no DTS
> for A619, so that part is not accurate but could be corrected later.
>
>
From: Tobias Jakobi
[ Upstream commit f74fb5df429ebc6a614dc5aa9e44d7194d402e5a ]
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
From: Douglas Anderson
[ Upstream commit c38896ca6318c2df20bbe6c8e3f633e071fda910 ]
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't
From: Tobias Jakobi
[ Upstream commit f74fb5df429ebc6a614dc5aa9e44d7194d402e5a ]
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
From: Krzysztof Kozlowski
[ Upstream commit 1f3512cdf8299f9edaea9046d53ea324a7730bab ]
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Signed-off-by:
From: Douglas Anderson
[ Upstream commit 0320ca14c6fb68ad19aa72e55a1a21c061b2946b ]
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time.
This is important because drm_atomic_helper_shutdown() will cause
From: Douglas Anderson
[ Upstream commit c38896ca6318c2df20bbe6c8e3f633e071fda910 ]
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't
From: Tobias Jakobi
[ Upstream commit f74fb5df429ebc6a614dc5aa9e44d7194d402e5a ]
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
From: Krzysztof Kozlowski
[ Upstream commit 1f3512cdf8299f9edaea9046d53ea324a7730bab ]
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Signed-off-by:
dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
given binding validation if the schema contains compatible list with
pattern and a const fallback. This leads to binding being a no-op - not
being applied at all. Issue should be fixed in the dtschema but for now
add a
On 23/06/2024 14:28, Akhil P Oommen wrote:
> On Sun, Jun 23, 2024 at 01:17:16PM +0200, Krzysztof Kozlowski wrote:
>> On 23/06/2024 13:06, Akhil P Oommen wrote:
>>> Add the necessary dt nodes for gpu support in X1E80100.
>>>
>>> Signed-off-by: Akhil P Oommen
>>> ---
>>> + gmu:
On 23/06/2024 13:06, Akhil P Oommen wrote:
> Document Adreno X185 GMU in the dt-binding specification.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> Documentation/devicetree/bindings/display/msm/gmu.yaml | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On Sun, Jun 23, 2024 at 01:17:16PM +0200, Krzysztof Kozlowski wrote:
> On 23/06/2024 13:06, Akhil P Oommen wrote:
> > Add the necessary dt nodes for gpu support in X1E80100.
> >
> > Signed-off-by: Akhil P Oommen
> > ---
> > + gmu: gmu@3d6a000 {
> > + compatible =
MMIO address space is known per each variant of Adreno GPU, so we can
constrain the reg/reg-names entries for each variant. There is no DTS
for A619, so that part is not accurate but could be corrected later.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/msm/gpu.yaml
All devices should (and actually do) have same order of entries, if
possible. That's the case for reg/reg-names, so define the reg-names in
top-level to enforce that.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 5 -
1 file changed, 4
We expect each schema with variable number of clocks, to have the widest
constrains in top-level "properties:". This is more readable and also
makes binding stricter, if there is no "if:then:" block for given
variant.
Signed-off-by: Krzysztof Kozlowski
---
On 23/06/2024 13:06, Akhil P Oommen wrote:
> Add the necessary dt nodes for gpu support in X1E80100.
>
> Signed-off-by: Akhil P Oommen
> ---
> + gmu: gmu@3d6a000 {
> + compatible = "qcom,adreno-gmu-x185.1",
> "qcom,adreno-gmu";
> + reg = <0x0
On 23/06/2024 13:06, Akhil P Oommen wrote:
> Document Adreno X185 GMU in the dt-binding specification.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> Documentation/devicetree/bindings/display/msm/gmu.yaml | 4
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 23/06/2024 13:06, Akhil P Oommen wrote:
> This series adds support for the Adreno X1-85 GPU found in Qualcomm's
> compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
> naming scheme for Adreno GPU, 'X' stands for compute series, '1' denotes
> 1st generation and '8' & '5' denotes
Add the necessary dt nodes for gpu support in X1E80100.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 195 +
1 file changed, 195 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
Document Adreno X185 GMU in the dt-binding specification.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/display/msm/gmu.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml
Add support in drm/msm driver for the Adreno X185 gpu found in
Snapdragon X1 Elite chipset.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 19 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 ++
drivers/gpu/drm/msm/adreno/adreno_device.c
This series adds support for the Adreno X1-85 GPU found in Qualcomm's
compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
naming scheme for Adreno GPU, 'X' stands for compute series, '1' denotes
1st generation and '8' & '5' denotes the tier and the SKU which it
belongs.
X1-85 has
On Sun, Jun 23, 2024 at 7:59 AM Dmitry Baryshkov
wrote:
>
> On Sun, Jun 23, 2024 at 01:25:52AM GMT, Barnabás Czémán wrote:
> > From: Daniil Titov
> >
> > Add the mdp5_cfg_hw entry for MDP5 version v1.14 found on msm8937.
> >
> > Signed-off-by: Daniil Titov
> > Signed-off-by: Barnabás Czémán
>
Are you planning on submitting a bogus CVE for this patch too?
- Joshie ✨
On June 22, 2024 9:22:19 AM GMT+01:00, Ma Ke wrote:
>In amdgpu_connector_add_common_modes(), the return value of drm_cvt_mode()
>is assigned to mode, which will lead to a NULL pointer dereference on
>failure of
The value of "min_input_signal" returned from ATIF on a Framework AMD 13
is "12". This leads to a fairly bright minimum display backlight.
Add a quirk to override that the minimum backlight PWM to "0" which
leads to a much lower minimum brightness, which is still visible.
Tested on a Framework
1 - 100 of 492594 matches
Mail list logo
