Hi Mike,
>
> On 07/18/23 01:26, Vivek Kasireddy wrote:
> > 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
On Sat, 8 Jul 2023 at 07:59, Lyude Paul wrote:
>
> Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> nouveau in order to read the DPCD of a DP connector, which makes sure we do
> the right thing and also check for extended DPCD caps. However, it turns
> out we're not
On Mon, Jul 17, 2023 at 10:14 PM AngeloGioacchino Del Regno
wrote:
>
> Changes in v6:
> - Added some previously missing error checking (patch [01/11])
> - Added error checks for devm_drm_bridge_add()
> - Made sure that cable_plugged_in is set to false if HPD assertion
>polling fails
Hi Rob,
Thanks for your comments,
> > Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge..
> >
> > Signed-off-by: Sandor Yu
> > ---
> > .../display/bridge/cdns,mhdp8501.yaml | 105
> ++
> > 1 file changed, 105 insertions(+)
> > create mode 100644
> >
Hi Rob,
Thanks for your comment.
> > Hi Alexander,
> >
> > Thanks for your comments,
> >
> > >
> > > Am Montag, 17. Juli 2023, 10:03:49 CEST schrieb Sandor Yu:
> > > >
> > > > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie
> > > > wissen, dass diese aus
[AMD Official Use Only - General]
> -Original Message-
> From: Andrew Lunn
> Sent: Tuesday, July 18, 2023 10:16 PM
> To: Quan, Evan
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch;
Vivek Kasireddy writes:
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 64a3239b6407..1f2f0209101a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6096,8 +6096,12 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
>* hugetlb_no_page will
On 2023/7/18 19:28, Andrzej Hajda wrote:
On 18.07.2023 12:10, Su Hui wrote:
On 2023/7/18 13:39, Dan Carpenter wrote:
On Mon, Jul 17, 2023 at 04:52:51PM +0200, Andrzej Hajda wrote:
On 17.07.2023 08:22, Su Hui wrote:
Clang warning: drivers/gpu/drm/i915/display/intel_tv.c:
line 991, column 22
From: Michael Banack
To clarify the intent and reasoning behind the hotspot properties
introduce userspace documentation that goes over cursor handling
in para-virtualized environments.
The documentation is generic enough to not special case for any
specific hypervisor and should apply equally
From: Zack Rusin
Virtualized drivers place additional restrictions on the cursor plane
which breaks the contract of universal planes. To allow atomic
modesettings with virtualized drivers the clients need to advertise
that they're capable of dealing with those extra restrictions.
To do that
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Reviewed-by: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc:
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Hans de Goede
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
From: Zack Rusin
Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but the functionality was not implemented in the new atomic
paths.
Due to the lack of hotspots in the atomic paths userspace
From: Zack Rusin
Atomic modesetting supports mouse cursor offsets via the hotspot
properties that are created on cursor planes. All drivers which
support hotspots are atomic and the legacy code has been implemented
in terms of the atomic properties as well.
Due to the above the lagacy cursor
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Maaz Mombasawala
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Martin Krastev
---
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Reviewed-by: Gerd Hoffmann
Cc: David Airlie
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel
From: Zack Rusin
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in
From: Zack Rusin
v5: Add a change with documentation from Michael, based on his discussion
with Pekka and bump the kernel version DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT
might be introduced with to 6.6.
v4: Make drm_plane_create_hotspot_properties static, rename
Hi Liu,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.5-rc2
next-20230718]
[cannot apply to drm-misc/drm-misc-next drm
On 7/7/2023 4:12 PM, Dmitry Baryshkov wrote:
Use devm_kzalloc to create VBIF data structure. This allows us to
remove corresponding kfree and drop dpu_hw_intr_destroy() function.
Hi Dmitry,
Nit: I think you mean dpu_hw_vbif_destroy() here.
Reviewed-by: Jessica Zhang
Thanks,
Jessica
On 7/7/2023 4:12 PM, Dmitry Baryshkov wrote:
Use devm_kzalloc to create interrupts data structure. This allows us to
remove corresponding kfree and drop dpu_hw_intr_destroy() function.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
On Wed, Jul 19, 2023 at 12:05:29AM +, Kasireddy, Vivek wrote:
> > If there is no change to the PTEs then it is hard to see why this
> > would be part of a mmu_notifier.
> IIUC, the PTEs do get changed but only when a new page is faulted in.
> For shmem, it looks like the PTEs are updated in
Hi Jason,
>
> On Tue, Jul 18, 2023 at 01:28:56AM -0700, Vivek Kasireddy wrote:
> > Currently, there does not appear to be any mechanism for letting
> > drivers or other kernel entities know about updates made in a
> > mapping particularly when a new page is faulted in. Providing
> >
On Fri, Jun 30, 2023 at 06:17:29PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> VGAARB should only care about PCI VGA class devices (pdev->class == 0x0300)
> since only those devices might have VGA routed to them.
This is not actually a question of whether VGA addresses (mem
On Thu, Jul 13, 2023 at 3:01 AM Frieder Schrempf
wrote:
>
> Hi Tim,
>
> On 13.07.23 09:18, Frieder Schrempf wrote:
> > Hi Tim,
> >
> > On 13.07.23 00:34, Tim Harvey wrote:
> >> On Wed, May 3, 2023 at 9:33 AM Frieder Schrempf wrote:
> >>>
> >>> From: Frieder Schrempf
> >>>
> >>> According to the
On Tue, 18 Jul 2023 16:35:17 -0600 David Ahern wrote:
> I do not see how 1 RSS context (or more specifically a h/w Rx queue) can
> be used properly with memory from different processes (or dma-buf
> references). When the process dies, that memory needs to be flushed from
> the H/W queues. Queues
On 7/18/23 12:29 PM, Jakub Kicinski wrote:
> On Tue, 18 Jul 2023 12:20:59 -0600 David Ahern wrote:
>> On 7/18/23 12:15 PM, Jakub Kicinski wrote:
>>> On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
netlink feels like a weird API choice for that, in particular it would
be
On Mon, 17 Jul 2023 16:03:51 +0800, Sandor Yu wrote:
> Add bindings for Freescale iMX8MQ DP and HDMI PHY.
>
> Signed-off-by: Sandor Yu
> ---
> .../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +++
> 1 file changed, 53 insertions(+)
> create mode 100644
>
On Mon, Jul 17, 2023 at 04:03:49PM +0800, Sandor Yu wrote:
> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge..
>
> Signed-off-by: Sandor Yu
> ---
> .../display/bridge/cdns,mhdp8501.yaml | 105 ++
> 1 file changed, 105 insertions(+)
> create mode 100644
>
On Tue, Jul 18, 2023 at 01:58:09AM +, Sandor Yu wrote:
> Hi Alexander,
>
> Thanks for your comments,
>
> >
> > Am Montag, 17. Juli 2023, 10:03:49 CEST schrieb Sandor Yu:
> > >
> > > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie
> > > wissen, dass
On Mon, 17 Jul 2023 14:18:30 +0800, Liu Ying wrote:
> Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
> controller and a Synopsys Designware MIPI DPHY. Some configurations
> and extensions to them are controlled by i.MX93 media blk-ctrl.
>
> Signed-off-by: Liu Ying
> ---
>
On 19/07/2023 00:24, Marijn Suijten wrote:
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts. This is represented by
reducing the clock array length to 6 so that it
On 19/07/2023 00:24, Marijn Suijten wrote:
This node has always resided in the wrong spot, making it somewhat
harder to contribute new node entries while maintaining proper sorting
around it. Move the node up to sit after hsusb_phy1 where it maintains
proper numerical sorting on the (first of
On 19/07/2023 00:00, Marijn Suijten wrote:
On 2023-06-29 13:54:13, Dmitry Baryshkov wrote:
On 27/06/2023 23:14, Marijn Suijten wrote:
Document availability of the 14nm DSI PHY on SM6125. Note that this
compatible uses the SoC-suffix variant, intead of postfixing an
arbitrary number without
Hello,
On Tue, Jul 18, 2023 at 11:54:58AM +0200, Geert Uytterhoeven wrote:
> I gave it a try on a system with an 800 MHz Cortex A9, only to discover
> it makes no difference, as that machine has 1600 BogoMIPS:
Oops.
> workqueue: blk_mq_run_work_fn hogged CPU for >1us 4 times,
> consider
On 7/7/2023 4:12 PM, Dmitry Baryshkov wrote:
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Replace IS_ERR_OR_NULL() with IS_ERR() in the
dpu_hw_intr_init() error check.
On 18/07/2023 23:44, Jessica Zhang wrote:
On 7/17/2023 11:04 PM, Dmitry Baryshkov wrote:
On 18/07/2023 03:30, Jessica Zhang wrote:
In addition, *_is_widebus_enabled() would only work under the
assumption that DSC (if supported) will always be enabled during
bootup for DSI. If there ends
operand in nsecs_to_jiffies_timeout()
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
drivers/gpu/drm/v3d/v3d_drv.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
change-id:
20230718-nsecs_to_jiffies_timeout-constant-logical-operand-4a944690f3e9
Best regards,
--
Nathan Chancellor
A proposed update to clang's -Wconstant-logical-operand to warn when the
left hand side is a constant shows the following instance in
nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
such as CONFIG_HZ=300:
drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: warning: use of
A proposed update to clang's -Wconstant-logical-operand to warn when the
left hand side is a constant shows the following instance in
nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
such as CONFIG_HZ=300:
In file included from drivers/gpu/drm/v3d/v3d_debugfs.c:12:
SM6125 has an UBWC 3.0 decoder but only an UBWC 1.0 encoder.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
Enable MDSS and DSI, and configure the Samsung SOFEF01-M ams597ut01
6.0" 1080x2520 panel.
Reviewed-by: Konrad Dybcio
Signed-off-by: Marijn Suijten
---
.../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git
Enable and configure the dispcc node on SM6125 for consumption by MDSS
later on.
Signed-off-by: Marijn Suijten
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
SM6125 features only a single PHY (despite a secondary PHY PLL source
being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
sources for this "trinket" SoC do not define the typical "vcca"
regulator to be available nor used. This, including the register offset
is identical to
We have a working RPM XO clock; no other driver except rpmcc should be
parenting directly to the fixed-factor xo_board clock nor should it be
reachable by that global name. Remove the name to that effect, so that
every clock relation is explicitly defined in DTS.
Reviewed-by: Konrad Dybcio
Document availability of the 14nm DSI PHY on SM6125. Note that this
compatible uses the SoC-suffix variant, intead of postfixing an
arbitrary number without the sm/sdm portion. The PHY is not powered by
a vcca regulator like on most SoCs, but by the MX power domain that is
provided via the
Add the DT nodes that describe the MDSS hardware on SM6125, containing
one MDP (display controller) together with a single DSI and DSI PHY. No
DisplayPort support is added for now.
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
Document general compatibility of the DSI controller on SM6125.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add definitions for the display hardware used on the Qualcomm SM6125
platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 236 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 7 +
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts. This is represented by
reducing the clock array length to 6 so that it cannot be passed. Note
that any SoC other than
Document the SM6125 MDSS.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Marijn Suijten
---
.../bindings/display/msm/qcom,sm6125-mdss.yaml | 211 +
1 file changed, 211 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
be passed from DT, and should be required by the bindings.
Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
bindings")
Reviewed-by: Rob Herring
Signed-off-by: Marijn Suijten
---
On SM6125 the dispcc block is gated behind VDDCX: allow this domain to
be configured.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Marijn Suijten
---
.../devicetree/bindings/clock/qcom,dispcc-sm6125.yaml| 16
1 file changed, 16 insertions(+)
diff --git
This node has always resided in the wrong spot, making it somewhat
harder to contribute new node entries while maintaining proper sorting
around it. Move the node up to sit after hsusb_phy1 where it maintains
proper numerical sorting on the (first of its many) reg address
property.
Fixes:
The regulator setup was likely copied from other SoCs by mistake. Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.
Fixes: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290")
Reviewed-by: Konrad Dybcio
Reviewed-by:
Bring up the SM6125 DPU now that all preliminary series (such as INTF
TE) have been merged (for me to test the hardware properly), and most
other conflicting work (barring ongoing catalog *improvements*) has made
its way in as well or is still being discussed.
The second part of the series
On 2023-06-29 21:14:47, Konrad Dybcio wrote:
> On 29.06.2023 14:26, Dmitry Baryshkov wrote:
> > On Thu, 29 Jun 2023 at 15:09, Marijn Suijten
> > wrote:
> >>
> >> On 2023-06-29 13:55:28, Dmitry Baryshkov wrote:
> >>> On 27/06/2023 23:14, Marijn Suijten wrote:
> We have a working RPM XO clock;
On 2023-06-29 13:54:13, Dmitry Baryshkov wrote:
> On 27/06/2023 23:14, Marijn Suijten wrote:
> > Document availability of the 14nm DSI PHY on SM6125. Note that this
> > compatible uses the SoC-suffix variant, intead of postfixing an
> > arbitrary number without the sm/sdm portion. The PHY is not
On 7/17/2023 11:04 PM, Dmitry Baryshkov wrote:
On 18/07/2023 03:30, Jessica Zhang wrote:
On 7/14/2023 6:38 PM, Dmitry Baryshkov wrote:
On 15/07/2023 03:59, Jessica Zhang wrote:
On 7/14/2023 3:30 PM, Dmitry Baryshkov wrote:
On Fri, 14 Jul 2023 at 22:03, Jessica Zhang
wrote:
On
On Fri, Jul 14, 2023, at 19:16, Javier Martinez Canillas wrote:
> This patch series splits the fbdev core support in two different Kconfig
> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> be disabled, while still having the the core fbdev support needed for the
>
On Fri, Jul 14, 2023, at 19:16, Javier Martinez Canillas wrote:
> The drivers/video/fbdev/Kconfig defines both symbols for fbdev drivers and
> core fbdev symbols, that can be enabled independently of the fbdev drivers.
>
> Split the Kconfig in two, one that only has the symbols for fbdev drivers
>
Hi,
On Tue, Jul 18, 2023 at 10:37 AM Marek Vasut wrote:
>
> On 7/18/23 18:15, Doug Anderson wrote:
> > Hi,
>
> Hi,
>
> > On Tue, Jul 18, 2023 at 8:36 AM Marek Vasut wrote:
> >>
> >> On 7/18/23 16:17, Doug Anderson wrote:
> >>> Hi,
> >>
> >> Hi,
> >>
> >>> On Sun, Jul 9, 2023 at 6:52 AM Marek
On Fri, Jul 14, 2023, at 19:16, Javier Martinez Canillas wrote:
> Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
> drivers are needed (e.g: only to have support for framebuffer consoles).
>
> The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
> and so
On Tue, 18 Jul 2023 12:20:59 -0600 David Ahern wrote:
> On 7/18/23 12:15 PM, Jakub Kicinski wrote:
> > On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
> >> netlink feels like a weird API choice for that, in particular it would
> >> be really wrong to somehow bind the lifecycle of a
On 7/18/23 12:15 PM, Jakub Kicinski wrote:
> On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
>> netlink feels like a weird API choice for that, in particular it would
>> be really wrong to somehow bind the lifecycle of a netlink object to a
>> process.
>
> Netlink is the right API, life
Introduce a test to cover the creation of framebuffer with
modifier on a device that don't support it.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 29
1 file changed, 29 insertions(+)
diff --git
Extend the existing test case to cover:
1. Invalid flag atribute in the struct drm_mode_fb_cmd2.
2. Pixel format which requires non-linear modifier with
DRM_FORMAT_MOD_LINEAR set.
3. Non-zero buffer offset for an unused plane
Also replace strcpy to strscpy on test_to_desc for improved security
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/drm_framebuffer.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index aff3746dedfb..49df3ca3b3ee 100644
---
Add a parametrized test for the drm_framebuffer_check_src_coords function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 126 +++
1 file changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
This series adds documentation and unit tests for
drm_framebuffer_check_src_coords() and drm_internal_framebuffer_create()
functions on drm_framebuffer.c, including new parameters to the, until
then, only existent test.
Many thanks,
Carlos
---
v2:
- Replaced strcpy to strscpy (Maxime)
-
On Tue, 18 Jul 2023 15:06:29 -0300 Jason Gunthorpe wrote:
> netlink feels like a weird API choice for that, in particular it would
> be really wrong to somehow bind the lifecycle of a netlink object to a
> process.
Netlink is the right API, life cycle of objects can be easily tied to
a netlink
On Tue, Jul 18, 2023 at 10:36:52AM -0700, Mina Almasry wrote:
> That is specific to this proposal, and will likely be very different
> in future ones. I thought the dma-buf pages approach was extensible
> and the uapi belonged somewhere in dma-buf. Clearly not. The next
> proposal, I think, will
On 18.07.23 10:26, Vivek Kasireddy wrote:
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
On 18.07.23 10:26, Vivek Kasireddy wrote:
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
On 7/18/23 18:15, Doug Anderson wrote:
Hi,
Hi,
On Tue, Jul 18, 2023 at 8:36 AM Marek Vasut wrote:
On 7/18/23 16:17, Doug Anderson wrote:
Hi,
Hi,
On Sun, Jul 9, 2023 at 6:52 AM Marek Vasut wrote:
The unprepared_time has to be initialized during probe to probe time
ktime, otherwise
Hi,
I still remember you are helps to review the drm/lsdc patch one years
ago, see [1].
drm/lsdc is the former version of drm/loongson, originally drm/lsdc
are embedded SoCs of Loongson.
[1] https://patchwork.freedesktop.org/patch/471997/?series=99512=5
I haven't forget about you.
On
On Sun, Jul 16, 2023 at 7:41 PM Andy Lutomirski wrote:
>
> On 7/10/23 15:32, Mina Almasry wrote:
> > * TL;DR:
> >
> > Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
> > from device memory efficiently, without bouncing the data to a host memory
> > buffer.
>
> (I'm
On Sun, 16 Jul 2023 19:41:28 -0700 Andy Lutomirski wrote:
> I'm wondering if a more capable if somewhat higher latency model could
> work where the NIC stores received packets in its own device memory.
> Then userspace (or the kernel or a driver or whatever) could initiate a
> separate DMA from
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).
This is needed by the next patch fixing HPD polling on i915.
Using FBTFT_REGISTER_DRIVER resolves to a NULL struct spi_device_id. This
ultimately causes a warning when the module probes. Fixes it.
Signed-off-by: Raphael Gallais-Pou
---
Changes in v3:
- added changelog
Changes in v2:
- dropped MODULE_ALIAS changes
- changed commit
Rename the "crtc" member of the shmob_drm_crtc subclass structure to
"base", to improve readability.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Sui Jingfeng
---
v2:
- Add Reviewed-by.
---
.../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 26
Add device tree bindings for the LCD Controller (LCDC) found in Renesas
SuperH SH-Mobile and ARM SH/R-Mobile SOCs.
Based on a plain text prototype by Laurent Pinchart.
Signed-off-by: Geert Uytterhoeven
---
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: Conor Dooley
Cc:
Rename the "connector" member of the shmob_drm_connector subclass
structure to "base", to improve readability.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Sui Jingfeng
---
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 4 ++--
Now that drm_device is embedded in shmob_drm_device, we can use
a container_of()-based helper to get the shmob_drm_device pointer from
the drm_device, instead of using the deprecated drm_device.dev_private
field.
While at it, restore reverse Xmas tree ordering of local variable
declarations.
When the device is unbound from the driver, the display may be active.
Make sure it gets shut down.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff
Move legacy interface handling to the connector setup code.
Set up bus_flags and bus_formats in display_info according to the
bus format and panel information from platform data, to make it more
similar with DT-based connector/bridge/panel setup.
This will allow us to use the same LCD interface
Add the RGB666 9:9 format MEDIA_BUS_FMT_RGB666_2X9_BE, which is
supported by the SH-Mobile LCD Controller.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
v2:
- Add Reviewed-by,
- Drop unused
Unify primary and overlay plane allocation:
- Enhance shmob_drm_plane_create() so it can be used to create the
primary plane, too,
- Move overlay plane creation next to primary plane creation.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Pass plane type to shmob_drm_plane_create() to
Implement atomic mode setting for both the primary and overlay planes.
This involves:
- Moving the primary plane handling code from CRTC mode setting to
plane handling shared by primary and overlay planes,
- Adding basic CRTC and mode config atomic mode setting ops, which
don't do much
Replace the last printing of an hexadecimal fourcc format code by a
pretty-printed format name, using the "%p4cc" format specifier.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c | 4 ++--
1
Replace the call to the legacy drm_handle_vblank() function with a call
to the new drm_crtc_handle_vblank() helper.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Sui Jingfeng
---
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 2
From: Laurent Pinchart
The display info width_mm and height_mm fields are set at init time and
never overwritten, don't set them a second time when getting modes.
Signed-off-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Sui Jingfeng
---
v2:
- Add Reviewed-by.
---
Improve the table containing hardware information related to the
supported plane formats:
1. Move (part of) the overlay format register settings from multiple
switch() statements spread across the code into the table, like is
already done for the primary plane register settings,
2.
The DRM core vblank handling mechanism requires drivers to forcefully
turn vblank reporting off when disabling the CRTC, and to restore the
vblank reporting status when enabling the CRTC.
Implement this using the drm_crtc_vblank_{on,off}() helpers.
Note that drm_crtc_vblank_off() must be called
Move the shmob_drm_crtc_finish_page_flip() function up, to avoid having
to move it during the modification in the next change.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by,
- Move further up.
---
.../gpu/drm/renesas/shmobile/shmob_drm_crtc.c |
According to the comments for drm_universal_plane_init(), the plane
structure should not be allocated with devm_kzalloc().
Fix lifetime issues by using drmm_universal_plane_alloc() instead.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split off removal of call to drm_plane_force_disable().
---
The primary plane supports various YCbCr formats, and the CRTC code
already knows how to handle them. Enable support for the missing
formats by adding them to the table of supported modes.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
From: Laurent Pinchart
Prepare for DT bindings by using more appropriate names for the input
clocks.
Note that all LDDCKR_ICKSEL_* definitions but the one for the bus clock
are valid only for SH7724, so the clock selection code needs to be
updated when extending clock support to other SoCs.
Replace to conversion helper macros using container_of() by static
inline functions, to improve type-safety.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 11 ---
1 - 100 of 262 matches
Mail list logo
