On 6/7/2024 5:57 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 02:55, Abhinav Kumar wrote:
On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhin
On Sat, 8 Jun 2024 at 02:55, Abhinav Kumar wrote:
>
>
>
> On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
> > On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
>
Hi Pierre-Eric,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.10-rc2 next-20240607]
[cannot apply to drm-xe/drm-xe-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM
On Fri, 7 Jun 2024 19:55:49 +0200
Danilo Krummrich wrote:
> On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote:
>> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
>> > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
>> > > Anyway, that's all hand-wavy right now, so
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar wrote:
>
>
>
> On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
> > On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
> >>> On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote
If the card doesn't have display hardware, hpd_work and hpd_lock are
left uninitialized which causes BUG when attempting to schedule hpd_work
on runtime PM resume.
Fix it by adding headless flag to DRM and skip any hpd if it's set.
Fixes: ae1aadb1eb8d ("nouveau: don't fail driver load if no displ
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks
The pull request you sent on Fri, 7 Jun 2024 12:05:49 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-06-07
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e32d580757362edc95fdd7a86d3b869b78e58d8
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Fri, Jun 07, 2024 at 12:22:16PM -0700, Abhinav Kumar wrote:
>
>
> On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
> > On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
> > > On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > > > Only several SSPP blocks support such features as YUV o
On Fri, Jun 07, 2024 at 10:00:04AM -0400, Kiarash Hajian wrote:
> The driver's memory regions are currently just ioremap()ed, but not
> reserved through a request. That's not a bug, but having the request is
> a little more robust.
>
> Implement the region-request through the corresponding managed
Hi Dave, Sima,
New stuff for 6.11.
The following changes since commit b77bef36015c501f1e0f51db72c55e6dcd8bdd48:
drm/amd/display: Add some HDCP registers DCN35 list (2024-04-26 17:22:45
-0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-
no problem, thanks for your time.
wu
On Fri, Jun 7, 2024 at 1:35 PM Christian König wrote:
>
> In general thanks for looking into this, but when you don't have
> hardware to at least briefly validate your work we probably can't accept
> that.
>
> I can see if I can get anybody looking into this,
On Wed, Jun 05, 2024 at 10:15:52AM +0200, Philipp Stanner wrote:
> Hello Bjorn,
>
> I tried to meet your requests from the last feedback round as much as
> possible. Especially, I removed a lot of code, made almost all
> interfaces private and cut the series into smaller chunks where
> possible.
>
On 6/7/2024 12:16 AM, Dmitry Baryshkov wrote:
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly uti
On 6/5/2024 5:17 PM, Andi Shyti wrote:
The ce->guc_state.lock was made to protect guc_prio, which
indicates the GuC priority level.
But at the begnning of the function we perform some sanity check
of guc_prio outside its protected section. Move them within the
locked region.
Use this occasio
On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote:
> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
> > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
> > > Anyway, that's all hand-wavy right now, sorry, to get back to the point
> > > here, again, let's take this,
In general thanks for looking into this, but when you don't have
hardware to at least briefly validate your work we probably can't accept
that.
I can see if I can get anybody looking into this, but the odds that
somebody has time and hardware are pretty low.
Christian.
Am 07.06.24 um 16:15
i do it because it is part of the todo list
where the task is to remove load/unload callback
there are only 2 drm_driver that still uses thats why
i thought my amdgpu could test radeonsi but no, i still send it anyway
regards,
wu
On Fri, Jun 7, 2024 at 3:51 AM Christian König wrote:
>
> Am 07.0
this patch is to remove the load callback from the kms_driver,
following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc
are used, most of the changes here are rdev->ddev to rdev_to_drm,
which maps to adev_to_drm in amdgpu. however this patch is not tested on
hardware, so if you are
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d35b2284e966c0bef3e2182a5c5ea02177dd32e4 Add linux-next specific
files for 20240607
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202406071624.o81nljmg-...@intel.com
https
On Fri, Jun 7, 2024 at 8:47 AM Pavel Begunkov wrote:
>
> On 6/7/24 16:42, Pavel Begunkov wrote:
> > On 6/7/24 15:27, David Ahern wrote:
> >> On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> >>> I haven't seen any arguments against from the (net) maintainers so
> >>> far. Nor I see any objection against
On Thu, Jun 6, 2024 at 6:37 PM Dave Airlie wrote:
>
> readding original poster
Thanks, Dave!
Ben, please keep me on CC, since I'm not subscribed to either nouveau
or dri-devel mailing lists.
> On Wed, 29 May 2024 at 09:57, Ben Skeggs wrote:
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_c
On 6/7/24 16:42, Pavel Begunkov wrote:
On 6/7/24 15:27, David Ahern wrote:
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
I haven't seen any arguments against from the (net) maintainers so
far. Nor I see any objection against callbacks from them (considering
that either option adds an if).
I have s
On 6/7/24 15:27, David Ahern wrote:
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
I haven't seen any arguments against from the (net) maintainers so
far. Nor I see any objection against callbacks from them (considering
that either option adds an if).
I have said before I do not understand why the d
On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
> On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
> > Anyway, that's all hand-wavy right now, sorry, to get back to the point
> > here, again, let's take this, which will allow the firmware bindings to
> > be resubmitted and
On Fri, Jun 07, 2024 at 04:51:31PM +0200, Andi Shyti wrote:
> The forcewake count and domains listing is multi process critical
> and the uncore provides a spinlock for such cases.
>
> Lock the forcewake evaluation section in the fw_domains_show()
> debugfs interface.
>
> Signed-off-by: Andi Shyt
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #15 from Hanabishi
(i.r.e.c.c.a.k.u.n+bugzilla.kernel@gmail.com) ---
(In reply to Vasant Hegde from comment #5)
> Created attachment 306364 [details]
> Check Enhanced PPR support before enabling PPR
I applied your patch on top of
On 6/4/24 15:20, Noralf Trønnes via B4 Relay wrote:
> Hi,
>
> In this version I've fixed up a commit message that I had forgotten to
> write before sending and improved a struct member name.
>
> See version 1 of the patchset for the full cover letter.
>
> Signed-off-by: Noralf Trønnes
> ---
On Fri, Jun 07, 2024 at 08:27:29AM -0600, David Ahern wrote:
> On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> > I haven't seen any arguments against from the (net) maintainers so
> > far. Nor I see any objection against callbacks from them (considering
> > that either option adds an if).
>
> I have sa
The forcewake count and domains listing is multi process critical
and the uncore provides a spinlock for such cases.
Lock the forcewake evaluation section in the fw_domains_show()
debugfs interface.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4
1 file cha
On Fri, 07 Jun 2024, Javier Martinez Canillas wrote:
> Jani Nikula writes:
>
> Hello Jani,
>
>> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
>> asking users about it.
>>
>> Reported-by: Linus Torvalds
>> Closes:
>> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=v
On Fri, 7 Jun 2024 23:00:03 +1200
Ryan Walklin wrote:
Hi Ryan,
thanks for taking the time and posting those patches!
> Buffers, compressed with AFBC, are generally more efficient for memory
> transfers. Add support for them.
>
> Currently it's implemented only for VI layers, but vendor code a
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> I haven't seen any arguments against from the (net) maintainers so
> far. Nor I see any objection against callbacks from them (considering
> that either option adds an if).
I have said before I do not understand why the dmabuf paradigm is not
sufficient f
On Fri, Jun 07, 2024 at 10:59:57PM +1200, Ryan Walklin wrote:
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> Add display engine bus, clock and mixer bindings for the DE33.
>
> Signed-off-by: Ryan Walklin
> ---
> .../devicetree/bindings/bus/allwinner,sun50i-a6
gpu *a6xx_gpu, struct
device_node *node)
detach_cxpd:
dev_pm_domain_detach(gmu->cxpd, false);
-err_mmio:
- iounmap(gmu->mmio);
- if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "rscc"))
- iounmap(gmu->rscc);
+err_cleanup:
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
---
base-commit: 1b294a1f35616977caddaddf3e9d28e576a1adbc
change-id: 20240607-memory-45e13bb0cd16
Best regards,
--
Kiarash Hajian
On Wed, 2024-06-05 at 13:31 +0300, Jouni Högander wrote:
> Add missing Panel Replay Enable SU Region ET bit defined in DP2.1
> specification.
Hello drm-core maintainers,
Could you please consider providing your ack on this patch? I'm
planning to merge it via drm-intel tree. I have already r-b tag
Hi,
Le 06/06/2024 à 15:18, Christian König a écrit :
Am 06.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer:
When tracing is enabled, being able to identify which device is sending
events is useful; for this the next commit will extend events to include
drm_device::primary::index.
That sound
On 6/5/24 09:24, Christoph Hellwig wrote:
On Mon, Jun 03, 2024 at 03:52:32PM +0100, Pavel Begunkov wrote:
The question for Christoph is what exactly is the objection here? Why we
would not be using well defined ops when we know there will be more
users?
The point is that there should be no mor
On 6/3/24 16:43, Mina Almasry wrote:
On Mon, Jun 3, 2024 at 7:52 AM Pavel Begunkov wrote:
On 6/3/24 15:17, Mina Almasry wrote:
On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig wrote:
On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote:
I'm unsure if the discussion has been reso
On Sun, May 26, 2024 at 10:12 AM Mikhail Gavrilov
wrote:
>
> Hi,
> Day before yesterday I replaced 7900XTX to 6900XT for got clear in
> which kernel first time appeared warning message "DMA-API: amdgpu
> :0f:00.0: cacheline tracking EEXIST, overlapping mappings aren't
> supported".
> The kerne
On 05/06/2024 08:19, Iago Toral wrote:
Thanks for looking at ixing this Tvrtko.
El mar, 04-06-2024 a las 17:02 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
Move static const array into the source file to fix the "defined but
not
used" errors.
The fix is perhaps not the prettiest du
Use generic macro round_closest_up() for rounding closest to specified
value instead of using local macro round_closest().
There is no change from functionality point of view as round_closest_up()
is functionally same as the previously used local macro round_closest().
Signed-off-by: Devarsh Thak
On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
> Anyway, that's all hand-wavy right now, sorry, to get back to the point
> here, again, let's take this, which will allow the firmware bindings to
> be resubmitted and hopefully accepted, and we can move forward from
> there to "real" things
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest val
Add tests for round_closest_up/down and roundclosest macros which round
to nearest multiple of specified argument. These are tested with kunit
tool as shared here [1] :
Link: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876 [1]
Signed-off-by: Devarsh Thakkar
Acked-by: Andy Shevch
From: Daniel Latypov
Add basic test coverage for files that don't require any config options:
* part of math.h (what seem to be the most commonly used macros)
* gcd.c
* lcm.c
* int_sqrt.c
* reciprocal_div.c
(Ignored int_pow.c since it's a simple textbook algorithm.)
These tests aren't particular
Add documentation for rounding, scaling, absolute value and 32-bit division
related macros and functions exported by math.h header file.
Signed-off-by: Devarsh Thakkar
Reviewed-by: Andy Shevchenko
---
V13: No change
V12: Add Reviewed-by
V11: Fix title for math function header
V10: Patch introduc
Add below rounding related macros:
round_closest_up(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to round up in case two nearest values are
possible.
round_closest_down(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to
Hi,
Le 06/06/2024 à 15:19, Steven Rostedt a écrit :
On Thu, 6 Jun 2024 15:06:24 +0200
Pierre-Eric Pelloux-Prayer wrote:
Print identifiers instead of pointers:
* "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
coherent way to print the fence. A possible follow up change
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 --
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format require
Turn drm_bridge_connector to using drmm_kzalloc() and
drmm_connector_init() and drop the custom destroy function. The
drm_connector_unregister() and fwnode_handle_put() are already handled
by the drm_connector_cleanup() and so are safe to be dropped.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to
simplify its usage in the driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/registers/display/hdmi
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 45 ++---
drive
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Turn it into the
atomic_enable callback as suggested by the documentation.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 33 +
Add drm_atomic_helper_connector_hdmi_disable_audio_infoframe(), an API
to allow the driver disable sending the Audio Infoframe. This is to be
used by the drivers if setup of the infoframes is not tightly coupled
with the audio functionality and just disabling the audio playback
doesn't stop the HDM
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gp
In order to let bridge chains implement HDMI connector infrastructure,
add necessary glue code to the drm_bridge_connector. In case there is a
bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs
implementation
This patchset sits on top Maxime's HDMI connector patchset ([1]).
Currently this is an RFC exploring the interface between HDMI bridges
and HDMI connector code. This has been lightly verified on the Qualcomm
DB820c, which has native HDMI output. If this approach is considered to
be acceptable, I'l
This adds support for V4L2 M2M based driver for E5010 JPEG Encoder
which is a stateful JPEG encoder from Imagination technologies
and is present in TI AM62A SoC.
While adding support for it, following additional framework changes were
made:
- Moved reference quantization and huffman tables provid
On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
> On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote:
> > Hi,
> >
> > On Fri, 31 May 2024 11:59:47 +0200
> > Danilo Krummrich wrote:
> >
> > > Once we get to a conclusion I can send a series with only the device and
> > > fir
On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote:
> Hi,
>
> On Fri, 31 May 2024 11:59:47 +0200
> Danilo Krummrich wrote:
>
> > Once we get to a conclusion I can send a series with only the device and
> > firmare
> > abstractions such that we can get them in outside of the scope o
Am 07.06.24 um 14:01 schrieb Dmitry Baryshkov:
On Fri, Jun 07, 2024 at 07:44:33PM +0800, zhaoxiong lv wrote:
hi Alex Bee
I compared these two drivers. Although the control IC is the same, the
panel is different, and the init_cmd and timing are also slightly
different, so I added a separate dr
Jani Nikula writes:
Hello Jani,
> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
> asking users about it.
>
> Reported-by: Linus Torvalds
> Closes:
> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
> Fixes: f89632a9e5fa ("d
On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote:
> Hi,
>
> On Fri, 31 May 2024 11:59:47 +0200
> Danilo Krummrich wrote:
>
> > Once we get to a conclusion I can send a series with only the device and
> > firmare
> > abstractions such that we can get them in outside of the scope o
On 6/6/24 02:48, Steven Rostedt wrote:
On Thu, 30 May 2024 20:16:05 +
Mina Almasry wrote:
@@ -42,51 +42,52 @@ TRACE_EVENT(page_pool_release,
TRACE_EVENT(page_pool_state_release,
TP_PROTO(const struct page_pool *pool,
-const struct page *page, u32 release),
+
[CCing the other amd drm maintainers]
On 05.06.24 14:04, Mikhail Gavrilov wrote:
> On Sun, May 26, 2024 at 7:06 PM Mikhail Gavrilov
> wrote:
>>
>> Day before yesterday I replaced 7900XTX to 6900XT for got clear in
>> which kernel first time appeared warning message "DMA-API: amdgpu
>> :0f:00.
On Thu, 16 May 2024, Jani Nikula wrote:
> If WERROR is already enabled, there's no point in enabling DRM_WERROR or
> asking users about it.
Ping. Any comments? (Besides the one snark.)
BR,
Jani.
>
> Reported-by: Linus Torvalds
> Closes:
> https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=ve
Hi,
On Fri, 31 May 2024 11:59:47 +0200
Danilo Krummrich wrote:
> Once we get to a conclusion I can send a series with only the device and
> firmare
> abstractions such that we can get them in outside of the scope of the reset of
> both series to get your driver going.
Since your discussion wit
On Fri, 7 Jun 2024 at 14:51, zhaoxiong lv
wrote:
>
> hi Dmitry
>
> These two panels are not the same IC but their timing is the same,
> only the init cmd and panel parameters are different, so I made it
> compatible on the kingdisplay driver.
We usually merge drivers by the driver IC, not by the
On 04/06/2024 14:32, Paweł Anikiel wrote:
> On Mon, Jun 3, 2024 at 10:37 AM Hans Verkuil wrote:
>>
>> On 07/05/2024 17:54, Paweł Anikiel wrote:
>>> Add v4l2 subdev driver for the Intel Displayport receiver FPGA IP.
>>> It is a part of the DisplayPort Intel FPGA IP Core, and supports
>>> DisplayPor
On Fri, Jun 07, 2024 at 07:44:33PM +0800, zhaoxiong lv wrote:
> hi Alex Bee
>
> I compared these two drivers. Although the control IC is the same, the
> panel is different, and the init_cmd and timing are also slightly
> different, so I added a separate driver.
But it obviously uses the same stru
Hi Maxime,
On Sun, Apr 21, 2024 at 09:52:58PM GMT, Jernej Škrabec wrote:
> Dne petek, 19. april 2024 ob 15:36:17 GMT +2 je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Sat, Feb 24, 2024 at 04:05:57PM GMT, megi xff wrote:
> > > From: Ondrej Jirman
> > >
> > > This series refactors blender setup
hi Dmitry
These two panels are not the same IC but their timing is the same,
only the init cmd and panel parameters are different, so I made it
compatible on the kingdisplay driver.
Similar to this driver: panel-boe-tv101wum-nl6.c
thanks
On Sun, Jun 2, 2024 at 12:26 AM Dmitry Baryshkov
wrote:
On Fri, 7 Jun 2024 at 14:38, zhaoxiong lv
wrote:
>
> hi Dmitry Baryshkov
>
> Because this is a separate mipi dsi driver, I did not put it in
> panel-sample-dsi.yaml.
Driver and bindings are two separate things. Bindings describe the
hardware. If there is no other reason to have a separate binding
hi Alex Bee
I compared these two drivers. Although the control IC is the same, the
panel is different, and the init_cmd and timing are also slightly
different, so I added a separate driver.
thanks
On Sun, Jun 2, 2024 at 1:07 PM Alex Bee wrote:
>
> Am 01.06.24 um 10:45 schrieb Zhaoxiong Lv:
>
>
hi Dmitry Baryshkov
Because this is a separate mipi dsi driver, I did not put it in
panel-sample-dsi.yaml.
On Sun, Jun 2, 2024 at 12:28 AM Dmitry Baryshkov
wrote:
>
> On Sat, Jun 01, 2024 at 04:45:25PM +0800, Zhaoxiong Lv wrote:
> > Create a new dt-scheam for the kd101ne3-40ti.
> > The bias IC
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
Notable features (from the H616 datasheet and implemented):
- 4096 x 2048 (4K) output support
- AFBC ARM Frame Buffer Compres
Buffers, compressed with AFBC, are generally more efficient for memory
transfers. Add support for them.
Currently it's implemented only for VI layers, but vendor code and
documentation suggest UI layers can have them too. However, I haven't
observed any SoC with such feature.
Signed-off-by: Jerne
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/drm_atomic_state_helper.c | 7 +
drivers/gpu/drm/sun4i/Makefile| 3 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c| 26 +++-
drivers/gpu/drm/sun4i/sun50i_fmt.c| 7
From: Jernej Skrabec
drm_universal_plane_init() can already call some callbacks, like
format_mod_supported, during initialization. Because of that, fields
should be initialized beforehand.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
---
drivers/gpu
From: Jernej Skrabec
Currently, only VI layer calls CSC setup function. This comes from DE2
limitation, which doesn't have CSC unit for UI layers. However, DE3 has
separate CSC units for each layer. This allows display pipeline to make
output signal in different color spaces. To support both use
From: Jernej Skrabec
Merging both function into one lets this one decide on it's own if CSC
should be enabled or not. Currently heuristics for that is pretty simple
- enable it for YUV formats and disable for RGB. However, DE3 can have
whole pipeline in RGB or YUV format. YUV pipeline will be sup
From: Jernej Skrabec
Currently, CSC module takes care only for converting YUV to RGB.
However, DE3 is more suited to work in YUV color space. Change CSC mode
argument to format type to be more neutral. New argument only tells
layer format type and doesn't imply output type.
This commit doesn't m
The Allwinner H616 and variants have a new display engine revision
(DE33).
Add display engine bus, clock and mixer bindings for the DE33.
Signed-off-by: Ryan Walklin
---
.../devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml| 1 +
.../devicetree/bindings/clock/allwinner,sun8i-a83t-de
Hi,
There is existing mainline support for the DE2 and DE3 AllWinner display
pipeline IP blocks, used in the A64 and H6 among others, however the H700 (as
well as the H616/H618 and the T507 automotive SoC) have a newer version of the
Display Engine (v3.3/DE33) which adds additional high-resolut
Jocelyn Falempe writes:
> Add a kmsg option, which will display the last lines of kmsg,
> and should be similar to fbcon.
> Add a drm.panic_screen module parameter, so you can choose between
> the different panic screens available.
> two options currently, but more will be added later:
> * "user
Jocelyn Falempe writes:
> This allows drivers to draw the pixel, and handle tiling, or specific
> color formats.
>
> v2:
> * Use fg_color for blit() functions (Javier Martinez Canillas)
>
> Signed-off-by: Jocelyn Falempe
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier M
Jocelyn Falempe writes:
Hello Jocelyn,
> The whole framebuffer is cleared, so it's useless to rewrite the
> background colored pixels. It allows to simplify the drawing
> functions, and prepare the work for the set_pixel() callback.
>
> v2:
> * keep fg16/fg24/fg32 as variable name for the blit
On Tue, 2024-06-04 at 20:27 -0400, Steven Rostedt wrote:
> On Wed, 5 Jun 2024 01:44:37 +0200
> Andrew Lunn wrote:
>
> > > Interesting, as I sped up the ftrace ring buffer by a substantial amount
> > > by
> > > adding strategic __always_inline, noinline, likely() and unlikely()
> > > throughout t
Am 07.06.24 um 03:14 schrieb wu hoi pok:
this patch is to remove the load callback from the kms_driver,
following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc
are used, most of the changes here are rdev->ddev to rdev_to_drm,
which maps to adev_to_drm in amdgpu. however this pat
Hi Randy,
Le jeudi 06 juin 2024 à 10:32 -0700, Randy Dunlap a écrit :
> Hi,
>
> On 6/5/24 4:08 AM, Paul Cercueil wrote:
> > Document the new DMABUF based API.
> >
> > Signed-off-by: Paul Cercueil
> > Signed-off-by: Nuno Sa
> >
> > ---
> > v2: - Explicitly state that the new interface is optio
On Thu, Jun 06, 2024 at 03:21:11PM -0700, Abhinav Kumar wrote:
> On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > Only several SSPP blocks support such features as YUV output or scaling,
> > thus different DRM planes have different features. Properly utilizing
> > all planes requires the attentio
94 matches
Mail list logo
