Re: New subsystem for acceleration devices
On Thu, 4 Aug 2022 at 17:44, Oded Gabbay wrote: > > On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie wrote: > > > > On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > > > > > > On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: > > > > > > > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay wrote: > > > > > > > > > > Hi, > > > > > Greg and I talked a couple of months ago about preparing a new accel > > > > > subsystem for compute/acceleration devices that are not GPUs and I > > > > > think your drivers that you are now trying to upstream fit it as well. > > > > > > > > We've had some submissions for not-GPUs to the drm subsystem recently. > > > > > > > > Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. > > > > > > > > why is creating a new subsystem at this time necessary? > > > > > > > > Are we just creating a subsystem to avoid the open source userspace > > > > consumer rules? Or do we have some concrete reasoning behind it? > > > > > > > > Dave. > > > > > > Hi Dave. > > > The reason it happened now is because I saw two drivers, which are > > > doing h/w acceleration for AI, trying to be accepted to the misc > > > subsystem. > > > Add to that the fact I talked with Greg a couple of months ago about > > > doing a subsystem for any compute accelerators, which he was positive > > > about, I thought it is a good opportunity to finally do it. > > > > > > I also honestly think that I can contribute much to these drivers from > > > my experience with the habana driver (which is now deployed in mass at > > > AWS) and contribute code from the habana driver to a common framework > > > for AI drivers. > > > > Why not port the habana driver to drm now instead? I don't get why it > > wouldn't make sense? > > imho, no, I don't see the upside. This is not a trivial change, and > will require a large effort. What will it give me that I need and I > don't have now ? The opportunity for review, code sharing, experience of locking hierarchy, mm integration? IMHO The biggest thing that drm has is the community of people who understand accelerators, memory management, userspace command submissions, fencing, dma-buf etc. It's hard to have input to those discussions from the outside, and they are always ongoing. I think one of the Intel teams reported dropping a lot of code on their drm port due to stuff already being there, I'd expect the same for you. The opposite question is also valid, what does moving to a new subsystem help you or others, when there is one with all the infrastructure and more importantly reviewers. I'd be happy to have accelerator submaintainers, I'd be happy to even create an ACCELERATOR property for non-gpu drivers, so they can opt out of some of the GPUier stuff, like multiple device node users etc, or even create a new class of device nodes under /dev/dri. > I totally agree. We need to set some rules and make sure everyone in > the kernel community is familiar with them, because now you get > different answers based on who you consult with. > > My rules of thumb that I thought of was that if you don't have any > display (you don't need to support X/wayland) and you don't need to > support opengl/vulkan/opencl/directx or any other gpu-related software > stack, then you don't have to go through drm. > In other words, if you don't have gpu-specific h/w and/or you don't > need gpu uAPI, you don't belong in drm. What happens when NVIDIA submit a driver for just compute or intel? for what is actually a GPU? This has been suggested as workaround for our userspace rules a few times. If my GPU can do compute tasks, do I have to add an accelerator subsystem driver alongside my GPU one? > After all, memory management services, or common device chars handling > I can get from other subsystems (e.g. rdma) as well. I'm sure I could > model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI > there as well), but this doesn't mean I belong there, right ? Good point, but I think accelerators do mostly belong in drm or media, because there is enough framework around them to allow them to work, without reinventing everything. > > > > I think the one area I can see a divide where a new subsystem is for > > accelerators that are single-user, one shot type things like media > > drivers (though maybe they could be just media drivers). > > > > I think anything that does command offloading to firmware or queues > > belongs in drm, because that is pretty much what the framework does. I > I think this is a very broad statement which doesn't reflect reality > in the kernel. I think the habanalabs driver is one of the only ones that is outside this really, and in major use. There might be one or two other minor drivers with no real users. Dave.
Re: [PATCH 0/3] Fix bugs in *_set_par() caused by user input
Hello,
On Thu, Aug 4, 2022 at 10:43 PM Ondrej Zajicek wrote:
>
> On Thu, Aug 04, 2022 at 08:41:22PM +0800, Zheyu Ma wrote:
> > In the function *_set_par(), the value of 'screen_size' is
> > calculated by the user input. If the user provides the improper value,
> > the value of 'screen_size' may larger than 'info->screen_size', which
> > may cause a bug in the memset_io().
>
> Hi
>
> I did not saw fbdev code in years, but should not this be already checked
> by *_check_var() ?
>
> arkfb_check_var():
>
> ...
> /* Check whether have enough memory */
> mem = ((var->bits_per_pixel * var->xres_virtual) >> 3) *
> var->yres_virtual;
> if (mem > info->screen_size)
> ...
Thanks for the reminder. But since the user can control all the
parameters of the ioctl system call, it is possible to assign
'var->bits_per_pixel' to be 0 and thus 'mem' will be 0, bypassing this
check. And in *_set_par(), when 'var->bits_per_pixel' is 0,
'screen_size' will be calculated as follows:
u32 bpp = info->var.bits_per_pixel;
if (bpp != 0) {
...
} else {
...
screen_size = (info->var.xres_virtual * info->var.yres_virtual) / 64;
}
resulting in a very large value.
regards,
Zheyu Ma
[PATCH -next RESEND] drm/amd/display: Simplify bool conversion
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c:109:52-57: WARNING:
conversion to bool not needed here
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 594fe8a4d02b..0c425c2ab2a3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -106,7 +106,7 @@ static void vblank_control_worker(struct work_struct *work)
dm->active_vblank_irq_count--;
dc_allow_idle_optimizations(
- dm->dc, dm->active_vblank_irq_count == 0 ? true : false);
+ dm->dc, dm->active_vblank_irq_count == 0);
DRM_DEBUG_KMS("Allow idle optimizations (MALL): %d\n",
dm->active_vblank_irq_count == 0);
--
2.20.1.7.g153144c
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
> +#if !defined(CONFIG_PPC)
> +static inline void out_8(void __iomem *addr, int val)
> +{ }
> +static inline void out_le32(void __iomem *addr, int val)
> +{ }
> +static inline unsigned int in_le32(const void __iomem *addr)
> +{
> + return 0;
> +}
> +#endif
These guys could just be replaced with readb/writel/readl respectively
(beware of the argument swap).
Cheers,
Ben.
Re: [PATCH v2 09/10] drm/ofdrm: Add per-model device function
On Tue, 2022-07-26 at 16:40 +0200, Michal Suchánek wrote:
> Hello,
>
> On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
> > On 7/20/22 16:27, Thomas Zimmermann wrote:
> > > Add a per-model device-function structure in preparation of adding
> > > color-management support. Detection of the individual models has been
> > > taken from fbdev's offb.
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> >
> > Reviewed-by: Javier Martinez Canillas
> >
> > [...]
> >
> > > +static bool is_avivo(__be32 vendor, __be32 device)
> > > +{
> > > + /* This will match most R5xx */
> > > + return (vendor == 0x1002) &&
> > > +((device >= 0x7100 && device < 0x7800) || (device >= 0x9400));
> > > +}
> >
> > Maybe add some constant macros to not have these magic numbers ?
>
> This is based on the existing fbdev implementation's magic numbers:
>
> drivers/video/fbdev/offb.c: ((*did >= 0x7100 && *did <
> 0x7800) ||
>
> Of course, it would be great if somebody knowledgeable could clarify
> those.
I don't think anybody remembers :-) Vendor 0x1002 is PCI_VENDOR_ID_ATI,
but the rest is basically ranges of PCI IDs for which we don't have
symbolic constants.
Cheers,
Ben.
Re: [Intel-gfx] [PATCH 3/7] drm/i915/guc: Add GuC <-> kernel time stamp translation information
I have a question on below code. Everything else looked good. Will r-b as soon as we can close on below question ...alan On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > It is useful to be able to match GuC events to kernel events when > looking at the GuC log. That requires being able to convert GuC > timestamps to kernel time. So, when dumping error captures and/or GuC > logs, include a stamp in both time zones plus the clock frequency. > > Signed-off-by: John Harrison > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -1675,6 +1678,13 @@ gt_record_uc(struct intel_gt_coredump *gt, >*/ > error_uc->guc_fw.path = kstrdup(uc->guc.fw.path, ALLOW_FAIL); > error_uc->huc_fw.path = kstrdup(uc->huc.fw.path, ALLOW_FAIL); > + > + /* > + * Save the GuC log and include a timestamp reference for converting the > + * log times to system times (in conjunction with the error->boottime > and > + * gt->clock_frequency fields saved elsewhere). > + */ > + error_uc->timestamp = intel_uncore_read(gt->_gt->uncore, > GUCPMTIMESTAMP); Alan:this register is in the GUC-SHIM domain and so unless i am mistaken u might need to ensure we hold a wakeref so that are getting a live value of the real timestamp register that this register is mirror-ing and not a stale snapshot. Or was this already done farther up the stack? Or are we doing the opposite - in which case we should ensure we drop al wakeref prior to this point. (which i am not sure is a reliable method since we wouldnt know what GuC ref was at). > error_uc->guc_log = create_vma_coredump(gt->_gt, uc->guc.log.vma, > "GuC log buffer", compress); >
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
On Wed, 2022-07-27 at 10:41 +0200, Thomas Zimmermann wrote:
>
> > > +static void __iomem *ofdrm_mach64_cmap_ioremap(struct ofdrm_device *odev,
> > > +struct device_node *of_node,
> > > +u64 fb_base)
> > > +{
> > > + struct drm_device *dev = &odev->dev;
> > > + u64 address;
> > > + void __iomem *cmap_base;
> > > +
> > > + address = fb_base & 0xff00ul;
> > > + address += 0x7ff000;
> > > +
> >
> > It would be good to know where these addresses are coming from. Maybe some
> > constant macros or a comment ? Same for the other places where addresses
> > and offsets are used.
>
> I have no idea where these values come from. I took them from offb. And
> I suspect that some of these CMAP helpers could be further merged if
> only it was clear where the numbers come from. But as i don't have the
> equipment for testing, I took most of this literally as-is from offb.
Ancient black magic :-) Old ATI mach64 chips had the registers sitting
at the end of the framebuffer. You can find an equivalent in
drivers/video/aty/atyfb_base.c:atyfb_setup_generic():
raddr = addr + 0x7ff000UL;
Cheers,
Ben.
Re: New subsystem for acceleration devices
On Thu, Aug 04, 2022 at 08:48:28PM +0300, Oded Gabbay wrote: > > The flip is true of DRM - DRM is pretty general. I bet I could > > implement an RDMA device under DRM - but that doesn't mean it should > > be done. > > > > My biggest concern is that this subsystem not turn into a back door > > for a bunch of abuse of kernel APIs going forward. Though things > > are > > How do you suggest to make sure it won't happen ? Well, if you launch the subsystem then it is your job to make sure it doesn't happen - or endure the complaints :) Accelerators have this nasty tendancy to become co-designed with their SOCs in nasty intricate ways and then there is a desire to punch through all the inconvenient layers to make it go faster. > > better now, we still see this in DRM where expediency or performance > > justifies hacky shortcuts instead of good in-kernel architecture. At > > least DRM has reliable and experienced review these days. > Definitely. DRM has some parts that are really well written. For > example, the whole char device handling with sysfs/debugfs and managed > resources code. Arguably this should all be common code in the driver core/etc - what value is a subsystem adding beyond that besides using it properly? It would be nice to at least identify something that could obviously be common, like some kind of enumeration and metadata kind of stuff (think like ethtool, devlink, rdma tool, nvemctl etc) > I think that it is clear from my previous email what I intended to > provide. A clean, simple framework for devices to register with, get > services for the most basic stuff such as device char handling, > sysfs/debugfs. This should all be trivially done by any driver using the core codes, if you see gaps I'd ask why not improve the core code? > Later on, add more simple stuff such as memory manager > and uapi for memory handling. I guess someone can say all that exists > in drm, but like I said it exists in other subsystems as well. This makes sense to me, all accelerators need a way to set a memory map, but on the other hand we are doing some very nifty stuff in this area with iommufd and it might be very interesting to just have the accelerator driver link to that API instead of building yet another copy of pin_user_pages() code.. Especially with PASID likely becoming part of any accelerator toolkit. > I want to be perfectly honest and say there is nothing special here > for AI. It's actually the opposite, it is a generic framework for > compute only. Think of it as an easier path to upstream if you just > want to do compute acceleration. Maybe in the future it will be more, > but I can't predict the future. I can't either, and to be clear I'm only questioning the merit of a "subsystem" eg with a struct class, rigerous uAPI, etc. The idea that these kinds of accel drivers deserve specialized review makes sense to me, even if they remain as unorganized char devices. Just understand that is what you are signing up for :) Jason
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson wrote: > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > > > > > ... > > > > > > > > > > > Did managed to get access to the ADV7535 programming guide? This > > > > > > > is the > > > > > > > black box here. Let me check if I can provide you a link with our > > > > > > > repo > > > > > > > so you can test our current DSIM state if you want. > > > > > > > > > > > > I do have access to the programming guide, but it's under NDA, but > > > > > > I'll try to answer questions if I can. > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > > > > from previously looking at these chips. > > > > > > > > Thanks for stepping into :) > > > > > > > > > Mine fairly plainly states: > > > > > "The DSI receiver input supports DSI video mode operation only, and > > > > > specifically, only supports nonburst mode with sync pulses". > > > > > > > > I've read this also, and we are working in nonburst mode with sync > > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > > > verify it. > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > > > > HDMI pixel rate. > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-clock. > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > configuration. > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > Okay, I just checked the bandwidth which must equal. > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > > > running at 891 / 2 = 445.5MHz. > > > > > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > > > > even more explicit about the requirement of DSI timing matching > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This > > > mode requires real time data generation as a pulse packet received > > > becomes a pulse generated. Therefore this mode requires a continuous > > > stream of data with correct video timing to avoid any visual > > > artifacts." > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS mode. > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. This > > > includes matching DPI pixel-transmission rates, and widths of timing > > > events." > > > > Thanks for sharing. > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > > > > be correct for 720p operation. > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 lanes > > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > > > > GBps. > > > > > > Has someone changed the number of lanes in use? I'd missed that if so, > > > but I'll agree that 891MHz over 2 lanes should work for 720p60. > > > > The ADV driver is changing it autom. but this logic is somehow odd and > > there was already a approach to stop the driver doing this. > > I'd missed that bit in the driver where it appears to drop to 3 lanes > for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but > probably the only way it can be achieved in the current framework. > > > To sync up: we have two problems: > > 1) The 720P mode with static DSI host configuration isn't working > > without hacks. > > 2) The DSI link frequency should changed as soon as required > > automatically. So we can provide all modes. > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > If you change your link frequency, it may be worth trying a lower > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > lanes is again listed as mandatory for using the timing generator). > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one > > > of the modes that is mandatory to use the timing generator (reg 0x27 > > > bit 7 = 1). On 2 lanes it is not required. > > > I don't know why it's referencing the 1000/1001 pixel clock rates and > > > not the base one, as it's only a base clock change with the same > > > timing (74.176MHz clock instead of 74.25MHz). > > > > Interesting! I would like to know how the HDMI block gets fetched by the > > DSI block and how the timing-generator can influence this in good/bad > > way. So that we know what DSI settings (freq, lanes) are sufficient. > > > > > > > If you do program the manual DSI divider register to allow a DSI pixel > > > >
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
On 6/13/22 07:47, Maxime Ripard wrote:
From: Dave Stevenson
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
After seeing the same warning as Stefan reported in the link below, but
on the Raspberry Pi 4B:
https://www.spinics.net/lists/dri-devel/msg354170.html
a separate bisection effort led me to this commit, before is fine, after
produces 4 warnings during boot, see attached log.
Is there a fix that we can try that would also cover the Raspberry Pi
4B? Is it possible that this series precipitates the problem:
https://www.spinics.net/lists/arm-kernel/msg984638.html
--
FlorianStarting start4.elf @ 0xfec00200 partition -1
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.19.0-rc2 (florian@silverado) (arm-buildroot-linux-gnueabi-gcc.br_real (Buildroot 2022.05-448-g7ff22c698a0d) 11.3.0, GNU ld (GNU Binutils)
2.37) #73 SMP Thu Aug 4 16:09:03 PDT 2022
[0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[0.00] earlycon: bcm2835aux0 at MMIO32 0xfe215040 (options '115200n8')
[0.00] printk: bootconsole [bcm2835aux0] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] Reserved memory: created CMA memory pool at 0x3740, size 64 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0xfbff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x3b3f]
[0.00] node 0: [mem 0x4000-0xfbff]
[0.00] Initmem setup node 0 [mem 0x-0xfbff]
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at arch/arm/mm/physaddr.c:40 __virt_to_phys+0x84/0xbc
[0.00] virt_to_phys used for non-linear address: (0x0)
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc2 #73
[0.00] Hardware name: BCM2711
[0.00] unwind_backtrace from show_stack+0x18/0x1c
[0.00] show_stack from dump_stack_lvl+0x40/0x4c
[0.00] dump_stack_lvl from __warn+0xb0/0x12c
[0.00] __warn from warn_slowpath_fmt+0x80/0xc0
[0.00] warn_slowpath_fmt from __virt_to_phys+0x84/0xbc
[0.00] __virt_to_phys from pcpu_embed_first_chunk+0x588/0x7cc
[0.00] pcpu_embed_first_chunk from setup_per_cpu_areas+0x24/0xa0
[0.00] setup_per_cpu_areas from start_kernel+0x1a8/0x6b8
[0.00] start_kernel from 0x0
[0.00] ---[ end trace ]---
[0.00] percpu: Embedded 16 pages/cpu s35860 r8192 d21484 u65536
[0.00] Built 1 zonelists, mobility grouping on. Total pages: 1011200
[0.00] Kernel command line: dma.dmachans=0x71f5 bcm2709.boardrev=0xc03111 bcm2709.serial=0x4b11cb83 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm270
9.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:1C:A0:82 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 earlycon earlyprintk
[0.00] Unknown kernel command line parameters "earlyprintk", will be passed to user space.
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] software IO TLB: mapped [mem 0x29079000-0x2d079000] (64MB)
[0.00] Memory: 3851564K/4050944K available (10240K kernel code, 1703K rwdata, 3832K rodata, 16384K init, 478K bss, 133844K reserved, 65536K cma-reserved, 319897
6K highmem)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 38049 entries in 112 pages
[0.00] ftrace: allocated 112
Re: [PATCH v2 4/4] Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode
On 2022-08-04 11:01, Melissa Wen wrote: AMD GPU display manager (DM) maps DRM pixel blend modes (None, Pre-multiplied, Coverage) to MPC hw blocks through blend configuration options. Describe relevant elements and how to set and test them to get the expected DRM blend mode on DCN hw. v2: - add ref tag (Tales) Signed-off-by: Melissa Wen Reviewed-by: Tales Aparecida --- .../gpu/amdgpu/display/display-manager.rst| 98 +++ Documentation/gpu/drm-kms.rst | 2 + 2 files changed, 100 insertions(+) diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index 88e2c08c7014..b7abb18cfc82 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -83,3 +83,101 @@ schemas. **DCN 3.0 family color caps and mapping** .. kernel-figure:: dcn3_cm_drm_current.svg + +Blend Mode Properties += + +Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` used to +describes how pixels from a foreground plane (fg) are composited with the +background plane (bg). Here, we present main concepts of DRM blend mode to help +to understand how this property is mapped to AMD DC interface. See more about +this DRM property and the alpha blending equations in :ref:`DRM Plane +Composition Properties `. + +Basically, a blend mode sets the alpha blending equation for plane +composition that fits the mode in which the alpha channel affects the state of +pixel color values and, therefore, the resulted pixel color. For +example, consider the following elements of the alpha blending equation: + +- *fg.rgb*: Each of the RGB component values from the foreground's pixel. +- *fg.alpha*: Alpha component value from the foreground's pixel. +- *bg.rgb*: Each of the RGB component values from the background. +- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see + more in :ref:`DRM Plane Composition Properties `. + +in the basic alpha blending equation:: + + out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb + +the alpha channel value of each pixel in a plane is ignored and only the plane +alpha affects the resulted pixel color values. + +DRM has three blend mode to define the blend formula in the plane composition: + +* **None**: Blend formula that ignores the pixel alpha. + +* **Pre-multiplied**: Blend formula that assumes the pixel color values in a + plane was already pre-multiplied by its own alpha channel before storage. + +* **Coverage**: Blend formula that assumes the pixel color values were not + pre-multiplied with the alpha channel values. + +and pre-multiplied is the default pixel blend mode, that means, when no blend +mode property is created or defined, DRM considers the plane's pixels has +pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test +provides a set of subtests to verify plane alpha and blend mode properties. + +The DRM blend mode and its elements are then mapped by AMDGPU display manager +(DM) to program the blending configuration of the Multiple Pipe/Plane Combined +(MPC), as follows: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :doc: mpc-overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_blnd_cfg + +Therefore, the blending configuration for a single MPCC instance on the MPC +tree is defined by :c:type:`mpcc_blnd_cfg`, where +:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to +set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is +multiplied (true/false), being only true for DRM pre-multiplied blend mode. +:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel +alpha and plane alpha values. It sets one of the three modes for +:c:type:`MPCC_ALPHA_BLND_MODE`, as described below. + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_alpha_blend_mode + +DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM +blend formula, as follows: + +* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value + from the plane's pixel +* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should + be ignored and, therefore, pixel values are not pre-multiplied +* *MPC global gain* assumes *MPC global alpha* value when both *DRM + fg.alpha* and *DRM plane_alpha* participate in the blend equation + +In short, *fg.alpha* is ignored by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha * +fg.alpha) component becomes available by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the +:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are +pre-multiplied by alpha or not. + +Blend configuration flow + + +The alpha blending equation is configured from DRM to D
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 04, 2022 at 02:59:01PM -0700, Linus Torvalds wrote:
> On Thu, Aug 4, 2022 at 1:43 PM Nathan Chancellor wrote:
> >
> > I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> > in the mode support function") did have a workaround for GCC. It appears
> > clang will still inline mode_support_configuration(). If I mark it as
> > 'noinline', the warning disappears in that file.
>
> That sounds like probably the best option for now. Gcc does not inline
> that function (at least for allmodconfig builds in my testing), so if
> that makes clang match what gcc does, it seems a reasonable thing to
> do.
Sounds good. That solution only takes care of the warning in
display_mode_vba_32.c. I will try and come up with something similar for
the other two files tomorrow, unless the AMD folks beat me to it, since
they will know the driver better than I will ;)
Cheers,
Nathan
Re: [PATCH v2 3/4] drm/amd/display: add doc entries for MPC blending configuration
On 2022-08-04 11:01, Melissa Wen wrote:
Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discussions on AMD issue tracker[1][2].
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1734
[2] https://gitlab.freedesktop.org/drm/amd/-/issues/1769
v2:
- fix typos (Tales)
- add MPCC to MPC entry in the glossary
Signed-off-by: Melissa Wen
Reviewed-by: Tales Aparecida
---
.../gpu/amdgpu/display/dc-glossary.rst| 2 +-
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 91 ---
2 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst
b/Documentation/gpu/amdgpu/display/dc-glossary.rst
index 116f5f0942fd..0b0ffd428dd2 100644
--- a/Documentation/gpu/amdgpu/display/dc-glossary.rst
+++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst
@@ -170,7 +170,7 @@ consider asking in the amdgfx and update this page.
MC
Memory Controller
-MPC
+MPC/MPCC
Multiple pipes and plane combine
MPO
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 5097037e3962..8d86159d9de0 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -22,6 +22,16 @@
*
*/
+/**
+ * DOC: mpc-overview
+ *
+ * Multiple Pipe/Plane Combined (MPC) is a component in the hardware pipeline
+ * that performs blending of multiple planes, using global and per-pixel alpha.
+ * It also performs post-blending color correction operations according to the
+ * hardware capabilities, such as color transformation matrix and gamma 1D and
+ * 3D LUT.
+ */
+
#ifndef __DC_MPCC_H__
#define __DC_MPCC_H__
@@ -48,14 +58,39 @@ enum mpcc_blend_mode {
MPCC_BLEND_MODE_TOP_BOT_BLENDING
};
+/**
+ * enum mpcc_alpha_blend_mode - define the alpha blend mode regarding pixel
+ * alpha and plane alpha values
+ */
enum mpcc_alpha_blend_mode {
+ /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA: per pixel alpha using DPP
+* alpha value
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA,
+ /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN: per
+* pixel alpha using DPP alpha value multiplied by a global gain (plane
+* alpha)
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN,
+ /**
+* @MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA: global alpha value, ignores
+* pixel alpha and consider only plane alpha
+*/
MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA
};
-/*
- * MPCC blending configuration
+/**
+ * struct mpcc_blnd_cfg - MPCC blending configuration
+ *
+ * @black_color: background color
+ * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE)
+ * @pre_multiplied_alpha: whether pixel color values were pre-multiplied by the
+ * alpha channel (MPCC_ALPHA_MULTIPLIED_MODE)
+ * @global_gain: used when blend mode considers both pixel alpha and plane
+ * alpha value and assumes the global alpha value.
+ * @global_alpha: plane alpha value
*/
struct mpcc_blnd_cfg {
struct tg_color black_color;/* background color */
@@ -107,8 +142,15 @@ struct mpc_dwb_flow_control {
int flow_ctrl_cnt1;
};
-/*
- * MPCC connection and blending configuration for a single MPCC instance.
+/**
+ * struct mpcc - MPCC connection and blending configuration for a single MPCC
instance.
+ * @mpcc_id: MPCC physical instance
+ * @dpp_id: DPP input to this MPCC
+ * @mpcc_bot: pointer to bottom layer MPCC. NULL when not connected.
+ * @blnd_cfg: the blending configuration for this MPCC
+ * @sm_cfg: stereo mix setting for this MPCC
+ * @shared_bottom: if MPCC output to both OPP and DWB endpoints, true.
Otherwise, false.
+ *
* This struct is used as a node in an MPC tree.
*/
struct mpcc {
@@ -120,8 +162,12 @@ struct mpcc {
bool shared_bottom; /* TRUE if MPCC output to both OPP and
DWB endpoints, else FALSE */
};
-/*
- * MPC tree represents all MPCC connections for a pipe.
+/**
+ * struct mpc_tree - MPC tree represents all MPCC connections for a pipe.
+ *
+ * @opp_id: the OPP instance that owns this MPC tree
+ * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint
+ *
*/
struct mpc_tree {
int opp_id; /* The OPP instance that owns this MPC
tree */
@@ -149,13 +195,18 @@ struct mpcc_state {
uint32_t busy;
};
+/**
+ * struct mpc_funcs - funcs
+ */
struct mpc_funcs {
void (*read_mpcc_state)(
struct mpc *mpc,
int mpcc_inst,
struct mpcc_state *s);
- /*
+ /**
+* @insert_plane:
+*
* Insert DPP into MPC tree based on specified blending position.
*
Re: [PATCH v2 2/4] Documentation/amdgpu/display: add DC color caps info
On 2022-08-04 11:01, Melissa Wen wrote: Add details about color correction capabilities and explain a bit about differences between DC hw generations and also how they are mapped between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted to svg from the original png) is included to illustrate it. They were obtained from a discussion[1] in the amd-gfx mailing list. [1] https://lore.kernel.org/amd-gfx/20220422142811.dm6vtk6v64jcw...@mail.igalia.com/>> v1: - remove redundant comments (Harry) - fix typos (Harry) v2: - reword introduction of color section - add co-dev tag for Harry - who provided most of the info - fix typos (Tales) - describe missing struct parameters (Tales and Siqueira) Co-developed-by: Harry Wentland Signed-off-by: Harry Wentland Signed-off-by: Melissa Wen Reviewed-by: Tales Aparecida --- .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++ .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 + .../gpu/amdgpu/display/display-manager.rst| 34 + drivers/gpu/drm/amd/display/dc/dc.h | 77 +- 4 files changed, 2997 insertions(+), 13 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg diff --git a/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg new file mode 100644 index ..315ffc5a1a4b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg @@ -0,0 +1,1370 @@ + + + +http://www.inkscape.org/namespaces/inkscape>> + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd>> + xmlns="http://www.w3.org/2000/svg>> + xmlns:svg="http://www.w3.org/2000/svg>> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Matrix +1D LUT +3D LUT +Unpacking +Other +drm_framebuffer +format +drm_plane +drm_crtc +Stream +MPC +DPP + +Blender +Degamma +CTM +Gamma +format +bias_and_scale +color space matrix +input_csc_color_matrix +in_transfer_func +hdr_mult +gamut_remap_matrix +in_shaper_func +lut3d_func +blend_tf +Blender +gamut_remap_matrix +func_shaper +lut3d_func +out_transfer_func +csc_color_matrix +bit_depth_param +clamping +output_color_space +Plane +Legend +DCN 2.0 +DC Interface +DRM Interface + +CNVC +Input CSC +DeGammaRAM and ROM(sRGB, BT2020 +HDR Multiply +Gamut Remap +Shaper LUTRAM +3D LUTRAM +Blend Gamma +Blender +GammaRAM +OCSC + + +color_encoding + +pixel_blend_mode + +color_range + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg new file mode 100644 index ..7299ee9b6d64 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg @@ -0,0 +1,1529 @@ + + + +http://www.inkscape.org/namespaces/inkscape>> + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd>> + xmlns="http://www.w3.org/2000/svg>> + xmlns:svg="http://www.w3.org/2000/svg>> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Matrix +1D LUT +3D LUT +Unpacking +Other +drm_framebuffer +format +drm_plane +drm_crtc +Stream +MPC +DPP + +Blender +Degamma +CTM +Gamma +format +bias_and_scale +color space matrix +input_csc_color_matrix +in_transfer_func +hdr_mult +gamut_remap_matrix +in_shaper_func +lut3d_func +blend_tf +Blender +gamut_remap_matrix +func_shaper +lut3d_func +out_transfer_func +csc_color_matrix +bit_depth_param +clamping +output_color_space +Plane +Legend +DCN 3.0 +DC Interface +DRM Interf
Re: [PATCH v2 1/4] Documentation/amdgpu_dm: Add DM color correction documentation
On 2022-08-04 11:01, Melissa Wen wrote:
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
v2:
- rebase to amd-staging-drm-next
- fix typos (Tales)
- undo kernel-docs inside functions (Tales)
Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Reviewed-by: Tales Aparecida
---
.../gpu/amdgpu/display/display-manager.rst| 9 ++
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 109 +-
2 files changed, 90 insertions(+), 28 deletions(-)
diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 7ce31f89d9a0..b1b0f11aed83 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -40,3 +40,12 @@ Atomic Implementation
.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
:functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
+
+Color Management Properties
+===
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+ :internal:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index a71177305bcd..a4cb23d059bd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -29,7 +29,9 @@
#include "modules/color/color_gamma.h"
#include "basics/conversion.h"
-/*
+/**
+ * DOC: overview
+ *
* The DC interface to HW gives us the following color management blocks
* per pipe (surface):
*
@@ -71,8 +73,8 @@
#define MAX_DRM_LUT_VALUE 0x
-/*
- * Initialize the color module.
+/**
+ * amdgpu_dm_init_color_mod - Initialize the color module.
*
* We're not using the full color module, only certain components.
* Only call setup functions for components that we need.
@@ -82,7 +84,14 @@ void amdgpu_dm_init_color_mod(void)
setup_x_points_distribution();
}
-/* Extracts the DRM lut and lut size from a blob. */
+/**
+ * __extract_blob_lut - Extracts the DRM lut and lut size from a blob.
+ * @blob: DRM color mgmt property blob
+ * @size: lut size
+ *
+ * Returns:
+ * DRM LUT or NULL
+ */
static const struct drm_color_lut *
__extract_blob_lut(const struct drm_property_blob *blob, uint32_t *size)
{
@@ -90,13 +99,18 @@ __extract_blob_lut(const struct drm_property_blob *blob,
uint32_t *size)
return blob ? (struct drm_color_lut *)blob->data : NULL;
}
-/*
- * Return true if the given lut is a linear mapping of values, i.e. it acts
- * like a bypass LUT.
+/**
+ * __is_lut_linear - check if the given lut is a linear mapping of values
+ * @lut: given lut to check values
+ * @size: lut size
*
* It is considered linear if the lut represents:
- * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in
- * [0, MAX_COLOR_LUT_ENTRIES)
+ * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in [0,
+ * MAX_COLOR_LUT_ENTRIES)
+ *
+ * Returns:
+ * True if the given lut is a linear mapping of values, i.e. it acts like a
+ * bypass LUT. Otherwise, false.
*/
static bool __is_lut_linear(const struct drm_color_lut *lut, uint32_t size)
{
@@ -119,9 +133,13 @@ static bool __is_lut_linear(const struct drm_color_lut
*lut, uint32_t size)
return true;
}
-/*
- * Convert the drm_color_lut to dc_gamma. The conversion depends on the size
- * of the lut - whether or not it's legacy.
+/**
+ * __drm_lut_to_dc_gamma - convert the drm_color_lut to dc_gamma.
+ * @lut: DRM lookup table for color conversion
+ * @gamma: DC gamma to set entries
+ * @is_legacy: legacy or atomic gamma
+ *
+ * The conversion depends on the size of the lut - whether or not it's legacy.
*/
static void __drm_lut_to_dc_gamma(const struct drm_color_lut *lut,
struct dc_gamma *gamma, bool is_legacy)
@@ -154,8 +172,11 @@ static void __drm_lut_to_dc_gamma(const struct
drm_color_lut *lut,
}
}
-/*
- * Converts a DRM CTM to a DC CSC float matrix.
+/**
+ * __drm_ctm_to_dc_matrix - converts a DRM CTM to a DC CSC float matrix
+ * @ctm: DRM color transformation matrix
+ * @matrix: DC CSC float matrix
+ *
* The matrix needs to be a 3x4 (12 entry) matrix.
*/
static void __drm_ctm_to_dc_matrix(const struct drm_color_ctm *ctm,
@@ -189,7 +210,18 @@ static void __drm_ctm_to_dc_matrix(const struct
drm_color_ctm *ctm,
}
}
-/* Calculates the legacy transfer function - only for sRGB input space. */
+/**
+ * __set_legacy_tf - Calculates the legacy transfer function
+ * @func: transfer function
+ * @lut: lookup table that defines the color space
+ * @lut_size: size of res
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 4, 2022 at 1:43 PM Nathan Chancellor wrote:
>
> I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> in the mode support function") did have a workaround for GCC. It appears
> clang will still inline mode_support_configuration(). If I mark it as
> 'noinline', the warning disappears in that file.
That sounds like probably the best option for now. Gcc does not inline
that function (at least for allmodconfig builds in my testing), so if
that makes clang match what gcc does, it seems a reasonable thing to
do.
Linus
Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"
On Fri, 5 Aug 2022 at 01:53, Mike Lothian wrote: > > Hi > > When is this relanding? It should be in Linus tree now enabled. Dave.
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote:
> On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
> wrote:
> >
> > On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
> > wrote:cov_trace_cmp
> > >
> > > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> > > display engine with KCOV enabled").
> >
> > Ahh. So that was presumably why it was disabled before - because it
> > presumably does disgusting things that make KCOV generate even bigger
> > stack frames than it already has.
> >
> > Those functions do seem to have fairly big stack footprints already (I
> > didn't try to look into why, I assume it's partly due to aggressive
> > inlining, and probably some automatic structures on stack). But gcc
> > doesn't seem to make it all that much worse with KCOV (and my clang
> > build doesn't enable KCOV).
> >
> > So it's presumably some KCOV-vs-clang thing. Nathan?
Looks like Arnd beat me to it :)
> The dependency was originally added to avoid a link failure in 9d1d02ff3678
> ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported
> the
> problem in
> https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html
>
> The commit from the bisection just turns off KCOV for the entire directory
> to avoid the link failure, so it's not actually a problem with KCOV vs clang,
> but I think a problem with clang vs badly written code that was obscured
> in allmodconfig builds prior to this.
Right, I do think the sanitizers make things worse here too, as those get
enabled with allmodconfig. I ran some really quick tests with allmodconfig and
a few instrumentation options flipped on/off:
allmodconfig (CONFIG_KASAN=y, CONFIG_KCSAN=n, CONFIG_KCOV=y, and
CONFIG_UBSAN=y):
warning: stack frame size (2216) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2184) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2176) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
allmodconfig + CONFIG_KASAN=n:
warning: stack frame size (2112) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
allmodconfig + CONFIG_KCOV=n:
warning: stack frame size (2216) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2184) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2176) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
allmodconfig + CONFIG_UBSAN=n:
warning: stack frame size (2584) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2680) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2352) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=y + CONFIG_UBSAN=n:
warning: stack frame size (2504) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2600) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
warning: stack frame size (2264) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=n + CONFIG_UBSAN=n:
warning: stack frame size (2072) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
There might be other debugging configurations that make this worse too,
as I don't see those warnings on my distribution configuration.
> The dml30_ModeSupportAndSystemConfigurationFull() function exercises
> a few paths in the compiler that are otherwise rare. On thing it does is to
> pass up to 60 arguments to other functions, and it heavily uses float and
> double variables. Both of these make it rather fragile when it comes to
> unusual compiler options, so the files keep coming up whenever a new
> instrumentation feature gets added. There is probably some other flag
> in allmodconfig that we can disable to improve this again, but I have not
> checked this time.
I do notice that these files build with a non-configurable
-Wframe-large-than value:
$ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
54:frame_warn_flag := -Wframe-larger-than=2048
70:CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags)
$(frame_warn_flag)
72:CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags)
$(frame_warn_flag)
76:CFLAGS_$(AMDDALPATH)/dc/dml/dcn32/display_mode_vba_32.o := $(dml_ccflags)
$(frame_warn_flag)
I suppose that could just be bumped as a quick workaround? Two of tho
Re: [PATCH 11/12] drm/format-helper: Rework XRGB8888-to-MONO conversion
On Wed, Jul 27, 2022 at 01:33:11PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-MONO conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 28 +++-
> drivers/gpu/drm/solomon/ssd130x.c | 7 ---
> drivers/gpu/drm/tiny/repaper.c | 6 +-
> include/drm/drm_format_helper.h | 5 +++--
> 4 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 521932fac491..d296d181659d 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -680,9 +680,9 @@ static void drm_fb_gray8_to_mono_line(void *dbuf, const
> void *sbuf, unsigned int
>
> /**
> * drm_fb_xrgb_to_mono - Convert XRGB to monochrome
It should be documented that this only supports system memory (no io
memory support).
Sam
> - * @dst: monochrome destination buffer (0=black, 1=white)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of monochrome destination buffers (0=black, 1=white)
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> @@ -700,26 +700,36 @@ static void drm_fb_gray8_to_mono_line(void *dbuf, const
> void *sbuf, unsigned int
> * x-coordinate that is a multiple of 8, then the caller must take care
> itself
> * of supplying a suitable clip rectangle.
> */
> -void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> - const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_mono(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> unsigned int linepixels = drm_rect_width(clip);
> unsigned int lines = drm_rect_height(clip);
> unsigned int cpp = fb->format->cpp[0];
> unsigned int len_src32 = linepixels * cpp;
> struct drm_device *dev = fb->dev;
> + void *vaddr = vmap[0].vaddr;
> + unsigned int dst_pitch_0;
> unsigned int y;
> - u8 *mono = dst, *gray8;
> + u8 *mono = dst[0].vaddr, *gray8;
> u32 *src32;
>
> if (drm_WARN_ON(dev, fb->format->format != DRM_FORMAT_XRGB))
> return;
>
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> + dst_pitch_0 = dst_pitch[0];
> +
> /*
>* The mono destination buffer contains 1 bit per pixel
>*/
> - if (!dst_pitch)
> - dst_pitch = DIV_ROUND_UP(linepixels, 8);
> + if (!dst_pitch_0)
> + dst_pitch_0 = DIV_ROUND_UP(linepixels, 8);
>
> /*
>* The cma memory is write-combined so reads are uncached.
> @@ -744,7 +754,7 @@ void drm_fb_xrgb_to_mono(void *dst, unsigned int
> dst_pitch, const void *vadd
> drm_fb_xrgb_to_gray8_line(gray8, src32, linepixels);
> drm_fb_gray8_to_mono_line(mono, gray8, linepixels);
> vaddr += fb->pitches[0];
> - mono += dst_pitch;
> + mono += dst_pitch_0;
> }
>
> kfree(src32);
> diff --git a/drivers/gpu/drm/solomon/ssd130x.c
> b/drivers/gpu/drm/solomon/ssd130x.c
> index 5a3e3b78cd9e..aa7329a65c98 100644
> --- a/drivers/gpu/drm/solomon/ssd130x.c
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -537,11 +537,11 @@ static void ssd130x_clear_screen(struct ssd130x_device
> *ssd130x)
> kfree(buf);
> }
>
> -static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb, const struct
> iosys_map *map,
> +static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb, const struct
> iosys_map *vmap,
> struct drm_rect *rect)
> {
> struct ssd130x_device *ssd130x = drm_to_ssd130x(fb->dev);
> - void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
> + struct iosys_map dst;
> unsigned int dst_pitch;
> int ret = 0;
> u8 *buf = NULL;
> @@ -555,7 +555,8 @@ static int ssd130x_fb_blit_rect(struct drm_framebuffer
> *fb, const struct iosys_m
> if (!buf)
> return -ENOMEM;
>
> - drm_fb_xrgb_to_mono(buf, dst_pitch, vmap, fb, rect);
> + iosys_map_set_vaddr(&dst, buf);
> + drm_fb_xrgb_to_mono(&dst, &dst_pitch, vmap, fb, rect);
>
> ssd130x_update_rect(ssd130x, buf
Re: [PATCH 10/12] drm/format-helper: Rework XRGB8888-to-GRAY8 conversion
On Wed, Jul 27, 2022 at 01:33:10PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-GRAY8 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 +++--
> drivers/gpu/drm/gud/gud_pipe.c | 7 +--
> drivers/gpu/drm/tiny/st7586.c | 5 -
> include/drm/drm_format_helper.h | 5 +++--
> 4 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 209f63b66c5f..521932fac491 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -552,9 +552,9 @@ static void drm_fb_xrgb_to_gray8_line(void *dbuf,
> const void *sbuf, unsigned
>
> /**
> * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
> - * @dst: 8-bit grayscale destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of 8-bit grayscale destination buffers
> + * @dst_pitch: Array of number of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> @@ -567,10 +567,23 @@ static void drm_fb_xrgb_to_gray8_line(void *dbuf,
> const void *sbuf, unsigned
> *
> * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
> */
> -void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> - const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_gray8(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 1, vaddr, fb, clip, false,
> drm_fb_xrgb_to_gray8_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 1,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_gray8_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 1, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_gray8_line);
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 0caa228f736d..7c6dc2bcd14a 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -59,6 +59,7 @@ static size_t gud_xrgb_to_r124(u8 *dst, const struct
> drm_format_info *format
> unsigned int bits_per_pixel = 8 / block_width;
> unsigned int x, y, width, height;
> u8 pix, *pix8, *block = dst; /* Assign to silence compiler warning */
> + struct iosys_map dst_map, vmap;
> size_t len;
> void *buf;
>
> @@ -74,7 +75,9 @@ static size_t gud_xrgb_to_r124(u8 *dst, const struct
> drm_format_info *format
> if (!buf)
> return 0;
>
> - drm_fb_xrgb_to_gray8(buf, 0, src, fb, rect);
> + iosys_map_set_vaddr(&dst_map, buf);
> + iosys_map_set_vaddr(&vmap, src);
> + drm_fb_xrgb_to_gray8(&dst_map, NULL, &vmap, fb, rect);
> pix8 = buf;
>
> for (y = 0; y < height; y++) {
> @@ -194,7 +197,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> goto end_cpu_access;
> }
> } else if (format->format == DRM_FORMAT_R8) {
> - drm_fb_xrgb_to_gray8(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_gray8(&dst, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB332) {
> drm_fb_xrgb_to_rgb332(&dst, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB565) {
> diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
> index 8eddb020c43e..702350d0f8bc 100644
> --- a/drivers/gpu/drm/tiny/st7586.c
> +++ b/drivers/gpu/drm/tiny/st7586.c
> @@ -69,12 +69,15 @@ static void st7586_xrgb_to_gray332(u8 *dst, void
> *vaddr,
> size_t len = (clip->x2 - clip->x1) * (clip->y2 - clip->y1);
> unsigned int x, y;
> u8 *src, *buf, val;
> + struct iosys_map dst_map, vmap;
>
> buf = kmalloc(len, GFP_KERNEL);
> if (!buf)
> return;
>
> - drm_fb_xrgb_to_gray8(buf, 0, va
Re: [PATCH 09/12] drm/format-helper: Rework XRGB8888-to-XRGB2101010 conversion
On Wed, Jul 27, 2022 at 01:33:09PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-XRGB2101010 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Sam Ravnborg
> drivers/gpu/drm/drm_format_helper.c | 35 +
> include/drm/drm_format_helper.h | 6 ++---
> 2 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 155827eebe99..209f63b66c5f 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -504,26 +504,34 @@ static void drm_fb_xrgb_to_xrgb2101010_line(void
> *dbuf, const void *sbuf, un
> }
>
> /**
> - * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
> - * buffer
> - * @dst: XRGB2101010 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * drm_fb_xrgb_to_xrgb2101010 - Convert XRGB to XRGB2101010 clip
> buffer
> + * @dst: Array of XRGB2101010 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for XRGB2101010 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
> - unsigned int dst_pitch, const void
> *vaddr,
> - const struct drm_framebuffer *fb,
> - const struct drm_rect *clip)
> +void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_xrgb2101010_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false,
> drm_fb_xrgb_to_xrgb2101010_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_xrgb2101010_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
>
> static void drm_fb_xrgb_to_gray8_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -628,8 +636,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_xrgb2101010_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> - vmap[0].vaddr, fb,
> clip);
> + drm_fb_xrgb_to_xrgb2101010(dst, dst_pitch, vmap,
> fb, clip);
> return 0;
> }
> }
> diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
> index 8c633dbab5d6..6807440ce29c 100644
> --- a/include/drm/drm_format_helper.h
> +++ b/include/drm/drm_format_helper.h
> @@ -29,9 +29,9 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const
> unsigned int *dst_pi
> void drm_fb_xrgb_to_rgb888(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> const struct drm_rect *clip);
> -void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip);
> +void drm_fb_xrgb_to_xrgb2101010(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip);
> void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> const struct drm_framebuffer *fb, const struct
> drm_rect *clip);
>
> --
> 2.37.1
Re: [PATCH 08/12] drm/format-helper: Rework RGB888-to-XRGB8888 conversion
On Wed, Jul 27, 2022 at 01:33:08PM +0200, Thomas Zimmermann wrote:
> Update RGB888-to-XRGB conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 5ef06f696657..155827eebe99 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -465,12 +465,24 @@ static void drm_fb_rgb888_to_xrgb_line(void *dbuf,
> const void *sbuf, unsigne
> }
> }
>
> -static void drm_fb_rgb888_to_xrgb_toio(void __iomem *dst, unsigned int
> dst_pitch,
> -const void *vaddr, const struct
> drm_framebuffer *fb,
> -const struct drm_rect *clip)
> +static void drm_fb_rgb888_to_xrgb(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap,
> + const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_rgb888_to_xrgb_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb888_to_xrgb_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb888_to_xrgb_line);
> }
>
> static void drm_fb_xrgb_to_xrgb2101010_line(void *dbuf, const void
> *sbuf, unsigned int pixels)
> @@ -608,8 +620,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> if (fb_format == DRM_FORMAT_RGB888) {
> - drm_fb_rgb888_to_xrgb_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_rgb888_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> } else if (fb_format == DRM_FORMAT_RGB565) {
> drm_fb_rgb565_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> --
> 2.37.1
Re: [PATCH 07/12] drm/format-helper: Rework RGB565-to-XRGB8888 conversion
On Wed, Jul 27, 2022 at 01:33:07PM +0200, Thomas Zimmermann wrote:
> Update RGB565-to-XRGB conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 4edab44336d8..5ef06f696657 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -430,12 +430,24 @@ static void drm_fb_rgb565_to_xrgb_line(void *dbuf,
> const void *sbuf, unsigne
> }
> }
>
> -static void drm_fb_rgb565_to_xrgb_toio(void __iomem *dst, unsigned int
> dst_pitch,
> -const void *vaddr, const struct
> drm_framebuffer *fb,
> -const struct drm_rect *clip)
> +static void drm_fb_rgb565_to_xrgb(struct iosys_map *dst, const unsigned
> int *dst_pitch,
> + const struct iosys_map *vmap,
> + const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> - drm_fb_xfrm_toio(dst, dst_pitch, 4, vaddr, fb, clip, false,
> - drm_fb_rgb565_to_xrgb_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 4,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb565_to_xrgb_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 4, vmap[0].vaddr, fb,
> + clip, false, drm_fb_rgb565_to_xrgb_line);
> }
>
> static void drm_fb_rgb888_to_xrgb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> @@ -600,8 +612,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> vmap[0].vaddr, fb, clip);
> return 0;
> } else if (fb_format == DRM_FORMAT_RGB565) {
> - drm_fb_rgb565_to_xrgb_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_rgb565_to_xrgb(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB2101010) {
> --
> 2.37.1
Re: [PATCH 06/12] drm/format-helper: Rework XRGB8888-to-RGB888 conversion
On Wed, Jul 27, 2022 at 01:33:06PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB888 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 48 -
> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
> drivers/gpu/drm/tiny/cirrus.c | 3 +-
> include/drm/drm_format_helper.h | 8 ++---
> 4 files changed, 25 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 8bf5655f5ce0..4edab44336d8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -383,41 +383,34 @@ static void drm_fb_xrgb_to_rgb888_line(void *dbuf,
> const void *sbuf, unsigne
>
> /**
> * drm_fb_xrgb_to_rgb888 - Convert XRGB to RGB888 clip buffer
> - * @dst: RGB888 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: XRGB source buffer
> + * @dst: Array of RGB888 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for RGB888 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_rgb888(void *dst, unsigned int dst_pitch, const void
> *src,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_rgb888(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 3, src, fb, clip, false,
> drm_fb_xrgb_to_rgb888_line);
> -}
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
>
> -/**
> - * drm_fb_xrgb_to_rgb888_toio - Convert XRGB to RGB888 clip buffer
> - * @dst: RGB565 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - *
> - * Drivers can use this function for RGB888 devices that don't natively
> - * support XRGB.
> - */
> -void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip)
> -{
> - drm_fb_xfrm_toio(dst, dst_pitch, 3, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb888_line);
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 3,
> vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_rgb888_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 3, vmap[0].vaddr, fb,
> + clip, false, drm_fb_xrgb_to_rgb888_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
>
> static void drm_fb_rgb565_to_xrgb_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -598,8 +591,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
> }
> } else if (dst_format == DRM_FORMAT_RGB888) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb888_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip);
> + drm_fb_xrgb_to_rgb888(dst, dst_pitch, vmap, fb,
> clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index a43eb6645352..0caa228f736d 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -201,7 +201,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> drm_fb_xrgb_to_rgb565(&dst, NULL, map_data, fb,
> rect,
> gud_is_big_endian());
> } else if (format->format == DRM_FORMAT_RGB888) {
> - drm_fb_xrgb_to_rgb888(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_rgb888(&dst, NULL, map_d
Re: [PATCH 05/12] drm/format-helper: Rework XRGB8888-to-RGBG565 conversion
On Wed, Jul 27, 2022 at 01:33:05PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB565 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 59 +++--
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/gud/gud_pipe.c | 3 +-
> drivers/gpu/drm/tiny/cirrus.c | 3 +-
> include/drm/drm_format_helper.h | 9 ++---
> 5 files changed, 30 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 2b5c3746ff4a..8bf5655f5ce0 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -330,9 +330,9 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void
> *dbuf, const void *sbuf,
>
> /**
> * drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of RGB565 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffer
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> * @swab: Swap bytes
> @@ -340,43 +340,31 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void
> *dbuf, const void *sbuf,
> * Drivers can use this function for RGB565 devices that don't natively
> * support XRGB.
> */
> -void drm_fb_xrgb_to_rgb565(void *dst, unsigned int dst_pitch, const void
> *vaddr,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip,
> -bool swab)
> +void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip, bool swab)
> {
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned int npixels);
> +
> if (swab)
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_swab_line);
> + xfrm_line = drm_fb_xrgb_to_rgb565_swab_line;
> else
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_line);
> -}
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
> + xfrm_line = drm_fb_xrgb_to_rgb565_line;
>
> -/**
> - * drm_fb_xrgb_to_rgb565_toio - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - * @swab: Swap bytes
> - *
> - * Drivers can use this function for RGB565 devices that don't natively
> - * support XRGB.
> - */
> -void drm_fb_xrgb_to_rgb565_toio(void __iomem *dst, unsigned int
> dst_pitch,
> - const void *vaddr, const struct
> drm_framebuffer *fb,
> - const struct drm_rect *clip, bool swab)
> -{
> - if (swab)
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_swab_line);
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 2,
> vmap[0].vaddr, fb, clip,
> + false, xfrm_line);
> else
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_line);
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 2, vmap[0].vaddr, fb,
> clip,
> + false, xfrm_line);
> }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_toio);
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>
> static void drm_fb_xrgb_to_rgb888_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> {
> @@ -605,8 +593,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int
> *dst_pitch, uint32_t d
>
> } else if (dst_format == DRM_FORMAT_RGB565) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb565_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip,
> false);
> + drm_fb_xrgb_to_rgb565(dst, dst
Re: [PATCH 04/12] drm/format-helper: Rework XRGB8888-to-RGBG332 conversion
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:04PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB332 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
>
> Signed-off-by: Thomas Zimmermann
I am not going to repeat my naming rant here, so
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 25 ++-
> drivers/gpu/drm/gud/gud_pipe.c| 2 +-
> .../gpu/drm/tests/drm_format_helper_test.c| 14 ++-
> include/drm/drm_format_helper.h | 5 ++--
> 4 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index fa22d3cb11e8..2b5c3746ff4a 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -265,18 +265,31 @@ static void drm_fb_xrgb_to_rgb332_line(void *dbuf,
> const void *sbuf, unsigne
>
> /**
> * drm_fb_xrgb_to_rgb332 - Convert XRGB to RGB332 clip buffer
> - * @dst: RGB332 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: XRGB source buffer
> + * @dst: Array of RGB332 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
> + * @vmap: Array of XRGB source buffers
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * Drivers can use this function for RGB332 devices that don't natively
> support XRGB.
> */
> -void drm_fb_xrgb_to_rgb332(void *dst, unsigned int dst_pitch, const void
> *src,
> -const struct drm_framebuffer *fb, const struct
> drm_rect *clip)
> +void drm_fb_xrgb_to_rgb332(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip)
> {
> - drm_fb_xfrm(dst, dst_pitch, 1, src, fb, clip, false,
> drm_fb_xrgb_to_rgb332_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 1,
> vmap[0].vaddr, fb, clip,
> + false, drm_fb_xrgb_to_rgb332_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 1, vmap[0].vaddr, fb,
> clip,
> + false, drm_fb_xrgb_to_rgb332_line);
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
>
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index a15cda9ba058..426a3ae6cc50 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -196,7 +196,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> } else if (format->format == DRM_FORMAT_R8) {
> drm_fb_xrgb_to_gray8(buf, 0, vaddr, fb, rect);
> } else if (format->format == DRM_FORMAT_RGB332) {
> - drm_fb_xrgb_to_rgb332(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_rgb332(&dst, NULL, map_data, fb,
> rect);
> } else if (format->format == DRM_FORMAT_RGB565) {
> drm_fb_xrgb_to_rgb565(buf, 0, vaddr, fb, rect,
> gud_is_big_endian());
> } else if (format->format == DRM_FORMAT_RGB888) {
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 98583bf56044..b74dba06f704 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -124,7 +124,8 @@ static void xrgb_to_rgb332_test(struct kunit *test)
> {
> const struct xrgb_to_rgb332_case *params = test->param_value;
> size_t dst_size;
> - __u8 *dst = NULL;
> + struct iosys_map dst, xrgb;
> + __u8 *buf = NULL;
>
> struct drm_framebuffer fb = {
> .format = drm_format_info(DRM_FORMAT_XRGB),
> @@ -135,12 +136,13 @@ static void xrgb_to_rgb332_test(struct kunit *test)
> ¶ms->clip);
> KUNIT_ASSERT_GT(test, dst_size, 0);
>
> - dst = kunit_kzalloc(test, dst_size, GFP_KERNEL);
> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dst);
> + buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
>
> - drm_fb_xrgb_to_rgb332(dst, params->dst_pitch, params->xrgb,
> - &fb, ¶ms->clip);
> - KUNIT_EXPECT_EQ(test, memcmp(dst, params->expected, dst_size), 0);
> + iosys_map_set_vaddr(&ds
Re: [PATCH 03/12] drm/format-helper: Convert drm_fb_swab() to struct iosys_map
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:03PM +0200, Thomas Zimmermann wrote:
> Convert drm_fb_swab() to use struct iosys_map() and convert users. The
> new interface supports multi-plane color formats.
It swabs only plane[0], sbut this is maybe enough to say so.
A few comments in the following.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 38 +
> drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
> include/drm/drm_format_helper.h | 6 ++---
> 4 files changed, 33 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 49589b442f18..fa22d3cb11e8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -196,9 +196,9 @@ static void drm_fb_swab32_line(void *dbuf, const void
> *sbuf, unsigned int pixels
>
> /**
> * drm_fb_swab - Swap bytes into clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
Document that it may be NULL?
> + * @vmap: Array of source buffers
Prefer that the source is named src, and vmap smells like system
(virtual) memory to me.
Also vmap must be system memory - but this is maybe fixed later.
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> * @cached: Source buffer is mapped cached (eg. not write-combined)
> @@ -209,24 +209,42 @@ static void drm_fb_swab32_line(void *dbuf, const void
> *sbuf, unsigned int pixels
> * This function does not apply clipping on dst, i.e. the destination
> * is at the top-left corner.
> */
> -void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
> - const struct drm_framebuffer *fb, const struct drm_rect *clip,
> - bool cached)
> +void drm_fb_swab(struct iosys_map *dst, const unsigned int *dst_pitch,
> + const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip, bool cached)
> {
> - u8 cpp = fb->format->cpp[0];
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + const struct drm_format_info *format = fb->format;
> + u8 cpp = format->cpp[0];
u8 cpp = drm_format_info_bpp(format, 0) / 8;
> + void (*swab_line)(void *dbuf, const void *sbuf, unsigned int npixels);
>
> switch (cpp) {
> case 4:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached,
> drm_fb_swab32_line);
> + swab_line = drm_fb_swab32_line;
> break;
> case 2:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached,
> drm_fb_swab16_line);
> + swab_line = drm_fb_swab16_line;
> break;
> default:
> drm_warn_once(fb->dev, "Format %p4cc has unsupported pixel
> size.\n",
> - &fb->format->format);
> + &format->format);
> + swab_line = NULL;
> break;
> }
> + if (!swab_line)
> + return;
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst->is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], cpp,
> + vmap[0].vaddr, fb, clip, cached, swab_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], cpp, vmap[0].vaddr, fb,
> + clip, cached, swab_line);
Here vmap is assumes system memory, not IO. I assume this is fixed
later.
> }
> EXPORT_SYMBOL(drm_fb_swab);
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 22451806fb5c..973a75585cad 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -221,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> switch (fb->format->format) {
> case DRM_FORMAT_RGB565:
> if (swap)
> - drm_fb_swab(dst, 0, src, fb, clip, !gem->import_attach);
> + drm_fb_swab(&dst_map, NULL, data, fb, clip,
> !gem->import_attach);
> else
> drm_fb_memcpy(&dst_map, NULL, data, fb, clip);
> break;
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 449c95a4aee0..a15cda9ba058 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -205,7 +205,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
> drm_framebuffer *fb,
> len = gud_xrgb_to_color(buf, format, vaddr, fb,
> rect);
> }
> } else if (gud_is_big_endian()
Re: New subsystem for acceleration devices
On Thu, Aug 4, 2022 at 6:04 PM Jeffrey Hugo wrote: > > On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote: > > > > On 04/08/2022 00:54, Dave Airlie wrote: > >> On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > >>> > >>> On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay > wrote: > > > > Hi, > > Greg and I talked a couple of months ago about preparing a new accel > > subsystem for compute/acceleration devices that are not GPUs and I > > think your drivers that you are now trying to upstream fit it as well. > > We've had some submissions for not-GPUs to the drm subsystem recently. > > Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. > > why is creating a new subsystem at this time necessary? > > Are we just creating a subsystem to avoid the open source userspace > consumer rules? Or do we have some concrete reasoning behind it? > > Dave. > >>> > >>> Hi Dave. > >>> The reason it happened now is because I saw two drivers, which are > >>> doing h/w acceleration for AI, trying to be accepted to the misc > >>> subsystem. > >>> Add to that the fact I talked with Greg a couple of months ago about > >>> doing a subsystem for any compute accelerators, which he was positive > >>> about, I thought it is a good opportunity to finally do it. > >>> > >>> I also honestly think that I can contribute much to these drivers from > >>> my experience with the habana driver (which is now deployed in mass at > >>> AWS) and contribute code from the habana driver to a common framework > >>> for AI drivers. > >> > >> Why not port the habana driver to drm now instead? I don't get why it > >> wouldn't make sense? > >> > >> Stepping up to create a new subsystem is great, but we need rules > >> around what belongs where, we can't just spawn new subsystems when we > >> have no clear guidelines on where drivers should land. > >> > >> What are the rules for a new accel subsystem? Do we have to now > >> retarget the 3 drivers that are queued up to use drm for accelerators, > >> because 2 drivers don't? > > > > Isn't there three on the "don't prefer drm" side as well? Habana, > > Toshiba and Samsung? Just so the numbers argument is not misrepresented. > > Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't > > care in principle; is in order? > > I'll chime in with my opinions. Take them for what you will. > > I would say I fall into the C category, but I'm targeting DRM and will > be the 5th(?) accel device to do so. > > I'll say that the ksummit (from what I see in the LWN article) made me > very happy. Finally, the community had clear rules for accel drivers. > When I targeted misc in the past, it seemed like Greg moved the goal > post just for me, which stalled our attempt. It was even more > frustrating to see that the high bar Greg set for us was not applied to > other devices of the same "class" in following submissions. > > However, the past is the past, and based on ksummit, we've spent a > number of months retargeting DRM. In a week (or two), I plan to post > something to start up the discussions again. > > As far as the DRM userspace requirements, unless we've misunderstood > something, they've been easier to satisfy (pending review I suppose) > than what misc has set. I think it is quite the opposite. In misc originally there was very minimal userspace requirements, but when my driver started to use dma-buf, Dave asked for more. e.g. a driver that wants to get accepted to DRM and use a fork of LLVM must not only open-source his code, but also to upstream his fork to the mainline LLVM tree. In misc there is nothing that closely comes to that requirement afaik. > > I would say that Dave Airlie's feedback on this discussion resonates > with me. From the perspective of a vendor wanting to be a part of the > community, clear rules are important and ksummit seemed to set that. > Oded's announcement has thrown all of that into the wind. Without a That wasn't my intention. I simply wanted to: 1. Offload Greg with these types of drivers. 2. Offer to the new drivers a standard char device handling 3. Start a community of kernel hackers that are writing device drivers for compute accelerators. > proposal to evaluate (eg show me the code with clear guidelines), I > cannot seriously consider Oded's idea, and I'm not sure I want to sit by > another few years to see it settle out. I thought of posting something quick (but not dirty) but this backlash has made me rethink that. > > I expect to move forward with what we were planning prior to seeing this > thread which is targeting DRM. We'll see what the DRM folks say when > they have something to look at. If our device doesn't fit in DRM per an > assessment of the DRM folks, then I sure hope they can suggest where we > do fit because then we'll have tried misc and DRM, and not found a home. > Since "drivers/accel" doesn't exist, and
Re: [PATCH 02/12] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:02PM +0200, Thomas Zimmermann wrote:
> Merge drm_fb_memcpy() and drm_fb_memcpy() into drm_fb_memcpy() that
One of these is drm_fb_memcpy_toio()
> uses struct iosys_map for buffers. The new function also supports
> multi-plane color formats. Convert all users of the original helpers.
A few comments in the patch below.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 77 +
> drivers/gpu/drm/drm_mipi_dbi.c | 3 +-
> drivers/gpu/drm/gud/gud_pipe.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 11 +--
> drivers/gpu/drm/mgag200/mgag200_mode.c | 11 +--
> drivers/gpu/drm/tiny/cirrus.c | 21 +++---
> include/drm/drm_format_helper.h | 7 +-
> 7 files changed, 63 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 4d74d46ab155..49589b442f18 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -131,63 +131,48 @@ static int drm_fb_xfrm_toio(void __iomem *dst, unsigned
> long dst_pitch, unsigned
>
> /**
> * drm_fb_memcpy - Copy clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines
> within dst
Document that this may be NULL, in which case the distance is considered
0.
> + * @vmap: Array of source buffers
It would have helped my understanding if this argument was named src,
so it is a little more obvious that we copy from src to dst.
Maybe document that data is copied from src based on the pitch info in
the framebuffer, and likewise the format_info in the framebuffer.
> * @fb: DRM framebuffer
> * @clip: Clip rectangle area to copy
> *
> * This function does not apply clipping on dst, i.e. the destination
> * is at the top-left corner.
> */
> -void drm_fb_memcpy(void *dst, unsigned int dst_pitch, const void *vaddr,
> -const struct drm_framebuffer *fb, const struct drm_rect
> *clip)
> +void drm_fb_memcpy(struct iosys_map *dst, const unsigned int *dst_pitch,
> +const struct iosys_map *vmap, const struct drm_framebuffer
> *fb,
> +const struct drm_rect *clip)
> {
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> -
> - if (!dst_pitch)
> - dst_pitch = len;
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
This is used in several places in this series. What I read is that a static
variable is declared where the first element in the array is set to all zeroes.
But the other elements in the array are ignored - but since it is static
they are also set to 0 so we are good here.
In some cases I see it removed again, I did not check the end result if
we end up dropping them all again.
>
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> - }
> -}
> -EXPORT_SYMBOL(drm_fb_memcpy);
> -
> -/**
> - * drm_fb_memcpy_toio - Copy clip buffer
> - * @dst: Destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - *
> - * This function does not apply clipping on dst, i.e. the destination
> - * is at the top-left corner.
> - */
> -void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch, const
> void *vaddr,
> - const struct drm_framebuffer *fb, const struct drm_rect
> *clip)
> -{
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> + const struct drm_format_info *format = fb->format;
> + unsigned int i, y, lines = drm_rect_height(clip);
>
> if (!dst_pitch)
> - dst_pitch = len;
> -
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy_toio(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> + dst_pitch = default_dst_pitch;
> +
> + for (i = 0; i < format->num_planes; ++i) {
> + unsigned int cpp_i = format->cpp[i];
unsigned int cpp_i = drm_format_info_bpp(format, i) / 8;
This avoid adding more uses of the deprecated cpp[] array.
> + size_t len_i = drm_rect_width(clip) * cpp_i;
> + unsigned int dst_pitch_i = dst_pitch[i];
> +
[PATCH] drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
As the comment right before the mtk_dsi_stop() call advises,
mtk_dsi_stop() should only be called after
mtk_drm_crtc_atomic_disable(). That's because that function calls
drm_crtc_wait_one_vblank(), which requires the vblank irq to be enabled.
Previously mtk_dsi_stop(), being in mtk_dsi_poweroff() and guarded by a
refcount, would only be called at the end of
mtk_drm_crtc_atomic_disable(), through the call to mtk_crtc_ddp_hw_fini().
Commit cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from
enable/disable and define new funcs") moved the mtk_dsi_stop() call to
mtk_output_dsi_disable(), causing it to be called before
mtk_drm_crtc_atomic_disable(), and consequently generating vblank
timeout warnings during suspend.
Move the mtk_dsi_stop() call back to mtk_dsi_poweroff() so that we have
a working vblank irq during mtk_drm_crtc_atomic_disable() and stop
getting vblank timeout warnings.
Fixes: cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from
enable/disable and define new funcs")
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9cc406e1eee1..f8ad59771551 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -685,6 +685,16 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
+ /*
+* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
+* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
+* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
+* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
+* after dsi is fully set.
+*/
+ mtk_dsi_stop(dsi);
+
+ mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -735,17 +745,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
- /*
-* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
-* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
-* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
-* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
-* after dsi is fully set.
-*/
- mtk_dsi_stop(dsi);
-
- mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
-
dsi->enabled = false;
}
--
2.37.1
Re: [PATCH 2/2] drm/cmdline-parser: Use assert when needed
Hi "Michał,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next linus/master v5.19 next-20220804]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: csky-buildonly-randconfig-r001-20220804
(https://download.01.org/0day-ci/archive/20220805/202208050307.u6yo3hhr-...@intel.com/config)
compiler: csky-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
git checkout 8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=csky SHELL=/bin/bash drivers/gpu/drm/tests/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function
'drm_cmdline_test_res_bpp_refresh_force_on_digital':
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:414:1: warning: the frame
>> size of 1120 bytes is larger than 1024 bytes [-Wframe-larger-than=]
414 | }
| ^
drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function
'drm_cmdline_test_force_D_only_hdmi':
drivers/gpu/drm/tests/drm_cmdline_parser_test.c:70:1: warning: the frame
size of 1120 bytes is larger than 1024 bytes [-Wframe-larger-than=]
70 | }
| ^
drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function
'drm_cmdline_test_force_D_only_dvi':
drivers/gpu/drm/tests/drm_cmdline_parser_test.c:91:1: warning: the frame
size of 1124 bytes is larger than 1024 bytes [-Wframe-larger-than=]
91 | }
| ^
vim +414 drivers/gpu/drm/tests/drm_cmdline_parser_test.c
9f0527d22a52ff Maíra Canal 2022-07-08 388
9f0527d22a52ff Maíra Canal 2022-07-08 389 static void
drm_cmdline_test_res_bpp_refresh_force_on_digital(struct kunit *test)
9f0527d22a52ff Maíra Canal 2022-07-08 390 {
9f0527d22a52ff Maíra Canal 2022-07-08 391 struct drm_cmdline_mode
mode = { };
8a21a5872b4bbe Michał Winiarski 2022-08-04 392 const struct
drm_connector connector = {
9f0527d22a52ff Maíra Canal 2022-07-08 393 .connector_type
= DRM_MODE_CONNECTOR_DVII,
9f0527d22a52ff Maíra Canal 2022-07-08 394 };
9f0527d22a52ff Maíra Canal 2022-07-08 395 const char *cmdline =
"720x480-24@60D";
9f0527d22a52ff Maíra Canal 2022-07-08 396
8a21a5872b4bbe Michał Winiarski 2022-08-04 397 KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
9f0527d22a52ff Maíra Canal 2022-07-08 398
&connector, &mode));
9f0527d22a52ff Maíra Canal 2022-07-08 399 KUNIT_EXPECT_TRUE(test,
mode.specified);
9f0527d22a52ff Maíra Canal 2022-07-08 400 KUNIT_EXPECT_EQ(test,
mode.xres, 720);
9f0527d22a52ff Maíra Canal 2022-07-08 401 KUNIT_EXPECT_EQ(test,
mode.yres, 480);
9f0527d22a52ff Maíra Canal 2022-07-08 402
9f0527d22a52ff Maíra Canal 2022-07-08 403 KUNIT_EXPECT_TRUE(test,
mode.refresh_specified);
9f0527d22a52ff Maíra Canal 2022-07-08 404 KUNIT_EXPECT_EQ(test,
mode.refresh, 60);
9f0527d22a52ff Maíra Canal 2022-07-08 405
9f0527d22a52ff Maíra Canal 2022-07-08 406 KUNIT_EXPECT_TRUE(test,
mode.bpp_specified);
9f0527d22a52ff Maíra Canal 2022-07-08 407 KUNIT_EXPECT_EQ(test,
mode.bpp, 24);
9f0527d22a52ff Maíra Canal 2022-07-08 408
9f0527d22a52ff Maíra Canal 2022-07-08 409
KUNIT_EXPECT_FALSE(test, mode.rb);
9f0527d22a52ff Maíra Canal 2022-07-08 410
KUNIT_EXPECT_FALSE(test, mode.cvt);
9f0527d22a52ff Maíra Canal 2022-07-08 411
KUNIT_EXPECT_FALSE(test, mode.interlace);
9f0527d22a52ff Maíra Canal 2022-07-08 412
KUNIT_EXPECT_FALSE(test, mode.margins);
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
wrote:
>
> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
> wrote:cov_trace_cmp
> >
> > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> > display engine with KCOV enabled").
>
> Ahh. So that was presumably why it was disabled before - because it
> presumably does disgusting things that make KCOV generate even bigger
> stack frames than it already has.
>
> Those functions do seem to have fairly big stack footprints already (I
> didn't try to look into why, I assume it's partly due to aggressive
> inlining, and probably some automatic structures on stack). But gcc
> doesn't seem to make it all that much worse with KCOV (and my clang
> build doesn't enable KCOV).
>
> So it's presumably some KCOV-vs-clang thing. Nathan?
The dependency was originally added to avoid a link failure in 9d1d02ff3678
("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the
problem in
https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html
The commit from the bisection just turns off KCOV for the entire directory
to avoid the link failure, so it's not actually a problem with KCOV vs clang,
but I think a problem with clang vs badly written code that was obscured
in allmodconfig builds prior to this.
The dml30_ModeSupportAndSystemConfigurationFull() function exercises
a few paths in the compiler that are otherwise rare. On thing it does is to
pass up to 60 arguments to other functions, and it heavily uses float and
double variables. Both of these make it rather fragile when it comes to
unusual compiler options, so the files keep coming up whenever a new
instrumentation feature gets added. There is probably some other flag
in allmodconfig that we can disable to improve this again, but I have not
checked this time.
Arnd
Re: [PATCH 2/2] drm/cmdline-parser: Use assert when needed
Hi "Michał,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next linus/master v5.19 next-20220803]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: hexagon-randconfig-r001-20220804
(https://download.01.org/0day-ci/archive/20220805/202208050217.vhlt1udz-...@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
26dd42705c2af0b8f6e5d6cdb32c9bd5ed9524eb)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
git checkout 8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/tests/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:72:13: warning: stack frame
>> size (1152) exceeds limit (1024) in 'drm_cmdline_test_force_D_only_dvi'
>> [-Wframe-larger-than]
static void drm_cmdline_test_force_D_only_dvi(struct kunit *test)
^
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:51:13: warning: stack frame
>> size (1152) exceeds limit (1024) in 'drm_cmdline_test_force_D_only_hdmi'
>> [-Wframe-larger-than]
static void drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
^
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:389:13: warning: stack frame
>> size (1152) exceeds limit (1024) in
>> 'drm_cmdline_test_res_bpp_refresh_force_on_digital' [-Wframe-larger-than]
static void drm_cmdline_test_res_bpp_refresh_force_on_digital(struct kunit
*test)
^
3 warnings generated.
vim +/drm_cmdline_test_force_D_only_dvi +72
drivers/gpu/drm/tests/drm_cmdline_parser_test.c
9f0527d22a52ff34 Maíra Canal 2022-07-08 49
9f0527d22a52ff34 Maíra Canal 2022-07-08 50
9f0527d22a52ff34 Maíra Canal 2022-07-08 @51 static void
drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
9f0527d22a52ff34 Maíra Canal 2022-07-08 52 {
9f0527d22a52ff34 Maíra Canal 2022-07-08 53struct drm_cmdline_mode
mode = { };
8a21a5872b4bbe7b Michał Winiarski 2022-08-04 54const struct
drm_connector connector_hdmi = {
8a21a5872b4bbe7b Michał Winiarski 2022-08-04 55.connector_type
= DRM_MODE_CONNECTOR_HDMIB,
8a21a5872b4bbe7b Michał Winiarski 2022-08-04 56};
9f0527d22a52ff34 Maíra Canal 2022-07-08 57const char *cmdline =
"D";
9f0527d22a52ff34 Maíra Canal 2022-07-08 58
8a21a5872b4bbe7b Michał Winiarski 2022-08-04 59KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
9f0527d22a52ff34 Maíra Canal 2022-07-08 60
&connector_hdmi, &mode));
9f0527d22a52ff34 Maíra Canal 2022-07-08 61
KUNIT_EXPECT_FALSE(test, mode.specified);
9f0527d22a52ff34 Maíra Canal 2022-07-08 62
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
9f0527d22a52ff34 Maíra Canal 2022-07-08 63
KUNIT_EXPECT_FALSE(test, mode.bpp_specified);
9f0527d22a52ff34 Maíra Canal 2022-07-08 64
9f0527d22a52ff34 Maíra Canal 2022-07-08 65
KUNIT_EXPECT_FALSE(test, mode.rb);
9f0527d22a52ff34 Maíra Canal 2022-07-08 66
KUNIT_EXPECT_FALSE(test, mode.cvt);
9f0527d22a52ff34 Maíra Canal 2022-07-08 67
KUNIT_EXPECT_FALSE(test, mode.interlace);
9f0527d22a52ff34 Maíra Canal 2022-07-08 68
KUNIT_EXPECT_FALSE(test, mode.margins);
9f0527d22a52ff34 Maíra Canal 2022-07-08 69KUNIT_EXPECT_EQ(test,
mode.force, DRM_FORCE_ON_DIGITAL);
9f0527d22a52ff34 Maíra Canal 2022-07-08 70 }
9f0527d22a52ff34 Maíra Canal 2022-07-08 71
9f0527d22a52ff34 Maíra Canal 2022-07-08 @72 static void
drm_cmdline_test
Re: [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
Hi Mauro,
On 8/4/22 00:37, Mauro Carvalho Chehab wrote:
> Add a description for the TLB cache invalidation algorithm and for
> the related kAPI functions.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v3 0/3] at:
> https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
>
> Documentation/gpu/i915.rst | 7 ++
> drivers/gpu/drm/i915/gt/intel_tlb.c | 25
> drivers/gpu/drm/i915/gt/intel_tlb.h | 99 +
> 3 files changed, 131 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
> b/drivers/gpu/drm/i915/gt/intel_tlb.c
> index af8cae979489..16b918ffe824 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.c
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
> @@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
> }
>
> +/**
> + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> + * @gt: GT structure
In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't find any comments about it.
Just saying that @gt is a GT structure isn't very helpful, other
than making kernel-doc shut up.
> + * @seqno: sequence number
> + *
> + * Do a full TLB cache invalidation if the @seqno is bigger than the last
> + * full TLB cache invalidation.
> + *
> + * Note:
> + * The TLB cache invalidation logic depends on GEN-specific registers.
> + * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
> + */
> void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> {
> intel_wakeref_t wakeref;
> @@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
> u32 seqno)
> }
> }
>
> +/**
> + * intel_gt_init_tlb - initialize TLB-specific vars
> + * @gt: GT structure
> + *
> + * TLB cache invalidation logic internally uses some resources that require
> + * initialization. Should be called before doing any TLB cache invalidation.
> + */
> void intel_gt_init_tlb(struct intel_gt *gt)
> {
> mutex_init(>->tlb.invalidate_lock);
> seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
> }
>
> +/**
> + * intel_gt_fini_tlb - free TLB-specific vars
> + * @gt: GT structure
> + *
> + * Frees any resources needed by TLB cache invalidation logic.
> + */
> void intel_gt_fini_tlb(struct intel_gt *gt)
> {
> mutex_destroy(>->tlb.invalidate_lock);
> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h
> b/drivers/gpu/drm/i915/gt/intel_tlb.h
> index 46ce25bf5afe..2838c051f872 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.h
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
> @@ -11,16 +11,115 @@
>
> #include "intel_gt_types.h"
>
> +/**
> + * DOC: TLB cache invalidation logic
> + *
...
> +
> void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno);
>
> void intel_gt_init_tlb(struct intel_gt *gt);
> void intel_gt_fini_tlb(struct intel_gt *gt);
>
> +/**
> + * intel_gt_tlb_seqno - Returns the current TLB invlidation sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is
> thread-safe
> + */
> static inline u32 intel_gt_tlb_seqno(const struct intel_gt *gt)
> {
> return seqprop_sequence(>->tlb.seqno);
> }
>
> +/**
> + * intel_gt_next_invalidate_tlb_full - Returns the next TLB full invalidation
> + * sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is
> thread-safe
> + */
> static inline u32 intel_gt_next_invalidate_tlb_full(const struct intel_gt
> *gt)
> {
> return intel_gt_tlb_seqno(gt) | 1;
thanks.
--
~Randy
Re: [Intel-gfx] [PATCH] drm: Fix typo 'the the' in comment
On Thu, 2022-07-21 at 14:23 +0800, Slark Xiao wrote:
> Replace 'the the' with 'the' in the comment.
>
> Signed-off-by: Slark Xiao
Reviewed-by: Stuart Summers
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5bab236b3ae..32b295003f49 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const
> struct drm_dp_aux_msg *msg)
>
> /*
> * Calculate the length of the i2c transfer in usec, assuming
> - * the i2c bus speed is as specified. Gives the the "worst"
> + * the i2c bus speed is as specified. Gives the "worst"
> * case estimate, ie. successful while as long as possible.
> * Doesn't account the "MOT" bit, and instead assumes each
> * message includes a START, ADDRESS and STOP. Neither does it
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 73cebc6aa650..783a6ca41a61 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -65,7 +65,7 @@
>
> /*
> * Interrupt statistic for PMU. Increments the counter only if the
> - * interrupt originated from the the GPU so interrupts from a device
> which
> + * interrupt originated from the GPU so interrupts from a device
> which
> * shares the interrupt line are not accounted.
> */
> static inline void pmu_irq_stats(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> index 40ea41b0a5dd..4085822f619a 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> @@ -231,7 +231,7 @@ struct nt35510_config {
>* bits 0..2 in the lower nibble controls HCK, the booster
> clock
>* frequency, the values are the same as for PCK in @bt1ctr.
>* bits 4..5 in the upper nibble controls BTH, the boosting
> - * amplification for the the step-up circuit.
> + * amplification for the step-up circuit.
>* 0 = AVDD + VDDB
>* 1 = AVDD - AVEE
>* 2 = AVDD - AVEE + VDDB
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
wrote:
>
> git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> display engine with KCOV enabled").
Ahh. So that was presumably why it was disabled before - because it
presumably does disgusting things that make KCOV generate even bigger
stack frames than it already has.
Those functions do seem to have fairly big stack footprints already (I
didn't try to look into why, I assume it's partly due to aggressive
inlining, and probably some automatic structures on stack). But gcc
doesn't seem to make it all that much worse with KCOV (and my clang
build doesn't enable KCOV).
So it's presumably some KCOV-vs-clang thing. Nathan?
Linus
mainline build failure for x86_64 allmodconfig with clang
Hi All,
The latest mainline kernel branch fails to build for x86_64 allmodconfig
with clang. The errors are:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6:
error: stack frame size (2184) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1726:6:
error: stack frame size (2176) exceeds limit (2048) in
'dml32_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
display engine with KCOV enabled").
My last good build for clang was with e2b542100719 ("Merge tag
'flexible-array-transformations-UAPI-6.0-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux").
I will be happy to test any patch or provide any extra log if needed.
--
Regards
Sudip
Re: mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")
On Thu, Aug 4, 2022 at 6:17 PM Linus Torvalds wrote: > > On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink) > wrote: > > > > I will be happy to test any patch or provide any extra log if needed. > > It sounds like that file just needs to get a > > #include > > there, and for some reason architectures other than alpha and mips end > up getting it accidentally through other headers. > > Mind testing just adding that header file, and perhaps even sending a > patch if (when) that works for you? Tested on alpha allmodconfig, that worked. And also sent the patch. -- Regards Sudip
[PATCH] drm/amd/amdgpu: fix build failure due to implicit declaration
The builds for alpha and mips allmodconfig fails with the error: drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:23: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:21: error: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:545:33: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration] Add the header file for vmalloc and vfree. Reported-by: Sudip Mukherjee Suggested-by: Linus Torvalds Signed-off-by: Sudip Mukherjee --- drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c index 63b2d32545cc..726a5bba40b2 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c @@ -22,6 +22,7 @@ */ #include #include +#include #include "amdgpu.h" #include "amdgpu_psp.h" #include "amdgpu_ucode.h" -- 2.30.2
Re: [PATCH v6 00/10] Add PSR support for eDP
Hi, On Thu, Aug 4, 2022 at 9:21 AM Robert Foss wrote: > > On Fri, 29 Jul 2022 at 02:22, Doug Anderson wrote: > > > > Hi, > > > > On Mon, Jul 11, 2022 at 5:57 AM Vinod Polimera > > wrote: > > > > > > Changes in v2: > > > - Use dp bridge to set psr entry/exit instead of dpu_enocder. > > > - Don't modify whitespaces. > > > - Set self refresh aware from atomic_check. > > > - Set self refresh aware only if psr is supported. > > > - Provide a stub for msm_dp_display_set_psr. > > > - Move dp functions to bridge code. > > > > > > Changes in v3: > > > - Change callback names to reflect atomic interfaces. > > > - Move bridge callback change to separate patch as suggested by Dmitry. > > > - Remove psr function declaration from msm_drv.h. > > > - Set self_refresh_aware flag only if psr is supported. > > > - Modify the variable names to simpler form. > > > - Define bit fields for PSR settings. > > > - Add comments explaining the steps to enter/exit psr. > > > - Change DRM_INFO to drm_dbg_db. > > > > > > Changes in v4: > > > - Move the get crtc functions to drm_atomic. > > > - Add atomic functions for DP bridge too. > > > - Add ternary operator to choose eDP or DP ops. > > > - Return true/false instead of 1/0. > > > - mode_valid missing in the eDP bridge ops. > > > - Move the functions to get crtc into drm_atomic.c. > > > - Fix compilation issues. > > > - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc. > > > - Check for crtc state enable while reserving resources. > > > > > > Changes in v5: > > > - Move the mode_valid changes into a different patch. > > > - Complete psr_op_comp only when isr is set. > > > - Move the DP atomic callback changes to a different patch. > > > - Get crtc from drm connector state crtc. > > > - Move to separate patch for check for crtc state enable while > > > reserving resources. > > > > > > Changes in v6: > > > - Remove crtc from dpu_encoder_virt struct. > > > - fix crtc check during vblank toggle crtc. > > > - Misc changes. > > > > > > Signed-off-by: Sankeerth Billakanti > > > Signed-off-by: Kalyan Thota > > > Signed-off-by: Vinod Polimera > > > > > > Vinod Polimera (10): > > > drm/msm/disp/dpu: clear dpu_assign_crtc and get crtc from connector > > > state instead of dpu_enc > > > drm: add helper functions to retrieve old and new crtc > > > drm/msm/dp: use atomic callbacks for DP bridge ops > > > drm/msm/dp: Add basic PSR support for eDP > > > drm/msm/dp: use the eDP bridge ops to validate eDP modes > > > drm/bridge: use atomic enable/disable callbacks for panel bridge > > > drm/bridge: add psr support for panel bridge callbacks > > > drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder > > > functions > > > drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver > > > drm/msm/disp/dpu: check for crtc enable rather than crtc active to > > > release shared resources > > > > > > drivers/gpu/drm/bridge/panel.c | 68 -- > > > drivers/gpu/drm/drm_atomic.c| 60 + > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 17 ++- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 56 + > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 -- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- > > > drivers/gpu/drm/msm/dp/dp_catalog.c | 81 > > > drivers/gpu/drm/msm/dp/dp_catalog.h | 4 + > > > drivers/gpu/drm/msm/dp/dp_ctrl.c| 73 +++ > > > drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 + > > > drivers/gpu/drm/msm/dp/dp_display.c | 31 +++-- > > > drivers/gpu/drm/msm/dp/dp_display.h | 2 + > > > drivers/gpu/drm/msm/dp/dp_drm.c | 184 > > > ++-- > > > drivers/gpu/drm/msm/dp/dp_drm.h | 9 +- > > > drivers/gpu/drm/msm/dp/dp_link.c| 36 ++ > > > drivers/gpu/drm/msm/dp/dp_panel.c | 22 > > > drivers/gpu/drm/msm/dp/dp_panel.h | 6 + > > > drivers/gpu/drm/msm/dp/dp_reg.h | 27 > > > include/drm/drm_atomic.h| 7 ++ > > > 19 files changed, 631 insertions(+), 65 deletions(-) > > > > Which tree does this series apply to? It ought to apply to msm-next, but as I mentioned in my reply to patch #1 it doesn't apply to the top of msm-next. I think I also had to manually apply a few of the later patches with "patch -p1". -Doug
Re: New subsystem for acceleration devices
On Thu, Aug 4, 2022 at 5:50 PM Jason Gunthorpe wrote: > > On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote: > > > After all, memory management services, or common device chars handling > > I can get from other subsystems (e.g. rdma) as well. I'm sure I could > > model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI > > there as well), but this doesn't mean I belong there, right ? > > You sure can, but there is still an expectation, eg in RDMA, that your > device has a similarity to the established standards (like roce in > habana's case) that RDMA is geared to support. > > I think the the most important thing to establish a new subsystem is > to actually identify what commonalities it is supposed to be > providing. Usually this is driven by some standards body, but the > AI/ML space hasn't gone in that direction at all yet. I agree. In the AI-world the standard doesn't exist and I don't see anything on the horizon. There are the AI frameworks/compilers which are 30,000 feet above us, and there is CUDA which is closed-source and I have no idea what it does inside. > > We don't need a "subsystem" to have a bunch of drivers expose chardevs > with completely unique ioctls. I totally agree with this sentence and this is *exactly* why personally I don't want to use DRM because when I look at the long list of common IOCTLs in drm.h, I don't find anything that I can use. It's simply either not relevant at all to my h/w or it is something that our h/w implemented differently. This is in contrast to the rdma, where as you said, we have ibverbs API. So, when you asked that we write an IBverbs driver I understood the reasoning. There is a common user-space library which talks to the rdma drivers and all the rdma applications use that library and once I will write a (somewhat) standard driver, then hopefully I can enjoy all that. > > The flip is true of DRM - DRM is pretty general. I bet I could > implement an RDMA device under DRM - but that doesn't mean it should > be done. > > My biggest concern is that this subsystem not turn into a back door > for a bunch of abuse of kernel APIs going forward. Though things are How do you suggest to make sure it won't happen ? > better now, we still see this in DRM where expediency or performance > justifies hacky shortcuts instead of good in-kernel architecture. At > least DRM has reliable and experienced review these days. Definitely. DRM has some parts that are really well written. For example, the whole char device handling with sysfs/debugfs and managed resources code. This is something I would gladly either use or copy-paste into the hw accel subsystem. And of course more pairs of eyes looking at the code will usually produce better code. I think that it is clear from my previous email what I intended to provide. A clean, simple framework for devices to register with, get services for the most basic stuff such as device char handling, sysfs/debugfs. Later on, add more simple stuff such as memory manager and uapi for memory handling. I guess someone can say all that exists in drm, but like I said it exists in other subsystems as well. I want to be perfectly honest and say there is nothing special here for AI. It's actually the opposite, it is a generic framework for compute only. Think of it as an easier path to upstream if you just want to do compute acceleration. Maybe in the future it will be more, but I can't predict the future. If that's not enough for a new subsystem, fair enough, I'll withdraw my offer. Thanks, Oded > > Jason
[PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2022-08-04: - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) Thanks, Rodrigo. The following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410: Merge tag 'topic/nouveau-misc-2022-07-27' of git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-08-04 for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) Chris Wilson (4): drm/i915/gt: Ignore TLB invalidations on idle engines drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations drm/i915/gt: Skip TLB invalidations once wedged drm/i915/gt: Batch TLB invalidations Matthew Auld (1): drm/i915/ttm: don't leak the ccs state Nirmoy Das (1): drm/i915: disable pci resize on 32-bit machine drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c| 25 +--- drivers/gpu/drm/i915/gt/intel_gt.c | 77 ++-- drivers/gpu/drm/i915/gt/intel_gt.h | 12 +++- drivers/gpu/drm/i915/gt/intel_gt_pm.h| 3 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 18 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++- drivers/gpu/drm/i915/gt/intel_ppgtt.c| 8 ++- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++ drivers/gpu/drm/i915/i915_vma.c | 33 +++--- drivers/gpu/drm/i915/i915_vma.h | 1 + drivers/gpu/drm/i915/i915_vma_resource.c | 5 +- drivers/gpu/drm/i915/i915_vma_resource.h | 6 +- 13 files changed, 177 insertions(+), 41 deletions(-)
Re: [PATCH 1/2] drm/msm: Move hangcheck timer restart
On Thu, Aug 4, 2022 at 12:53 AM Akhil P Oommen wrote:
>
> On 8/4/2022 1:59 AM, Rob Clark wrote:
> > On Wed, Aug 3, 2022 at 12:52 PM Akhil P Oommen
> > wrote:
> >> On 8/3/2022 10:53 PM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Don't directly restart the hangcheck timer from the timer handler, but
> >>> instead start it after the recover_worker replays remaining jobs.
> >>>
> >>> If the kthread is blocked for other reasons, there is no point to
> >>> immediately restart the timer. Fixes a random symptom of the problem
> >>> fixed in the next patch.
> >>>
> >>> Signed-off-by: Rob Clark
> >>> ---
> >>>drivers/gpu/drm/msm/msm_gpu.c | 14 +-
> >>>1 file changed, 9 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> >>> index fba85f894314..8f9c48eabf7d 100644
> >>> --- a/drivers/gpu/drm/msm/msm_gpu.c
> >>> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> >>> @@ -328,6 +328,7 @@ find_submit(struct msm_ringbuffer *ring, uint32_t
> >>> fence)
> >>>}
> >>>
> >>>static void retire_submits(struct msm_gpu *gpu);
> >>> +static void hangcheck_timer_reset(struct msm_gpu *gpu);
> >>>
> >>>static void get_comm_cmdline(struct msm_gem_submit *submit, char
> >>> **comm, char **cmd)
> >>>{
> >>> @@ -420,6 +421,8 @@ static void recover_worker(struct kthread_work *work)
> >>>}
> >>>
> >>>if (msm_gpu_active(gpu)) {
> >>> + bool restart_hangcheck = false;
> >>> +
> >>>/* retire completed submits, plus the one that hung: */
> >>>retire_submits(gpu);
> >>>
> >>> @@ -436,10 +439,15 @@ static void recover_worker(struct kthread_work
> >>> *work)
> >>>unsigned long flags;
> >>>
> >>>spin_lock_irqsave(&ring->submit_lock, flags);
> >>> - list_for_each_entry(submit, &ring->submits, node)
> >>> + list_for_each_entry(submit, &ring->submits, node) {
> >>>gpu->funcs->submit(gpu, submit);
> >>> + restart_hangcheck = true;
> >>> + }
> >>>spin_unlock_irqrestore(&ring->submit_lock, flags);
> >>>}
> >>> +
> >>> + if (restart_hangcheck)
> >>> + hangcheck_timer_reset(gpu);
> >>>}
> >>>
> >>>mutex_unlock(&gpu->lock);
> >>> @@ -515,10 +523,6 @@ static void hangcheck_handler(struct timer_list *t)
> >>>kthread_queue_work(gpu->worker, &gpu->recover_work);
> >>>}
> >>>
> >>> - /* if still more pending work, reset the hangcheck timer: */
> >> In the scenario mentioned here, shouldn't we restart the timer?
> > yeah, actually the case where we don't want to restart the timer is
> > *only* when we schedule recover_work..
> >
> > BR,
> > -R
> Not sure if your codebase is different but based on msm-next branch,
> when "if (fence != ring->hangcheck_fence)" is true, we now skip
> rescheduling the timer. I don't think that is what we want. There should
> be a hangcheck timer running as long as there is an active submit,
> unless we have scheduled a recover_work here.
>
right, v2 will change that to only skip rescheduling the timer in the
recover path
BR,
-R
> -Akhil.
> >
> >> -Akhil.
> >>> - if (fence_after(ring->fctx->last_fence, ring->hangcheck_fence))
> >>> - hangcheck_timer_reset(gpu);
> >>> -
> >>>/* workaround for missing irq: */
> >>>msm_gpu_retire(gpu);
> >>>}
> >>>
>
Re: [PATCH] drm/amd/display: restore plane with no modifiers code.
On Wed, Aug 3, 2022 at 10:50 PM Dave Airlie wrote: > > With this applied, I get gdm back. I can confirm that it makes thing work again for me too. Applied. Linus
Re: mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")
On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink) wrote: > > I will be happy to test any patch or provide any extra log if needed. It sounds like that file just needs to get a #include there, and for some reason architectures other than alpha and mips end up getting it accidentally through other headers. Mind testing just adding that header file, and perhaps even sending a patch if (when) that works for you? Linus
Re: [PATCH 01/12] drm/format-helper: Provide drm_fb_blit()
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:01PM +0200, Thomas Zimmermann wrote:
> Provide drm_fb_blit() that works with struct iosys_map. Update all
> users of drm_fb_blit_toio(), which required a destination buffer in
> I/O memory. The new function's interface works with multi-plane
> color formats, although the implementation only supports a single
> plane for now.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 39 ++---
> drivers/gpu/drm/tiny/simpledrm.c| 18 +++--
> include/drm/drm_format_helper.h | 7 +++---
> 3 files changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index c6182b5de78b..4d74d46ab155 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -8,9 +8,10 @@
> * (at your option) any later version.
> */
>
> +#include
> +#include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -545,9 +546,9 @@ void drm_fb_xrgb_to_gray8(void *dst, unsigned int
> dst_pitch, const void *vad
> EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>
> /**
> - * drm_fb_blit_toio - Copy parts of a framebuffer to display memory
> - * @dst: The display memory to copy to
> - * @dst_pitch: Number of bytes between two consecutive scanlines
> within dst
> + * drm_fb_blit - Copy parts of a framebuffer to display memory
> + * @dst: Array of display-memory addresses to copy to
> + * @dst_pitch: Array of numbers of bytes between two consecutive
> scanlines within dst
The rename confused me since this function continue to operate only on
io memory, but I see that this is all fixed up in later patches.
It would be nice to have this mentioned in the changelog, just in case
someone else takes a deeper look at it.
With the changelog updated:
Reviewed-by: Sam Ravnborg
See also comments below.
> * @dst_format: FOURCC code of the display's color format
> * @vmap:The framebuffer memory to copy from
> * @fb: The framebuffer to copy from
> @@ -557,14 +558,18 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
> * formats of the display and the framebuffer mismatch, the blit function
> * will attempt to convert between them.
> *
> + * The parameters @dst, @dst_pitch and @vmap refer to arrays. Each array must
> + * have at least as many entries as there are planes in @dst_format's
> format. Each
> + * entry stores the value for the format's respective color plane at the
> same index.
> + *
> * Returns:
> * 0 on success, or
> * -EINVAL if the color-format conversion failed, or
> * a negative error code otherwise.
> */
> -int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t
> dst_format,
> - const void *vmap, const struct drm_framebuffer *fb,
> - const struct drm_rect *clip)
> +int drm_fb_blit(struct iosys_map *dst, const unsigned int *dst_pitch,
> uint32_t dst_format,
> + const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
> {
> uint32_t fb_format = fb->format->format;
>
> @@ -579,30 +584,35 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> dst_format = DRM_FORMAT_XRGB2101010;
>
> if (dst_format == fb_format) {
> - drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
> + drm_fb_memcpy_toio(dst[0].vaddr_iomem, dst_pitch[0],
> vmap[0].vaddr, fb, clip);
> return 0;
>
> } else if (dst_format == DRM_FORMAT_RGB565) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb565_toio(dst, dst_pitch, vmap,
> fb, clip, false);
> + drm_fb_xrgb_to_rgb565_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip,
> false);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_RGB888) {
> if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap,
> fb, clip);
> + drm_fb_xrgb_to_rgb888_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip);
> return 0;
> }
> } else if (dst_format == DRM_FORMAT_XRGB) {
> if (fb_format == DRM_FORMAT_RGB888) {
> - drm_fb_rgb888_to_xrgb_toio(dst, dst_pitch, vmap,
> fb, clip);
> + drm_fb_rgb888_to_xrgb_toio(dst[0].vaddr_iomem,
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip);
> return 0;
> } else if (fb_format == DRM_FORMAT_RGB565) {
> - drm_fb_r
Re: [PATCH v6 00/10] Add PSR support for eDP
On Fri, 29 Jul 2022 at 02:22, Doug Anderson wrote: > > Hi, > > On Mon, Jul 11, 2022 at 5:57 AM Vinod Polimera > wrote: > > > > Changes in v2: > > - Use dp bridge to set psr entry/exit instead of dpu_enocder. > > - Don't modify whitespaces. > > - Set self refresh aware from atomic_check. > > - Set self refresh aware only if psr is supported. > > - Provide a stub for msm_dp_display_set_psr. > > - Move dp functions to bridge code. > > > > Changes in v3: > > - Change callback names to reflect atomic interfaces. > > - Move bridge callback change to separate patch as suggested by Dmitry. > > - Remove psr function declaration from msm_drv.h. > > - Set self_refresh_aware flag only if psr is supported. > > - Modify the variable names to simpler form. > > - Define bit fields for PSR settings. > > - Add comments explaining the steps to enter/exit psr. > > - Change DRM_INFO to drm_dbg_db. > > > > Changes in v4: > > - Move the get crtc functions to drm_atomic. > > - Add atomic functions for DP bridge too. > > - Add ternary operator to choose eDP or DP ops. > > - Return true/false instead of 1/0. > > - mode_valid missing in the eDP bridge ops. > > - Move the functions to get crtc into drm_atomic.c. > > - Fix compilation issues. > > - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc. > > - Check for crtc state enable while reserving resources. > > > > Changes in v5: > > - Move the mode_valid changes into a different patch. > > - Complete psr_op_comp only when isr is set. > > - Move the DP atomic callback changes to a different patch. > > - Get crtc from drm connector state crtc. > > - Move to separate patch for check for crtc state enable while > > reserving resources. > > > > Changes in v6: > > - Remove crtc from dpu_encoder_virt struct. > > - fix crtc check during vblank toggle crtc. > > - Misc changes. > > > > Signed-off-by: Sankeerth Billakanti > > Signed-off-by: Kalyan Thota > > Signed-off-by: Vinod Polimera > > > > Vinod Polimera (10): > > drm/msm/disp/dpu: clear dpu_assign_crtc and get crtc from connector > > state instead of dpu_enc > > drm: add helper functions to retrieve old and new crtc > > drm/msm/dp: use atomic callbacks for DP bridge ops > > drm/msm/dp: Add basic PSR support for eDP > > drm/msm/dp: use the eDP bridge ops to validate eDP modes > > drm/bridge: use atomic enable/disable callbacks for panel bridge > > drm/bridge: add psr support for panel bridge callbacks > > drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder > > functions > > drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver > > drm/msm/disp/dpu: check for crtc enable rather than crtc active to > > release shared resources > > > > drivers/gpu/drm/bridge/panel.c | 68 -- > > drivers/gpu/drm/drm_atomic.c| 60 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 17 ++- > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 56 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 -- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- > > drivers/gpu/drm/msm/dp/dp_catalog.c | 81 > > drivers/gpu/drm/msm/dp/dp_catalog.h | 4 + > > drivers/gpu/drm/msm/dp/dp_ctrl.c| 73 +++ > > drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 + > > drivers/gpu/drm/msm/dp/dp_display.c | 31 +++-- > > drivers/gpu/drm/msm/dp/dp_display.h | 2 + > > drivers/gpu/drm/msm/dp/dp_drm.c | 184 > > ++-- > > drivers/gpu/drm/msm/dp/dp_drm.h | 9 +- > > drivers/gpu/drm/msm/dp/dp_link.c| 36 ++ > > drivers/gpu/drm/msm/dp/dp_panel.c | 22 > > drivers/gpu/drm/msm/dp/dp_panel.h | 6 + > > drivers/gpu/drm/msm/dp/dp_reg.h | 27 > > include/drm/drm_atomic.h| 7 ++ > > 19 files changed, 631 insertions(+), 65 deletions(-) > Which tree does this series apply to?
Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280
On Thu, 4 Aug 2022 at 13:29, Kalyan Thota wrote:
>
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This change adds necessary support for the above design.
>
> Signed-off-by: Kalyan Thota
I'd like to land at least patches 6-8 from [1] next cycle. They clean
up the CTL interface. Could you please rebase your patch on top of
them?
[1] https://patchwork.freedesktop.org/series/99909/
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 40
> +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 3 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 7 +
> 6 files changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 7763558..4eca317 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -703,6 +703,10 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc
> *crtc)
> mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
> mixer[i].hw_dspp->idx);
>
> + if(ctl->ops.set_dspp_hierarchical_flush)
> + ctl->ops.set_dspp_hierarchical_flush(ctl,
> + mixer[i].hw_dspp->idx,
> DSPP_SUB_PCC);
> +
> /* stage config flush mask */
> ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 021eb2f..3b27a87 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -58,7 +58,10 @@
> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>
> #define CTL_SC7280_MASK \
> - (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
> BIT(DPU_CTL_VM_CFG))
> + (BIT(DPU_CTL_ACTIVE_CFG) | \
> +BIT(DPU_CTL_FETCH_ACTIVE) | \
> +BIT(DPU_CTL_VM_CFG) | \
> +BIT(DPU_CTL_HIERARCHICAL_FLUSH))
>
> #define MERGE_3D_SM8150_MASK (0)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index b85b24b..7922f6c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -185,6 +185,7 @@ enum {
> * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
> * @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
> * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
> + * @DPU_CTL_HIERARCHICAL_FLUSH: CTL config to support hierarchical flush
> * @DPU_CTL_MAX
> */
> enum {
> @@ -192,6 +193,7 @@ enum {
> DPU_CTL_ACTIVE_CFG,
> DPU_CTL_FETCH_ACTIVE,
> DPU_CTL_VM_CFG,
> + DPU_CTL_HIERARCHICAL_FLUSH,
> DPU_CTL_MAX
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 3584f5e..b34fc30 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -28,6 +28,8 @@
> #define CTL_INTF_FLUSH0x110
> #define CTL_INTF_MASTER 0x134
> #define CTL_FETCH_PIPE_ACTIVE 0x0FC
> +#define CTL_DSPP_0_FLUSH 0x13C
Please change to CTL_DSPP_n_FLUSH(n).
> +
>
> #define CTL_MIXER_BORDER_OUTBIT(24)
> #define CTL_FLUSH_MASK_CTL BIT(17)
> @@ -292,6 +294,36 @@ static uint32_t dpu_hw_ctl_get_bitmask_dspp(struct
> dpu_hw_ctl *ctx,
> return flushbits;
> }
>
> +static uint32_t dpu_hw_ctl_get_bitmask_dspp_v1(struct dpu_hw_ctl *ctx,
> + enum dpu_dspp dspp)
> +{
> + return BIT(29);
> +}
> +
> +static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
> + enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> +{
> + uint32_t flushbits = 0, active = 0;
> +
> + switch (dspp_sub_blk) {
> + case DSPP_SUB_IGC:
> + flushbits = BIT(2);
> + break;
> + case DSPP_SUB_PCC:
> + flushbits = BIT(4);
> + break;
> + case DSPP_SUB_GC:
> + flushbits = BIT(5);
> + break;
> + default:
> + return;
> + }
> +
> + active = DPU_REG_READ(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4));
So that this line will be simpler to read.
> +
> + DPU_REG_WRITE(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4), active |
> flushbits);
> +}
> +
> static u32 dpu_hw_ctl_poll_reset_status(struct dpu_hw_ctl *ctx, u32
> time
Re: [PATCH] drm/vmwgfx: cleanup comments
On Sat, 2022-07-30 at 09:57 -0400, Tom Rix wrote: > Remove second 'should' > > Spelling replacements > aqcuire -> acquire > applcations -> applications > assumings -> assumes > begining-> beginning > commited-> committed > contol -> control > inbetween -> in between > resorces-> resources > succesful -> successful > successfule -> successful > > Signed-off-by: Tom Rix Thanks, looks good. I pushed it through drm-misc-next. z
Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"
Hi
When is this relanding?
Cheers
Mike
On Mon, 18 Jul 2022 at 21:40, Dixit, Ashutosh wrote:
>
> On Thu, 14 Jul 2022 08:00:32 -0700, Christian König wrote:
> >
> > Am 14.07.22 um 15:33 schrieb Alex Deucher:
> > > On Thu, Jul 14, 2022 at 9:09 AM Christian König
> > > wrote:
> > >> Hi Mauro,
> > >>
> > >> well the last time I checked drm-tip was clean.
> > >>
> > >> The revert is necessary because we had some problems with the commit
> > >> which we couldn't fix in the 5.19 cycle.
> > > Would it be worth reverting the revert and applying the actual fix[1]?
> > > It's a huge revert unfortunately while the actual fix is like 10
> > > lines of code. I'm concerned there will be subtle fallout from the
> > > revert due to how extensive it is.
> >
> > We have other bug fixes and cleanups around that patch which didn't made it
> > into 5.19 either. I don't want to create an ever greater mess.
> >
> > Real question is why building drm-tip work for me but not for others?
>
> Seeing this on latest drm-tip:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:54:1: error: redefinition of
> ‘amdgpu_vram_mgr_first_block’
>54 | amdgpu_vram_mgr_first_block(struct list_head *list)
> | ^~~
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h:29,
> from drivers/gpu/drm/amd/amdgpu/amdgpu.h:73,
> from drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:28:
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:57:1: note: previous definition
> of ‘amdgpu_vram_mgr_first_block’ with type ‘struct drm_buddy_block *(struct
> list_head *)’
>57 | amdgpu_vram_mgr_first_block(struct list_head *list)
> | ^~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:59:20: error: redefinition of
> ‘amdgpu_is_vram_mgr_blocks_contiguous’
>59 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct
> list_head *head)
> |^~~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:62:20: note: previous definition
> of ‘amdgpu_is_vram_mgr_blocks_contiguous’ with type ‘bool(struct list_head
> *)’ {aka ‘_Bool(struct list_head *)’}
>62 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct
> list_head *head)
> |^~~~
> make[4]: *** [scripts/Makefile.build:249:
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [scripts/Makefile.build:466: drivers/gpu/drm/amd/amdgpu] Error 2
> make[2]: *** [scripts/Makefile.build:466: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:466: drivers/gpu] Error 2
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Kevin, > 1) Get an un-accelerated driver merged without new uapi, ioctls, etc. All > you need is there already. We already agreed to take the code mostly as-is > and do the cleanups later on. > > 2a) Stay around on dri-devel, send improvements and fixes for the merged > code. > > 2b) In parallel, you can work on video, 3d, etc in both kernel and > userspace. And on top of this the driver will see all the refactoring going on in drm drivers all the time, and we may find cases where the driver can use more of the drm helpers. I really hope to see next revision where there is focus on the general un-accelerated case and without the extras as Thomas mentions. Sam
Re: New subsystem for acceleration devices
On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote: On 04/08/2022 00:54, Dave Airlie wrote: On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: On Sun, 31 Jul 2022 at 22:04, Oded Gabbay wrote: Hi, Greg and I talked a couple of months ago about preparing a new accel subsystem for compute/acceleration devices that are not GPUs and I think your drivers that you are now trying to upstream fit it as well. We've had some submissions for not-GPUs to the drm subsystem recently. Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. why is creating a new subsystem at this time necessary? Are we just creating a subsystem to avoid the open source userspace consumer rules? Or do we have some concrete reasoning behind it? Dave. Hi Dave. The reason it happened now is because I saw two drivers, which are doing h/w acceleration for AI, trying to be accepted to the misc subsystem. Add to that the fact I talked with Greg a couple of months ago about doing a subsystem for any compute accelerators, which he was positive about, I thought it is a good opportunity to finally do it. I also honestly think that I can contribute much to these drivers from my experience with the habana driver (which is now deployed in mass at AWS) and contribute code from the habana driver to a common framework for AI drivers. Why not port the habana driver to drm now instead? I don't get why it wouldn't make sense? Stepping up to create a new subsystem is great, but we need rules around what belongs where, we can't just spawn new subsystems when we have no clear guidelines on where drivers should land. What are the rules for a new accel subsystem? Do we have to now retarget the 3 drivers that are queued up to use drm for accelerators, because 2 drivers don't? Isn't there three on the "don't prefer drm" side as well? Habana, Toshiba and Samsung? Just so the numbers argument is not misrepresented. Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't care in principle; is in order? I'll chime in with my opinions. Take them for what you will. I would say I fall into the C category, but I'm targeting DRM and will be the 5th(?) accel device to do so. I'll say that the ksummit (from what I see in the LWN article) made me very happy. Finally, the community had clear rules for accel drivers. When I targeted misc in the past, it seemed like Greg moved the goal post just for me, which stalled our attempt. It was even more frustrating to see that the high bar Greg set for us was not applied to other devices of the same "class" in following submissions. However, the past is the past, and based on ksummit, we've spent a number of months retargeting DRM. In a week (or two), I plan to post something to start up the discussions again. As far as the DRM userspace requirements, unless we've misunderstood something, they've been easier to satisfy (pending review I suppose) than what misc has set. I would say that Dave Airlie's feedback on this discussion resonates with me. From the perspective of a vendor wanting to be a part of the community, clear rules are important and ksummit seemed to set that. Oded's announcement has thrown all of that into the wind. Without a proposal to evaluate (eg show me the code with clear guidelines), I cannot seriously consider Oded's idea, and I'm not sure I want to sit by another few years to see it settle out. I expect to move forward with what we were planning prior to seeing this thread which is targeting DRM. We'll see what the DRM folks say when they have something to look at. If our device doesn't fit in DRM per an assessment of the DRM folks, then I sure hope they can suggest where we do fit because then we'll have tried misc and DRM, and not found a home. Since "drivers/accel" doesn't exist, and realistically won't for a long time if ever, I don't see why we should consider it. Why DRM? We consume dma_buf and might look to p2pdma in the future. ksummit appears clear - we are a DRM device. Also, someone could probably run openCL on our device if they were so inclined to wire it up. Over time, I've come to the thinking that we are a GPU, just without display. Yes, it would have helped if DRM and/or drivers/gpu were renamed, but I think I'm past that point. Once you have everything written, it doesn't seem like it matters if the uAPI device is called /dev/drmX, /dev/miscX, or /dev/magic. I will not opine on other devices as I am no expert on them. Today, my opinion is that DRM is the best place for me. We'll see where that goes. More to the point, code sharing is a very compelling argument if it can be demonstrated to be significant, aka not needing to reinvent the same wheel. Perhaps one route forward could be a) to consider is to rename DRM to something more appropriate, removing rendering from the name and replacing with accelerators, co-processors, I don't know... Althoug
[PATCH v2 4/4] Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode
AMD GPU display manager (DM) maps DRM pixel blend modes (None, Pre-multiplied, Coverage) to MPC hw blocks through blend configuration options. Describe relevant elements and how to set and test them to get the expected DRM blend mode on DCN hw. v2: - add ref tag (Tales) Signed-off-by: Melissa Wen Reviewed-by: Tales Aparecida --- .../gpu/amdgpu/display/display-manager.rst| 98 +++ Documentation/gpu/drm-kms.rst | 2 + 2 files changed, 100 insertions(+) diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index 88e2c08c7014..b7abb18cfc82 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -83,3 +83,101 @@ schemas. **DCN 3.0 family color caps and mapping** .. kernel-figure:: dcn3_cm_drm_current.svg + +Blend Mode Properties += + +Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` used to +describes how pixels from a foreground plane (fg) are composited with the +background plane (bg). Here, we present main concepts of DRM blend mode to help +to understand how this property is mapped to AMD DC interface. See more about +this DRM property and the alpha blending equations in :ref:`DRM Plane +Composition Properties `. + +Basically, a blend mode sets the alpha blending equation for plane +composition that fits the mode in which the alpha channel affects the state of +pixel color values and, therefore, the resulted pixel color. For +example, consider the following elements of the alpha blending equation: + +- *fg.rgb*: Each of the RGB component values from the foreground's pixel. +- *fg.alpha*: Alpha component value from the foreground's pixel. +- *bg.rgb*: Each of the RGB component values from the background. +- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see + more in :ref:`DRM Plane Composition Properties `. + +in the basic alpha blending equation:: + + out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb + +the alpha channel value of each pixel in a plane is ignored and only the plane +alpha affects the resulted pixel color values. + +DRM has three blend mode to define the blend formula in the plane composition: + +* **None**: Blend formula that ignores the pixel alpha. + +* **Pre-multiplied**: Blend formula that assumes the pixel color values in a + plane was already pre-multiplied by its own alpha channel before storage. + +* **Coverage**: Blend formula that assumes the pixel color values were not + pre-multiplied with the alpha channel values. + +and pre-multiplied is the default pixel blend mode, that means, when no blend +mode property is created or defined, DRM considers the plane's pixels has +pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test +provides a set of subtests to verify plane alpha and blend mode properties. + +The DRM blend mode and its elements are then mapped by AMDGPU display manager +(DM) to program the blending configuration of the Multiple Pipe/Plane Combined +(MPC), as follows: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :doc: mpc-overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_blnd_cfg + +Therefore, the blending configuration for a single MPCC instance on the MPC +tree is defined by :c:type:`mpcc_blnd_cfg`, where +:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to +set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is +multiplied (true/false), being only true for DRM pre-multiplied blend mode. +:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel +alpha and plane alpha values. It sets one of the three modes for +:c:type:`MPCC_ALPHA_BLND_MODE`, as described below. + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_alpha_blend_mode + +DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM +blend formula, as follows: + +* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value + from the plane's pixel +* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should + be ignored and, therefore, pixel values are not pre-multiplied +* *MPC global gain* assumes *MPC global alpha* value when both *DRM + fg.alpha* and *DRM plane_alpha* participate in the blend equation + +In short, *fg.alpha* is ignored by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha * +fg.alpha) component becomes available by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the +:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are +pre-multiplied by alpha or not. + +Blend configuration flow + + +The alpha blending equation is configured from DRM to DC interface by the +following path: + +1. When updat
[PATCH v2 3/4] drm/amd/display: add doc entries for MPC blending configuration
Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discussions on AMD issue tracker[1][2].
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1734
[2] https://gitlab.freedesktop.org/drm/amd/-/issues/1769
v2:
- fix typos (Tales)
- add MPCC to MPC entry in the glossary
Signed-off-by: Melissa Wen
Reviewed-by: Tales Aparecida
---
.../gpu/amdgpu/display/dc-glossary.rst| 2 +-
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 91 ---
2 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst
b/Documentation/gpu/amdgpu/display/dc-glossary.rst
index 116f5f0942fd..0b0ffd428dd2 100644
--- a/Documentation/gpu/amdgpu/display/dc-glossary.rst
+++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst
@@ -170,7 +170,7 @@ consider asking in the amdgfx and update this page.
MC
Memory Controller
-MPC
+MPC/MPCC
Multiple pipes and plane combine
MPO
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 5097037e3962..8d86159d9de0 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -22,6 +22,16 @@
*
*/
+/**
+ * DOC: mpc-overview
+ *
+ * Multiple Pipe/Plane Combined (MPC) is a component in the hardware pipeline
+ * that performs blending of multiple planes, using global and per-pixel alpha.
+ * It also performs post-blending color correction operations according to the
+ * hardware capabilities, such as color transformation matrix and gamma 1D and
+ * 3D LUT.
+ */
+
#ifndef __DC_MPCC_H__
#define __DC_MPCC_H__
@@ -48,14 +58,39 @@ enum mpcc_blend_mode {
MPCC_BLEND_MODE_TOP_BOT_BLENDING
};
+/**
+ * enum mpcc_alpha_blend_mode - define the alpha blend mode regarding pixel
+ * alpha and plane alpha values
+ */
enum mpcc_alpha_blend_mode {
+ /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA: per pixel alpha using DPP
+* alpha value
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA,
+ /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN: per
+* pixel alpha using DPP alpha value multiplied by a global gain (plane
+* alpha)
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN,
+ /**
+* @MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA: global alpha value, ignores
+* pixel alpha and consider only plane alpha
+*/
MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA
};
-/*
- * MPCC blending configuration
+/**
+ * struct mpcc_blnd_cfg - MPCC blending configuration
+ *
+ * @black_color: background color
+ * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE)
+ * @pre_multiplied_alpha: whether pixel color values were pre-multiplied by the
+ * alpha channel (MPCC_ALPHA_MULTIPLIED_MODE)
+ * @global_gain: used when blend mode considers both pixel alpha and plane
+ * alpha value and assumes the global alpha value.
+ * @global_alpha: plane alpha value
*/
struct mpcc_blnd_cfg {
struct tg_color black_color;/* background color */
@@ -107,8 +142,15 @@ struct mpc_dwb_flow_control {
int flow_ctrl_cnt1;
};
-/*
- * MPCC connection and blending configuration for a single MPCC instance.
+/**
+ * struct mpcc - MPCC connection and blending configuration for a single MPCC
instance.
+ * @mpcc_id: MPCC physical instance
+ * @dpp_id: DPP input to this MPCC
+ * @mpcc_bot: pointer to bottom layer MPCC. NULL when not connected.
+ * @blnd_cfg: the blending configuration for this MPCC
+ * @sm_cfg: stereo mix setting for this MPCC
+ * @shared_bottom: if MPCC output to both OPP and DWB endpoints, true.
Otherwise, false.
+ *
* This struct is used as a node in an MPC tree.
*/
struct mpcc {
@@ -120,8 +162,12 @@ struct mpcc {
bool shared_bottom; /* TRUE if MPCC output to both OPP and
DWB endpoints, else FALSE */
};
-/*
- * MPC tree represents all MPCC connections for a pipe.
+/**
+ * struct mpc_tree - MPC tree represents all MPCC connections for a pipe.
+ *
+ * @opp_id: the OPP instance that owns this MPC tree
+ * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint
+ *
*/
struct mpc_tree {
int opp_id; /* The OPP instance that owns this MPC
tree */
@@ -149,13 +195,18 @@ struct mpcc_state {
uint32_t busy;
};
+/**
+ * struct mpc_funcs - funcs
+ */
struct mpc_funcs {
void (*read_mpcc_state)(
struct mpc *mpc,
int mpcc_inst,
struct mpcc_state *s);
- /*
+ /**
+* @insert_plane:
+*
* Insert DPP into MPC tree based on specified blending position.
* Only used for planes that are part of blending chain for OPP output
*
@@ -
[PATCH v2 2/4] Documentation/amdgpu/display: add DC color caps info
Add details about color correction capabilities and explain a bit about differences between DC hw generations and also how they are mapped between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted to svg from the original png) is included to illustrate it. They were obtained from a discussion[1] in the amd-gfx mailing list. [1] https://lore.kernel.org/amd-gfx/20220422142811.dm6vtk6v64jcw...@mail.igalia.com/ v1: - remove redundant comments (Harry) - fix typos (Harry) v2: - reword introduction of color section - add co-dev tag for Harry - who provided most of the info - fix typos (Tales) - describe missing struct parameters (Tales and Siqueira) Co-developed-by: Harry Wentland Signed-off-by: Harry Wentland Signed-off-by: Melissa Wen Reviewed-by: Tales Aparecida --- .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++ .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 + .../gpu/amdgpu/display/display-manager.rst| 34 + drivers/gpu/drm/amd/display/dc/dc.h | 77 +- 4 files changed, 2997 insertions(+), 13 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg diff --git a/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg new file mode 100644 index ..315ffc5a1a4b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg @@ -0,0 +1,1370 @@ + + + +http://www.inkscape.org/namespaces/inkscape"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:svg="http://www.w3.org/2000/svg";> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Matrix +1D LUT +3D LUT +Unpacking +Other +drm_framebuffer +format +drm_plane +drm_crtc +Stream +MPC +DPP + +Blender +Degamma +CTM +Gamma +format +bias_and_scale +color space matrix +input_csc_color_matrix +in_transfer_func +hdr_mult +gamut_remap_matrix +in_shaper_func +lut3d_func +blend_tf +Blender +gamut_remap_matrix +func_shaper +lut3d_func +out_transfer_func +csc_color_matrix +bit_depth_param +clamping +output_color_space +Plane +Legend +DCN 2.0 +DC Interface +DRM Interface + +CNVC +Input CSC +DeGammaRAM and ROM(sRGB, BT2020 +HDR Multiply +Gamut Remap +Shaper LUTRAM +3D LUTRAM +Blend Gamma +Blender +GammaRAM +OCSC + + +color_encoding + +pixel_blend_mode + +color_range + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg new file mode 100644 index ..7299ee9b6d64 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg @@ -0,0 +1,1529 @@ + + + +http://www.inkscape.org/namespaces/inkscape"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:svg="http://www.w3.org/2000/svg";> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Matrix +1D LUT +3D LUT +Unpacking +Other +drm_framebuffer +format +drm_plane +drm_crtc +Stream +MPC +DPP + +Blender +Degamma +CTM +Gamma +format +bias_and_scale +color space matrix +input_csc_color_matrix +in_transfer_func +hdr_mult +gamut_remap_matrix +in_shaper_func +lut3d_func +blend_tf +Blender +gamut_remap_matrix +func_shaper +lut3d_func +out_transfer_func +csc_color_matrix +bit_depth_param +clamping +output_color_space +Plane +Legend +DCN 3.0 +DC Interface +DRM Interface + +CNVC +Input CSC +DeGammaROM(sRGB,
[PATCH v2 1/4] Documentation/amdgpu_dm: Add DM color correction documentation
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
v2:
- rebase to amd-staging-drm-next
- fix typos (Tales)
- undo kernel-docs inside functions (Tales)
Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Reviewed-by: Tales Aparecida
---
.../gpu/amdgpu/display/display-manager.rst| 9 ++
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 109 +-
2 files changed, 90 insertions(+), 28 deletions(-)
diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 7ce31f89d9a0..b1b0f11aed83 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -40,3 +40,12 @@ Atomic Implementation
.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
:functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
+
+Color Management Properties
+===
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+ :internal:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index a71177305bcd..a4cb23d059bd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -29,7 +29,9 @@
#include "modules/color/color_gamma.h"
#include "basics/conversion.h"
-/*
+/**
+ * DOC: overview
+ *
* The DC interface to HW gives us the following color management blocks
* per pipe (surface):
*
@@ -71,8 +73,8 @@
#define MAX_DRM_LUT_VALUE 0x
-/*
- * Initialize the color module.
+/**
+ * amdgpu_dm_init_color_mod - Initialize the color module.
*
* We're not using the full color module, only certain components.
* Only call setup functions for components that we need.
@@ -82,7 +84,14 @@ void amdgpu_dm_init_color_mod(void)
setup_x_points_distribution();
}
-/* Extracts the DRM lut and lut size from a blob. */
+/**
+ * __extract_blob_lut - Extracts the DRM lut and lut size from a blob.
+ * @blob: DRM color mgmt property blob
+ * @size: lut size
+ *
+ * Returns:
+ * DRM LUT or NULL
+ */
static const struct drm_color_lut *
__extract_blob_lut(const struct drm_property_blob *blob, uint32_t *size)
{
@@ -90,13 +99,18 @@ __extract_blob_lut(const struct drm_property_blob *blob,
uint32_t *size)
return blob ? (struct drm_color_lut *)blob->data : NULL;
}
-/*
- * Return true if the given lut is a linear mapping of values, i.e. it acts
- * like a bypass LUT.
+/**
+ * __is_lut_linear - check if the given lut is a linear mapping of values
+ * @lut: given lut to check values
+ * @size: lut size
*
* It is considered linear if the lut represents:
- * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in
- * [0, MAX_COLOR_LUT_ENTRIES)
+ * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in [0,
+ * MAX_COLOR_LUT_ENTRIES)
+ *
+ * Returns:
+ * True if the given lut is a linear mapping of values, i.e. it acts like a
+ * bypass LUT. Otherwise, false.
*/
static bool __is_lut_linear(const struct drm_color_lut *lut, uint32_t size)
{
@@ -119,9 +133,13 @@ static bool __is_lut_linear(const struct drm_color_lut
*lut, uint32_t size)
return true;
}
-/*
- * Convert the drm_color_lut to dc_gamma. The conversion depends on the size
- * of the lut - whether or not it's legacy.
+/**
+ * __drm_lut_to_dc_gamma - convert the drm_color_lut to dc_gamma.
+ * @lut: DRM lookup table for color conversion
+ * @gamma: DC gamma to set entries
+ * @is_legacy: legacy or atomic gamma
+ *
+ * The conversion depends on the size of the lut - whether or not it's legacy.
*/
static void __drm_lut_to_dc_gamma(const struct drm_color_lut *lut,
struct dc_gamma *gamma, bool is_legacy)
@@ -154,8 +172,11 @@ static void __drm_lut_to_dc_gamma(const struct
drm_color_lut *lut,
}
}
-/*
- * Converts a DRM CTM to a DC CSC float matrix.
+/**
+ * __drm_ctm_to_dc_matrix - converts a DRM CTM to a DC CSC float matrix
+ * @ctm: DRM color transformation matrix
+ * @matrix: DC CSC float matrix
+ *
* The matrix needs to be a 3x4 (12 entry) matrix.
*/
static void __drm_ctm_to_dc_matrix(const struct drm_color_ctm *ctm,
@@ -189,7 +210,18 @@ static void __drm_ctm_to_dc_matrix(const struct
drm_color_ctm *ctm,
}
}
-/* Calculates the legacy transfer function - only for sRGB input space. */
+/**
+ * __set_legacy_tf - Calculates the legacy transfer function
+ * @func: transfer function
+ * @lut: lookup table that defines the color space
+ * @lut_size: size of respective lut
+ * @has_rom: if ROM can be used for hardcoded curve
+ *
+ * Only for sRGB input s
[PATCH v2 0/4] Documentation/amdgpu/display: describe color and blend mode properties mapping
As mentioned in the previous version, patches 1 and 2 describe DM mapping of DRM color correction properties to DC interface and where detached from 3D LUT RFC series [1]. Patches 3 and 4 describe MPC block programming that matches the three DRM blend modes and came from previous work [2][3] and discussions on AMD issue tracker. Let me know any misleading information. In this version, typos were fixed and I removed unusual kernel-docs inside functions, as suggested by Tales. I also added description of some struct elements thanks to Siqueira's feedback. I restructured the introdutory text of the color section, but preserved the content. Unfortunately, there are some missing definitions for mpc_blnd_cfg, that I appreciate if someone can provide more information: ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'overlap_only' not described in 'mpcc_blnd_cfg' ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'bottom_gain_mode' not described in 'mpcc_blnd_cfg' ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'background_color_bpc' not described in 'mpcc_blnd_cfg' ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'top_gain' not described in 'mpcc_blnd_cfg' ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'bottom_inside_gain' not described in 'mpcc_blnd_cfg' ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter or member 'bottom_outside_gain' not described in 'mpcc_blnd_cfg' [1] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/ [2] https://lore.kernel.org/amd-gfx/20220329201835.2393141-1-m...@igalia.com/ [3] https://lore.kernel.org/amd-gfx/7a95d6a4-bc2f-b0e8-83f8-8cc5b7559...@amd.com/ Melissa Wen (4): Documentation/amdgpu_dm: Add DM color correction documentation Documentation/amdgpu/display: add DC color caps info drm/amd/display: add doc entries for MPC blending configuration Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode .../gpu/amdgpu/display/dc-glossary.rst|2 +- .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++ .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 + .../gpu/amdgpu/display/display-manager.rst| 141 ++ Documentation/gpu/drm-kms.rst |2 + .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 109 +- drivers/gpu/drm/amd/display/dc/dc.h | 77 +- drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 91 +- 8 files changed, 3265 insertions(+), 56 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg -- 2.35.1
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, 4 Aug 2022 at 13:51, Marco Felsch wrote: > > Hi Dave, > > On 22-08-04, Dave Stevenson wrote: > > Hi Marco > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > Hi Dave, Adam, > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > Hi Adam > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > > > ... > > > > > > > > > Did managed to get access to the ADV7535 programming guide? This is > > > > > > the > > > > > > black box here. Let me check if I can provide you a link with our > > > > > > repo > > > > > > so you can test our current DSIM state if you want. > > > > > > > > > > I do have access to the programming guide, but it's under NDA, but > > > > > I'll try to answer questions if I can. > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > > > from previously looking at these chips. > > > > > > Thanks for stepping into :) > > > > > > > Mine fairly plainly states: > > > > "The DSI receiver input supports DSI video mode operation only, and > > > > specifically, only supports nonburst mode with sync pulses". > > > > > > I've read this also, and we are working in nonburst mode with sync > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > > verify it. > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > > > HDMI pixel rate. > > > > > > On DSI side you don't have a pixel-clock instead there is bit-clock. > > > > You have an effective pixel clock, with a fixed conversion for the > > configuration. > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > Okay, I just checked the bandwidth which must equal. > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > > running at 891 / 2 = 445.5MHz. > > > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > > > even more explicit about the requirement of DSI timing matching > > > > > > Is it possible to share the key points of the requirements? > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This > > mode requires real time data generation as a pulse packet received > > becomes a pulse generated. Therefore this mode requires a continuous > > stream of data with correct video timing to avoid any visual > > artifacts." > > > > LP mode is supported on data lanes. Clock lane must remain in HS mode. > > > > "... the goal is to accurately convey DPI-type timing over DSI. This > > includes matching DPI pixel-transmission rates, and widths of timing > > events." > > Thanks for sharing. > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > > > be correct for 720p operation. > > > > > > It should be absolute no difference if you work on 891MHz with 2 lanes > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > > > GBps. > > > > Has someone changed the number of lanes in use? I'd missed that if so, > > but I'll agree that 891MHz over 2 lanes should work for 720p60. > > The ADV driver is changing it autom. but this logic is somehow odd and > there was already a approach to stop the driver doing this. I'd missed that bit in the driver where it appears to drop to 3 lanes for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but probably the only way it can be achieved in the current framework. > To sync up: we have two problems: > 1) The 720P mode with static DSI host configuration isn't working > without hacks. > 2) The DSI link frequency should changed as soon as required > automatically. So we can provide all modes. > > I would concentrate on problem 1 first before moving on to the 2nd. If you change your link frequency, it may be worth trying a lower resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 lanes is again listed as mandatory for using the timing generator). > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one > > of the modes that is mandatory to use the timing generator (reg 0x27 > > bit 7 = 1). On 2 lanes it is not required. > > I don't know why it's referencing the 1000/1001 pixel clock rates and > > not the base one, as it's only a base clock change with the same > > timing (74.176MHz clock instead of 74.25MHz). > > Interesting! I would like to know how the HDMI block gets fetched by the > DSI block and how the timing-generator can influence this in good/bad > way. So that we know what DSI settings (freq, lanes) are sufficient. > > > > > If you do program the manual DSI divider register to allow a DSI pixel > > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on > > > > > > There is no such DSI pixel rate to be precise, we only have a DSI bit > > > clock/rate. > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI > > > > tx to compensate for the d
Re: New subsystem for acceleration devices
On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote: > After all, memory management services, or common device chars handling > I can get from other subsystems (e.g. rdma) as well. I'm sure I could > model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI > there as well), but this doesn't mean I belong there, right ? You sure can, but there is still an expectation, eg in RDMA, that your device has a similarity to the established standards (like roce in habana's case) that RDMA is geared to support. I think the the most important thing to establish a new subsystem is to actually identify what commonalities it is supposed to be providing. Usually this is driven by some standards body, but the AI/ML space hasn't gone in that direction at all yet. We don't need a "subsystem" to have a bunch of drivers expose chardevs with completely unique ioctls. The flip is true of DRM - DRM is pretty general. I bet I could implement an RDMA device under DRM - but that doesn't mean it should be done. My biggest concern is that this subsystem not turn into a back door for a bunch of abuse of kernel APIs going forward. Though things are better now, we still see this in DRM where expediency or performance justifies hacky shortcuts instead of good in-kernel architecture. At least DRM has reliable and experienced review these days. Jason
RE: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch > wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > wrote: > > > > > > > > ... > > > > > > > > > > > Did managed to get access to the ADV7535 programming guide? > > > > > > > This is the black box here. Let me check if I can provide > > > > > > > you a link with our repo so you can test our current DSIM > state if you want. > > > > > > > > > > > > I do have access to the programming guide, but it's under NDA, > > > > > > but I'll try to answer questions if I can. > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and > > > > > 7535 from previously looking at these chips. > > > > > > > > Thanks for stepping into :) > > > > > > > > > Mine fairly plainly states: > > > > > "The DSI receiver input supports DSI video mode operation only, > > > > > and specifically, only supports nonburst mode with sync pulses". > > > > > > > > I've read this also, and we are working in nonburst mode with sync > > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > > > verify it. > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same > > > > > as the HDMI pixel rate. > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit- > clock. > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > configuration. > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > Okay, I just checked the bandwidth which must equal. > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > > > running at 891 / 2 = 445.5MHz. > > > > > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide > > > > > is even more explicit about the requirement of DSI timing > > > > > matching > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. > > > This mode requires real time data generation as a pulse packet > > > received becomes a pulse generated. Therefore this mode requires a > > > continuous stream of data with correct video timing to avoid any > > > visual artifacts." > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS > mode. > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. This > > > includes matching DPI pixel-transmission rates, and widths of timing > > > events." > > > > Thanks for sharing. > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would > > > > > therefore be correct for 720p operation. > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that > > > > you need the minimum required bandwidth which is roughly: > > > > 1280*720*24*60 = 1.327 GBps. > > > > > > Has someone changed the number of lanes in use? I'd missed that if > > > so, but I'll agree that 891MHz over 2 lanes should work for 720p60. > > > > The ADV driver is changing it autom. but this logic is somehow odd and > > there was already a approach to stop the driver doing this. > > > > To sync up: we have two problems: > > 1) The 720P mode with static DSI host configuration isn't working > > without hacks. > > can you share your hacks with me about getting 720p to work? I've been > struggling to get 720 to work. I have problems with 720p working on 3 lanes. Then I switch to 4 lanes [1] and it starts working on Renesas RZ/G2L SMARC EVK. [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220309151109.20957-2-biju.das...@bp.renesas.com/ Cheers, Biju
[PATCH v4 1/6] drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
3 regulators are listed but the number 2 is specified. Fix it.
Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
Changes in v4:
- Use more gooder English in the commit description.
Changes in v2:
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 2c23324a2296..02000a7b7a18 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -109,7 +109,7 @@ static const char * const dsi_8996_bus_clk_names[] = {
static const struct msm_dsi_config msm8996_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
- .num = 2,
+ .num = 3,
.regs = {
{"vdda", 18160, 1 },/* 1.25 V */
{"vcca", 17000, 32 }, /* 0.925 V */
--
2.37.1.455.g008518b4e5-goog
[PATCH v4 2/6] drm/msm/dsi: Fix number of regulators for SDM660
1 regulator is listed but the number 2 is specified. This presumably
means we try to get a regulator with no name. Fix it.
Fixes: 462f7017a691 ("drm/msm/dsi: Fix DSI and DSI PHY regulator config from
SDM660")
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
---
Changes in v4:
- Correct the commit that this Fixes.
- Use more gooder English in the commit description.
Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 02000a7b7a18..72c018e26f47 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -148,7 +148,7 @@ static const char * const dsi_sdm660_bus_clk_names[] = {
static const struct msm_dsi_config sdm660_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
- .num = 2,
+ .num = 1,
.regs = {
{"vdda", 12560, 4 },/* 1.2 V */
},
--
2.37.1.455.g008518b4e5-goog
[PATCH v4 3/6] drm/msm/dsi: Don't set a load before disabling a regulator
As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.
It should be noted that all of the loads set that were being specified
were pointless noise anyway. The only use for this number is to pick
between low power and high power modes of regulators. Regulators
appear to do this changeover at loads on the order of 1 uA. You
would need a lot of clients of the same rail for that 100 uA number to
count for anything.
Note that now that we get rid of the setting of the load at disable
time, we can just set the load once when we first get the regulator
and then forget it.
It should also be noted that the regulator functions
regulator_bulk_enable() and regulator_set_load() already print error
messages when they encounter problems so while moving things around we
get rid of some extra error prints.
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
(no changes since v3)
Changes in v3:
- Fix typo in commit message.
- Just directly call the bulk commands; get rid of the wrapper.
drivers/gpu/drm/msm/dsi/dsi.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 52 +++---
drivers/gpu/drm/msm/dsi/dsi_host.c| 71 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 52 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 4 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 6 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 4 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 6 +-
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +-
10 files changed, 60 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 580a1e6358bf..bb6a5bd05cb1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -37,7 +37,6 @@ enum msm_dsi_phy_usecase {
struct dsi_reg_entry {
char name[32];
int enable_load;
- int disable_load;
};
struct dsi_reg_config {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 72c018e26f47..901d6fd53800 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -14,9 +14,9 @@ static const struct msm_dsi_config apq8064_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"avdd", 1, 100}, /* 3.0 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"avdd", 1},/* 3.0 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_v2_bus_clk_names,
@@ -34,9 +34,9 @@ static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
- {"vdd", 15, 100}, /* 3.0 V */
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdd", 15},/* 3.0 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_6g_bus_clk_names,
@@ -54,8 +54,8 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_8916_bus_clk_names,
@@ -73,8 +73,8 @@ static const struct msm_dsi_config msm8976_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_8976_bus_clk_names,
@@ -88,12 +88,12 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
.reg_cfg = {
.num = 6,
.regs = {
- {"vdda", 10, 100}, /* 1.25 V */
- {"vddio", 10, 100}, /* 1.8 V */
- {"vcca", 1, 100}, /* 1.0 V */
- {"vdd", 10, 100}, /* 1.8 V */
- {"la
[PATCH v4 5/6] drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()
As of the commit 1de452a0edda ("regulator: core: Allow drivers to
define their init data as const") we no longer need to do copying of
regulator bulk data from initdata to something dynamic. Let's take
advantage of that.
In addition to saving some code, this also moves us to using
ARRAY_SIZE() to specify how many regulators we have which is less
error prone.
This gets rid of some layers of wrappers which makes it obvious that
we can get rid of an extra error print.
devm_regulator_bulk_get_const() prints errors for you so you don't
need an extra layer of printing.
In all cases here I have preserved the old settings without any
investigation about whether the loads being set are sensible. In the
cases of some of the PHYs if several PHYs in the same file used
exactly the same settings I had them point to the same data structure.
NOTE: Though I haven't done the math, this is likely an overall
savings in terms of "static const" data. We previously always
allocated space for 8 supplies. Each of these supplies took up 36
bytes of data (32 for name, 4 for an int).
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
(no changes since v3)
Changes in v3:
- Do all the PHYs too.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.
drivers/gpu/drm/msm/dsi/dsi.h | 12 --
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 3 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 42 ++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 37 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 5 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 20 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 32 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 14 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 28 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 12 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 32 ++--
12 files changed, 167 insertions(+), 242 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index bb6a5bd05cb1..d661510d570d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -30,20 +30,8 @@ enum msm_dsi_phy_usecase {
MSM_DSI_PHY_SLAVE,
};
-#define DSI_DEV_REGULATOR_MAX 8
#define DSI_BUS_CLK_MAX4
-/* Regulators for DSI devices */
-struct dsi_reg_entry {
- char name[32];
- int enable_load;
-};
-
-struct dsi_reg_config {
- int num;
- struct dsi_reg_entry regs[DSI_DEV_REGULATOR_MAX];
-};
-
struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 901d6fd53800..7e97c239ed48 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -9,16 +9,16 @@ static const char * const dsi_v2_bus_clk_names[] = {
"core_mmss", "iface", "bus",
};
+static const struct regulator_bulk_data apq8064_dsi_regulators[] = {
+ { .supply = "vdda", .init_load_uA = 10 }, /* 1.2 V */
+ { .supply = "avdd", .init_load_uA = 1 },/* 3.0 V */
+ { .supply = "vddio", .init_load_uA = 10 }, /* 1.8 V */
+};
+
static const struct msm_dsi_config apq8064_dsi_cfg = {
.io_offset = 0,
- .reg_cfg = {
- .num = 3,
- .regs = {
- {"vdda", 10}, /* 1.2 V */
- {"avdd", 1},/* 3.0 V */
- {"vddio", 10}, /* 1.8 V */
- },
- },
+ .regulator_data = apq8064_dsi_regulators,
+ .num_regulators = ARRAY_SIZE(apq8064_dsi_regulators),
.bus_clk_names = dsi_v2_bus_clk_names,
.num_bus_clks = ARRAY_SIZE(dsi_v2_bus_clk_names),
.io_start = { 0x470, 0x580 },
@@ -29,16 +29,16 @@ static const char * const dsi_6g_bus_clk_names[] = {
"mdp_core", "iface", "bus", "core_mmss",
};
+static const struct regulator_bulk_data msm8974_apq8084_regulators[] = {
+ { .supply = "vdd", .init_load_uA = 15 },/* 3.0 V */
+ { .supply = "vdda", .init_load_uA = 10 }, /* 1.2 V */
+ { .supply = "vddio", .init_load_uA = 10 }, /* 1.8 V */
+};
+
static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
- .reg_cfg = {
- .num = 3,
- .regs = {
- {"vdd", 15},/* 3.0 V */
- {"vdda", 10}, /* 1.2 V */
- {"vddio", 10}, /* 1.8 V */
- },
- },
+ .regulator_data = msm8974_apq8084_regulators
[PATCH v4 6/6] drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling
The dsi_phy_driver_probe() function has a "goto fail" for no
reason. Change it to just always return directly when it sees an
error. Make this simpler by leveraging dev_err_probe() which is
designed to make code like this shorter / simpler.
NOTE: as part of this, we now pass through error codes directly from
msm_ioremap_size() rather than translating to -ENOMEM. This changed
mostly because it's much more convenient when using dev_err_probe()
and also it's usually encouraged not to hide error codes like the old
code was doing unless there is a good reason. I can't see any reason
why we'd need to return -ENOMEM instead of -EINVAL from the probe
function.
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
Changes in v4:
- Mention error code change in commit message.
Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 74 ++-
1 file changed, 27 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 0a00f9b73fc5..57cd525de7a1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -621,12 +621,9 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
phy->pdev = pdev;
phy->id = dsi_phy_get_id(phy);
- if (phy->id < 0) {
- ret = phy->id;
- DRM_DEV_ERROR(dev, "%s: couldn't identify PHY index, %d\n",
- __func__, ret);
- goto fail;
- }
+ if (phy->id < 0)
+ return dev_err_probe(dev, phy->id,
+"Couldn't identify PHY index\n");
phy->regulator_ldo_mode = of_property_read_bool(dev->of_node,
"qcom,dsi-phy-regulator-ldo-mode");
@@ -634,88 +631,71 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
phy->cphy_mode = (phy_type == PHY_TYPE_CPHY);
phy->base = msm_ioremap_size(pdev, "dsi_phy", &phy->base_size);
- if (IS_ERR(phy->base)) {
- DRM_DEV_ERROR(dev, "%s: failed to map phy base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->base))
+ return dev_err_probe(dev, PTR_ERR(phy->base),
+"Failed to map phy base\n");
phy->pll_base = msm_ioremap_size(pdev, "dsi_pll", &phy->pll_size);
- if (IS_ERR(phy->pll_base)) {
- DRM_DEV_ERROR(&pdev->dev, "%s: failed to map pll base\n",
__func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->pll_base))
+ return dev_err_probe(dev, PTR_ERR(phy->pll_base),
+"Failed to map pll base\n");
if (phy->cfg->has_phy_lane) {
phy->lane_base = msm_ioremap_size(pdev, "dsi_phy_lane",
&phy->lane_size);
- if (IS_ERR(phy->lane_base)) {
- DRM_DEV_ERROR(&pdev->dev, "%s: failed to map phy lane
base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->lane_base))
+ return dev_err_probe(dev, PTR_ERR(phy->lane_base),
+"Failed to map phy lane base\n");
}
if (phy->cfg->has_phy_regulator) {
phy->reg_base = msm_ioremap_size(pdev, "dsi_phy_regulator",
&phy->reg_size);
- if (IS_ERR(phy->reg_base)) {
- DRM_DEV_ERROR(&pdev->dev, "%s: failed to map phy
regulator base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->reg_base))
+ return dev_err_probe(dev, PTR_ERR(phy->reg_base),
+"Failed to map phy regulator
base\n");
}
if (phy->cfg->ops.parse_dt_properties) {
ret = phy->cfg->ops.parse_dt_properties(phy);
if (ret)
- goto fail;
+ return ret;
}
ret = devm_regulator_bulk_get_const(dev, phy->cfg->num_regulators,
phy->cfg->regulator_data,
&phy->supplies);
if (ret)
- goto fail;
+ return ret;
phy->ahb_clk = msm_clk_get(pdev, "iface");
- if (IS_ERR(phy->ahb_clk)) {
- DRM_DEV_ERROR(dev, "%s: Unable to get ahb clk\n", __func__);
- ret = PTR_ERR(phy->ahb_clk);
- goto fail;
- }
+ if (IS_ERR(phy->ahb_clk))
+ return dev_err_probe(dev, PTR_ERR(phy->ahb_clk),
+"Unable to get ahb clk\n");
/* PLL init wi
[PATCH v4 4/6] drm/msm/dsi: Use the new regulator bulk feature to specify the load
As of commit 6eabfc018e8d ("regulator: core: Allow specifying an
initial load w/ the bulk API") we can now specify the initial load in
the bulk data rather than having to manually call regulator_set_load()
on each regulator. Let's use it.
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
(no changes since v3)
Changes in v3:
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Use the new regulator bulk feature to specify the load") new for v2.
drivers/gpu/drm/msm/dsi/dsi_host.c| 13 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 13 +++--
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9df278d39559..a0a1b6d61d05 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -260,8 +260,10 @@ static int dsi_regulator_init(struct msm_dsi_host
*msm_host)
int num = msm_host->cfg_hnd->cfg->reg_cfg.num;
int i, ret;
- for (i = 0; i < num; i++)
+ for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+ s[i].init_load_uA = regs[i].enable_load;
+ }
ret = devm_regulator_bulk_get(&msm_host->pdev->dev, num, s);
if (ret < 0) {
@@ -270,15 +272,6 @@ static int dsi_regulator_init(struct msm_dsi_host
*msm_host)
return ret;
}
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
- if (ret < 0)
- return ret;
- }
- }
-
return 0;
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 7c105120d73e..efb6b1726cdb 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -515,8 +515,10 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
int num = phy->cfg->reg_cfg.num;
int i, ret;
- for (i = 0; i < num; i++)
+ for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+ s[i].init_load_uA = regs[i].enable_load;
+ }
ret = devm_regulator_bulk_get(dev, num, s);
if (ret < 0) {
@@ -529,15 +531,6 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
return ret;
}
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
- regs[i].enable_load);
- if (ret < 0)
- return ret;
- }
- }
-
return 0;
}
--
2.37.1.455.g008518b4e5-goog
[PATCH v4 0/6] drm/msm/dsi regulator improvements
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads for DSI drivers.
As of v3 of this series, the regulator API improvements needed for the
later patches in the series are merged into mainline. Thus this series
only contains the DSI changes now.
I'd expect:
* The first two patches are bugfixes found while converting the DSI
driver over. Those could land any time.
* The third patch ("drm/msm/dsi: Don't set a load before disabling a
regulator") is a patch a sent the other day verbatim, included in
this series because it's highly related. It could land any
time.
* The next two patches use the new APIs. Since those APIs are now in
mainline those could also land any time.
* The last patch is just cleanup I noticed as I was touching the
function. It's not really related to regulators but it applies atop
these. In theory it could be rebased to land separately.
Changes in v4:
- Correct the commit that this Fixes.
- Mention error code change in commit message.
- Use more gooder English in the commit description.
Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.
- Do all the PHYs too.
- Fix typo in commit message.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.
- ("Use the new regulator bulk feature to specify the load") new for v2.
Douglas Anderson (6):
drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
drm/msm/dsi: Fix number of regulators for SDM660
drm/msm/dsi: Don't set a load before disabling a regulator
drm/msm/dsi: Use the new regulator bulk feature to specify the load
drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()
drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling
drivers/gpu/drm/msm/dsi/dsi.h | 13 --
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 3 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 96 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 160
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 5 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 20 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 32 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 14 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 28 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 12 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 32 ++--
12 files changed, 197 insertions(+), 390 deletions(-)
--
2.37.1.455.g008518b4e5-goog
Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280
On Thu, Aug 4, 2022 at 3:29 AM Kalyan Thota wrote:
>
> +static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
> + enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> +{
> + uint32_t flushbits = 0, active = 0;
nit: don't init to 0 since you just override below.
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> index ac15444..8ecab91 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> @@ -160,6 +160,9 @@ struct dpu_hw_ctl_ops {
> uint32_t (*get_bitmask_dspp)(struct dpu_hw_ctl *ctx,
> enum dpu_dspp blk);
>
> + void (*set_dspp_hierarchical_flush)(struct dpu_hw_ctl *ctx,
> + enum dpu_dspp blk, enum dpu_dspp_sub_blk dspp_sub_blk);
> +
Given that most of the items in this list have kernel-doc comments
explaining them, probably you should have one for your new one too.
-Doug
Re: [PATCH] drm/amd/display: restore plane with no modifiers code.
On 2022-08-04 01:50, Dave Airlie wrote:
> When this file was split in
>
> 5d945cbcd4b16a29d6470a80dfb19738f9a4319f
> Author: Rodrigo Siqueira
> Date: Wed Jul 20 15:31:42 2022 -0400
>
> drm/amd/display: Create a file dedicated to planes
>
> This chunk seemed to get dropped. Linus noticed on this
> rx580 and I've reproduced on FIJI which makes sense as these
> are pre-modifier GPUs.
>
> With this applied, I get gdm back.
>
> Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
> Signed-off-by: Dave Airlie
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 8cd25b2ea0dc..b841b8b0a9d8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1591,6 +1591,9 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager
> *dm,
> if (res)
> return res;
>
> + if (modifiers == NULL)
> + adev_to_drm(dm->adev)->mode_config.fb_modifiers_not_supported =
> true;
> +
> res = drm_universal_plane_init(adev_to_drm(dm->adev), plane,
> possible_crtcs,
> &dm_plane_funcs, formats, num_formats,
> modifiers, plane->type, NULL);
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, On 22-08-04, Adam Ford wrote: > On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch wrote: > > > > Hi Dave, > > > > On 22-08-04, Dave Stevenson wrote: > > > Hi Marco > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > > > Hi Dave, Adam, > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > Hi Adam > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > > > > > ... > > > > > > > > > > > Did managed to get access to the ADV7535 programming guide? This > > > > > > > is the > > > > > > > black box here. Let me check if I can provide you a link with our > > > > > > > repo > > > > > > > so you can test our current DSIM state if you want. > > > > > > > > > > > > I do have access to the programming guide, but it's under NDA, but > > > > > > I'll try to answer questions if I can. > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > > > > from previously looking at these chips. > > > > > > > > Thanks for stepping into :) > > > > > > > > > Mine fairly plainly states: > > > > > "The DSI receiver input supports DSI video mode operation only, and > > > > > specifically, only supports nonburst mode with sync pulses". > > > > > > > > I've read this also, and we are working in nonburst mode with sync > > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > > > verify it. > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > > > > HDMI pixel rate. > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit-clock. > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > configuration. > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > Okay, I just checked the bandwidth which must equal. > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > > > running at 891 / 2 = 445.5MHz. > > > > > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > > > > even more explicit about the requirement of DSI timing matching > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This > > > mode requires real time data generation as a pulse packet received > > > becomes a pulse generated. Therefore this mode requires a continuous > > > stream of data with correct video timing to avoid any visual > > > artifacts." > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS mode. > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. This > > > includes matching DPI pixel-transmission rates, and widths of timing > > > events." > > > > Thanks for sharing. > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > > > > be correct for 720p operation. > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 lanes > > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > > > > GBps. > > > > > > Has someone changed the number of lanes in use? I'd missed that if so, > > > but I'll agree that 891MHz over 2 lanes should work for 720p60. > > > > The ADV driver is changing it autom. but this logic is somehow odd and > > there was already a approach to stop the driver doing this. > > > > To sync up: we have two problems: > > 1) The 720P mode with static DSI host configuration isn't working > > without hacks. > > can you share your hacks with me about getting 720p to work? I've > been struggling to get 720 to work. Here you go: https://git.pengutronix.de/cgit/mfe/linux It has just one branch, so very easy. If you use a 8MMini-EVK with the NXP-Adapter than you only need a proper defconfig. > > 2) The DSI link frequency should changed as soon as required > > automatically. So we can provide all modes. > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > I do have some code that does #2 already. Unfortunately no, since we want to fix problem 1 first. > I can clean it up and share if you want. I've been bouncing back and > forth between the NXP kernel and the Jagan/Fabio kernel to compare and > with my clock change, it appears to be generating similar clocks to > the NXP, yet it still won't sync at 720P. > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one > > > of the modes that is mandatory to use the timing generator (reg 0x27 > > > bit 7 = 1). On 2 lanes it is not required. > > > I don't know why it's referencing the 1000/1001 pixel clock rates and > > > not the base one, as it's only a base clock change with the same > > > timing (74.176MHz clock instead of 74.25MHz). > > > > Interesting! I would like to know how the HDMI block gets fetched by the > > DSI block and h
[PATCH] drm/gma500: Fix comment typo
The double `the' is duplicated in the comment, remove one. Signed-off-by: Jason Wang --- drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c b/drivers/gpu/drm/gma500/cdv_intel_dp.c index bb2e9d64018a..53b967282d6a 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c @@ -115,7 +115,7 @@ i2c_algo_dp_aux_stop(struct i2c_adapter *adapter, bool reading) /* * Write a single byte to the current I2C address, the - * the I2C link must be running or this returns -EIO + * I2C link must be running or this returns -EIO */ static int i2c_algo_dp_aux_put_byte(struct i2c_adapter *adapter, u8 byte) -- 2.35.1
[PATCH] drm/panel: nt35510: Fix comment typo
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index 40ea41b0a5dd..4085822f619a 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -231,7 +231,7 @@ struct nt35510_config {
* bits 0..2 in the lower nibble controls HCK, the booster clock
* frequency, the values are the same as for PCK in @bt1ctr.
* bits 4..5 in the upper nibble controls BTH, the boosting
-* amplification for the the step-up circuit.
+* amplification for the step-up circuit.
* 0 = AVDD + VDDB
* 1 = AVDD - AVEE
* 2 = AVDD - AVEE + VDDB
--
2.35.1
[PATCH] drm/mipi-dsi: Fix comment typo
The double `the' is duplicated in the comment, remove one. Signed-off-by: Jason Wang --- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index c40bde96cfdf..fd2790a5664d 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -606,7 +606,7 @@ EXPORT_SYMBOL(mipi_dsi_turn_on_peripheral); /* * mipi_dsi_set_maximum_return_packet_size() - specify the maximum size of the - *the payload in a long packet transmitted from the peripheral back to the + *payload in a long packet transmitted from the peripheral back to the *host processor * @dsi: DSI peripheral device * @value: the maximum size of the payload -- 2.35.1
[PATCH] drm/display: Fix comment typo
The double `the' is duplicated in the comment, remove one. Signed-off-by: Jason Wang --- drivers/gpu/drm/display/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c index e5bab236b3ae..32b295003f49 100644 --- a/drivers/gpu/drm/display/drm_dp_helper.c +++ b/drivers/gpu/drm/display/drm_dp_helper.c @@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg) /* * Calculate the length of the i2c transfer in usec, assuming - * the i2c bus speed is as specified. Gives the the "worst" + * the i2c bus speed is as specified. Gives the "worst" * case estimate, ie. successful while as long as possible. * Doesn't account the "MOT" bit, and instead assumes each * message includes a START, ADDRESS and STOP. Neither does it -- 2.35.1
[PATCH 2/2] drm/cmdline-parser: Use assert when needed
Expecting to observe a specific value, when the function responsible for
setting the value has failed will lead to extra noise in test output.
Use assert when the situation calls for it.
Also - very small tidying up around the changed areas (whitespace /
variable locality).
Signed-off-by: Michał Winiarski
---
.../gpu/drm/tests/drm_cmdline_parser_test.c | 93 +--
1 file changed, 46 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 058808faaf4a..7a313e2fd52a 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -16,7 +16,7 @@ static void drm_cmdline_test_force_e_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "e";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -34,7 +34,7 @@ static void drm_cmdline_test_force_D_only_not_digital(struct
kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -47,16 +47,16 @@ static void
drm_cmdline_test_force_D_only_not_digital(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON);
}
-static const struct drm_connector connector_hdmi = {
- .connector_type = DRM_MODE_CONNECTOR_HDMIB,
-};
static void drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
+ const struct drm_connector connector_hdmi = {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIB,
+ };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&connector_hdmi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -69,16 +69,15 @@ static void drm_cmdline_test_force_D_only_hdmi(struct kunit
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON_DIGITAL);
}
-static const struct drm_connector connector_dvi = {
- .connector_type = DRM_MODE_CONNECTOR_DVII,
-};
-
static void drm_cmdline_test_force_D_only_dvi(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
+ const struct drm_connector connector_dvi = {
+ .connector_type = DRM_MODE_CONNECTOR_DVII,
+ };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&connector_dvi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -96,7 +95,7 @@ static void drm_cmdline_test_force_d_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "d";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -114,7 +113,7 @@ static void drm_cmdline_test_res(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_TRUE(test, mode.specified);
KUNIT_EXPECT_EQ(test, mode.xres, 720);
@@ -136,7 +135,7 @@ static void drm_cmdline_test_res_vesa(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480M";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_co
[PATCH 1/2] drm/cmdline-parser: Merge negative tests
Negative tests can be expressed as a single parameterized test case,
which highlights that we're following the same test logic (passing
negative cmdline and expecting drm_mode_parse_command_line_for_connector
to fail), which improves readability.
Signed-off-by: Michał Winiarski
---
.../gpu/drm/tests/drm_cmdline_parser_test.c | 293 ++
1 file changed, 103 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 59b29cdfdd35..058808faaf4a 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -109,24 +109,6 @@ static void drm_cmdline_test_force_d_only(struct kunit
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
}
-static void drm_cmdline_test_margin_only(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "m";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_interlace_only(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "i";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -149,42 +131,6 @@ static void drm_cmdline_test_res(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_missing_x(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "x480";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024x";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_bad_y(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024xtest";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y_bpp(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024x-24";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_vesa(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -274,15 +220,6 @@ static void drm_cmdline_test_res_bpp(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_bad_bpp(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480-test";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_refresh(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -306,15 +243,6 @@ static void drm_cmdline_test_res_refresh(struct kunit
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_bad_refresh(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480@refresh";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_bpp_refresh(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -411,15 +339,6 @@ static void
drm_cmdline_test_res_bpp_refresh_force_off(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
}
-static void drm_cmdline_test_res_bpp_refresh_force_on_off(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480-24@60de";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_t
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, On 22-08-04, Dave Stevenson wrote: > Hi Marco > > On Thu, 4 Aug 2022 at 11:28, Marco Felsch wrote: > > > > On 22-08-03, Dave Stevenson wrote: > > > On Wed, 3 Aug 2022 at 13:31, Adam Ford wrote: > > > > ... > > > > > > Mine also states the DSI source needs to provide correct video timing > > > > with start and stop sync packets. > > > > > > > > If I remember correctly, it seemed like Marek V wanted the hard coded > > > > samsung,burst-clock-frequency to go away so the clock frequency could > > > > be set dynamically. > > > > > > I've never worked with Exynos or imx8, but my view would be that > > > samsung,burst-clock-frequency should only be used if > > > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for > > > adv7533/5). > > > > Some notes on that. The samsung,burst-clock-frequency is the > > hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to > > do with the MIPI_DSI_MODE_VIDEO_BURST. > > > > > Without that flag the DSI link frequency should be running at the rate > > > defined by the mode clock, number of lanes, bpp, etc. > > > > IMHO the DSI link have only to guarantee the bandwidth is sufficient for > > the mode. > > DSI spec 8.11.3 Non-Burst Mode with Sync Events > "This mode is a simplification of the format described in Section > 8.11.2 (Non-Burst Mode with Sync Pulses) > ... > Pixels are transmitted at the same rate as they would in a > corresponding parallel display interface such as DPI-2." > > If you are running the DSI clock at anything other than that rate, > then AIUI you are in a burst mode (although you may choose not to drop > into LP mode). Yes, that makes sense to me. The bandwidth on the DSI side should match the one required on the other side (HDMI). Apart the fact that the ADV is working in mode 8.11.2 (Non-Burst Mode with Sync Pulses). > (One of my pet peeves that there is no documentation as to exactly > what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI > spec all modes of 8.11 say that the host can drop to LP during > blanking if time allows, it surely has to be the time compression > element of 8.11.4 Burst Mode). Hm.. I don't have the DSI spec either but I thought that BURST mode allows the host to send the data as fast as possible and enter LP afterwards. > > > From the DSI spec (v 1.1 section 8.11.1): > > > "Non-Burst Mode with Sync Pulses – enables the peripheral to > > > accurately reconstruct original video timing, including sync pulse > > > widths." > > > "RGB pixel packets are time-compressed, leaving more time during a > > > scan line for LP mode (saving power) or for multiplexing other > > > transmissions onto the DSI link." > > > How can the peripheral reconstruct the video timing off a quirky link > > > frequency? > > > > If the ADV couldn't reconstruct the sync signals, then we should not get > > any mode working but we get the 1080P mode working. > > > > > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1] > > > reconfigures the clock setup of the DSI block, then I don't see how > > > the Exynos driver can follow the DSI spec in that regard. > > > > Why do you think that the Exynos driver isn't following the spec? We > > configure the host into video mode with sync signals which is working > > for the 1080P mode. > > 1080p is working with samsung,burst-clock-frequency setting? Yes. > As I say, I've not worked with this IP, I'm only looking at it from > the outside having spent far too much time recently on the Pi DSI > interface. Good to know :) > exynos_drm_dsi.c seems to be doing a lot of PLL computation around > burst-clock-frequency, and nothing with the pixel clock rate. Yes currently there is just this setting for setting the PLL freq. but as you said for the "Non-Burst Mode with Sync Pulses" we need to reconfigure it according the required bandwidth or the dsi-device tells us about which dsi-link settings should be applied. > Without knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG > actually does in the hardware, I can only make guesses. 8<-- Selects Burst mode in Video mode In Non-burst mode, RGB data area is filled with RGB data and Null packets, according to input bandwidth of RGB interface. In Burst mode, RGB data area is filled with RGB data only. 0 = Non-burst mode 1 = Burst mode 8<-- According the current implementation we are in Non-burst mode. Regards, Marco > Perhaps it does ditch the burst clock and switch the bit clock to be > derived from the pixel clock of the upstream block, but that seems > unlikely. > > Dave >
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch wrote: > > Hi Dave, > > On 22-08-04, Dave Stevenson wrote: > > Hi Marco > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > > > Hi Dave, Adam, > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > Hi Adam > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > > > ... > > > > > > > > > Did managed to get access to the ADV7535 programming guide? This is > > > > > > the > > > > > > black box here. Let me check if I can provide you a link with our > > > > > > repo > > > > > > so you can test our current DSIM state if you want. > > > > > > > > > > I do have access to the programming guide, but it's under NDA, but > > > > > I'll try to answer questions if I can. > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > > > from previously looking at these chips. > > > > > > Thanks for stepping into :) > > > > > > > Mine fairly plainly states: > > > > "The DSI receiver input supports DSI video mode operation only, and > > > > specifically, only supports nonburst mode with sync pulses". > > > > > > I've read this also, and we are working in nonburst mode with sync > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > > verify it. > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > > > HDMI pixel rate. > > > > > > On DSI side you don't have a pixel-clock instead there is bit-clock. > > > > You have an effective pixel clock, with a fixed conversion for the > > configuration. > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > Okay, I just checked the bandwidth which must equal. > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > > running at 891 / 2 = 445.5MHz. > > > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > > > even more explicit about the requirement of DSI timing matching > > > > > > Is it possible to share the key points of the requirements? > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This > > mode requires real time data generation as a pulse packet received > > becomes a pulse generated. Therefore this mode requires a continuous > > stream of data with correct video timing to avoid any visual > > artifacts." > > > > LP mode is supported on data lanes. Clock lane must remain in HS mode. > > > > "... the goal is to accurately convey DPI-type timing over DSI. This > > includes matching DPI pixel-transmission rates, and widths of timing > > events." > > Thanks for sharing. > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > > > be correct for 720p operation. > > > > > > It should be absolute no difference if you work on 891MHz with 2 lanes > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > > > GBps. > > > > Has someone changed the number of lanes in use? I'd missed that if so, > > but I'll agree that 891MHz over 2 lanes should work for 720p60. > > The ADV driver is changing it autom. but this logic is somehow odd and > there was already a approach to stop the driver doing this. > > To sync up: we have two problems: > 1) The 720P mode with static DSI host configuration isn't working > without hacks. can you share your hacks with me about getting 720p to work? I've been struggling to get 720 to work. > 2) The DSI link frequency should changed as soon as required > automatically. So we can provide all modes. > > I would concentrate on problem 1 first before moving on to the 2nd. I do have some code that does #2 already. I can clean it up and share if you want. I've been bouncing back and forth between the NXP kernel and the Jagan/Fabio kernel to compare and with my clock change, it appears to be generating similar clocks to the NXP, yet it still won't sync at 720P. > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one > > of the modes that is mandatory to use the timing generator (reg 0x27 > > bit 7 = 1). On 2 lanes it is not required. > > I don't know why it's referencing the 1000/1001 pixel clock rates and > > not the base one, as it's only a base clock change with the same > > timing (74.176MHz clock instead of 74.25MHz). > > Interesting! I would like to know how the HDMI block gets fetched by the > DSI block and how the timing-generator can influence this in good/bad > way. So that we know what DSI settings (freq, lanes) are sufficient. > > > > > If you do program the manual DSI divider register to allow a DSI pixel > > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on > > > > > > There is no such DSI pixel rate to be precise, we only have a DSI bit > > > clock/rate. > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI > > > > tx to compensate for the differing
[PATCH 0/3] Fix bugs in *_set_par() caused by user input
In the function *_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause a bug in the memset_io(). Zheyu Ma (3): video: fbdev: vt8623fb: Check the size of screen before memset_io() video: fbdev: arkfb: Check the size of screen before memset_io() video: fbdev: s3fb: Check the size of screen before memset_io() drivers/video/fbdev/arkfb.c| 2 ++ drivers/video/fbdev/s3fb.c | 2 ++ drivers/video/fbdev/vt8623fb.c | 2 ++ 3 files changed, 6 insertions(+) -- 2.25.1
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, On 22-08-04, Dave Stevenson wrote: > Hi Marco > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > > > Hi Dave, Adam, > > > > On 22-08-03, Dave Stevenson wrote: > > > Hi Adam > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > > > ... > > > > > > > Did managed to get access to the ADV7535 programming guide? This is > > > > > the > > > > > black box here. Let me check if I can provide you a link with our repo > > > > > so you can test our current DSIM state if you want. > > > > > > > > I do have access to the programming guide, but it's under NDA, but > > > > I'll try to answer questions if I can. > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > > from previously looking at these chips. > > > > Thanks for stepping into :) > > > > > Mine fairly plainly states: > > > "The DSI receiver input supports DSI video mode operation only, and > > > specifically, only supports nonburst mode with sync pulses". > > > > I've read this also, and we are working in nonburst mode with sync > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > > verify it. > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > > HDMI pixel rate. > > > > On DSI side you don't have a pixel-clock instead there is bit-clock. > > You have an effective pixel clock, with a fixed conversion for the > configuration. > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s Okay, I just checked the bandwidth which must equal. > As noted elsewhere, the DSI is DDR, so the clock lane itself is only > running at 891 / 2 = 445.5MHz. > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > > even more explicit about the requirement of DSI timing matching > > > > Is it possible to share the key points of the requirements? > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This > mode requires real time data generation as a pulse packet received > becomes a pulse generated. Therefore this mode requires a continuous > stream of data with correct video timing to avoid any visual > artifacts." > > LP mode is supported on data lanes. Clock lane must remain in HS mode. > > "... the goal is to accurately convey DPI-type timing over DSI. This > includes matching DPI pixel-transmission rates, and widths of timing > events." Thanks for sharing. > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > > be correct for 720p operation. > > > > It should be absolute no difference if you work on 891MHz with 2 lanes > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > > GBps. > > Has someone changed the number of lanes in use? I'd missed that if so, > but I'll agree that 891MHz over 2 lanes should work for 720p60. The ADV driver is changing it autom. but this logic is somehow odd and there was already a approach to stop the driver doing this. To sync up: we have two problems: 1) The 720P mode with static DSI host configuration isn't working without hacks. 2) The DSI link frequency should changed as soon as required automatically. So we can provide all modes. I would concentrate on problem 1 first before moving on to the 2nd. > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one > of the modes that is mandatory to use the timing generator (reg 0x27 > bit 7 = 1). On 2 lanes it is not required. > I don't know why it's referencing the 1000/1001 pixel clock rates and > not the base one, as it's only a base clock change with the same > timing (74.176MHz clock instead of 74.25MHz). Interesting! I would like to know how the HDMI block gets fetched by the DSI block and how the timing-generator can influence this in good/bad way. So that we know what DSI settings (freq, lanes) are sufficient. > > > If you do program the manual DSI divider register to allow a DSI pixel > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on > > > > There is no such DSI pixel rate to be precise, we only have a DSI bit > > clock/rate. > > > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI > > > tx to compensate for the differing data rates. I see no reference to > > > such, and I'd be surprised if it was more than a half dozen pixels to > > > compensate for the jitter in the cases where the internal timing > > > generator is mandatory due to fractional bytes. > > > > This is interesting and would proofs our assumption that the device > > don't have a FIFO :) > > > > Our assumptions (we don't have the datasheet/programming manual): > > - HDMI part is fetching 3 bytes per HDMI pixclk > > - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and > > HDMI are in sync. So from bandwidth pov there are no differences > > between: > > - HDMI: 74.25 MHz * 24 Bit = 1782.0
Re: [PATCH] drm/imx/dcss: get rid of HPD warning message
On Thu, Jul 21, 2022 at 03:25:02PM +0300, Laurent Pinchart wrote:
> Hi Laurentiu,
>
> Thank you for the patch.
>
> On Thu, Jul 21, 2022 at 03:09:12PM +0300, Laurentiu Palcu wrote:
> > When DCSS + MIPI_DSI is used, and the last bridge in the chain supports
> > HPD, we can see a "Hot plug detection already enabled" warning stack
> > trace dump that's thrown when DCSS is initialized.
> >
> > The problem appeared when HPD was enabled by default in the
> > bridge_connector initialization, which made the
> > drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant.
> > So, let's remove that call.
> >
> > Fixes: 09077bc311658 ("drm/bridge_connector: enable HPD by default if
> > supported")
> > Signed-off-by: Laurentiu Palcu
>
> Reviewed-by: Laurent Pinchart
Applied to drm-misc/drm-misc-fixes.
Thanks,
laurentiu
[PATCH 3/3] video: fbdev: s3fb: Check the size of screen before memset_io()
In the function s3fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 54.083733] BUG: unable to handle page fault for address: c9000300
[ 54.083742] #PF: supervisor write access in kernel mode
[ 54.083744] #PF: error_code(0x0002) - not-present page
[ 54.083760] RIP: 0010:memset_orig+0x33/0xb0
[ 54.083782] Call Trace:
[ 54.083788] s3fb_set_par+0x1ec6/0x4040
[ 54.083806] fb_set_var+0x604/0xeb0
[ 54.083836] do_fb_ioctl+0x234/0x670
Fix the this by checking the value of 'screen_size' before memset_io().
Fixes: a268422de8bf ("[PATCH] fbdev driver for S3 Trio/Virge")
Signed-off-by: Zheyu Ma
---
drivers/video/fbdev/s3fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index b93c8eb02336..5069f6f67923 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -905,6 +905,8 @@ static int s3fb_set_par(struct fb_info *info)
value = clamp((htotal + hsstart + 1) / 2 + 2, hsstart + 4, htotal + 1);
svga_wcrt_multi(par->state.vgabase, s3_dtpc_regs, value);
+ if (screen_size > info->screen_size)
+ screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
svga_wcrt_mask(par->state.vgabase, 0x17, 0x80, 0x80);
--
2.25.1
[PATCH 2/3] video: fbdev: arkfb: Check the size of screen before memset_io()
In the function arkfb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 659.399066] BUG: unable to handle page fault for address: c9000300
[ 659.399077] #PF: supervisor write access in kernel mode
[ 659.399079] #PF: error_code(0x0002) - not-present page
[ 659.399094] RIP: 0010:memset_orig+0x33/0xb0
[ 659.399116] Call Trace:
[ 659.399122] arkfb_set_par+0x143f/0x24c0
[ 659.399130] fb_set_var+0x604/0xeb0
[ 659.399161] do_fb_ioctl+0x234/0x670
[ 659.399189] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io().
Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards")
Signed-off-by: Zheyu Ma
---
drivers/video/fbdev/arkfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index eb3e47c58c5f..de4002914f9e 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -792,6 +792,8 @@ static int arkfb_set_par(struct fb_info *info)
value = ((value * hmul / hdiv) / 8) - 5;
vga_wcrt(par->state.vgabase, 0x42, (value + 1) / 2);
+ if (screen_size > info->screen_size)
+ screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
svga_wcrt_mask(par->state.vgabase, 0x17, 0x80, 0x80);
--
2.25.1
[PATCH 1/3] video: fbdev: vt8623fb: Check the size of screen before memset_io()
In the function vt8623fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 583.339036] BUG: unable to handle page fault for address: c9000500
[ 583.339049] #PF: supervisor write access in kernel mode
[ 583.339052] #PF: error_code(0x0002) - not-present page
[ 583.339074] RIP: 0010:memset_orig+0x33/0xb0
[ 583.339110] Call Trace:
[ 583.339118] vt8623fb_set_par+0x11cd/0x21e0
[ 583.339146] fb_set_var+0x604/0xeb0
[ 583.339181] do_fb_ioctl+0x234/0x670
[ 583.339209] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io().
Fixes: 558b7bd86c32 ("vt8623fb: new framebuffer driver for VIA VT8623")
Signed-off-by: Zheyu Ma
---
drivers/video/fbdev/vt8623fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index a92a8c670cf0..4274c6efb249 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -507,6 +507,8 @@ static int vt8623fb_set_par(struct fb_info *info)
(info->var.vmode & FB_VMODE_DOUBLE) ? 2 : 1, 1,
1, info->node);
+ if (screen_size > info->screen_size)
+ screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
--
2.25.1
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Am 03.08.22 um 03:49 schrieb Kevin Brace: Hi Thomas, I am honestly surprised of the e-mail back and forth regarding the mainlining of OpenChrome DRM, but let me state my position. That's because your expectations are unrealistic. We don't know you, you apparently have little prior kernel experience and want to merge code that is essentially your pet project. It's also not a good start to insist on merging new uapi calls. Upstream kernel is not a place to dump code that you declare ready. You're becoming part of a community. Your first priority should be to earn the trust of the other developers on this mailing list. Considering the age of the hardware I am dealing with (i.e., pre-OpenGL 2.x generation 3D engine), I do not anticipate being able to run OpenChrome on Wayland with acceleration. Acceleration and wayland are independent from each other. As a first step after mainlining, I am looking to add uAPI to pass 2D / 3D acceleration commands to the graphics engine, but frankly, I am going to focus on the 2D acceleration side first. Did you read https://blog.ffwll.ch/2018/08/no-2d-in-drm.html ? Considering the age of the hardware, I do not think limiting the use to X.Org X Server is a bad choice. If you're not interested in running modern userspace, then why are you doing this anyway? Everyone with an X server can already use the existing DRI1 code. You also don't seem to understand the state of the Linux graphics stack. First of all, you're not building a driver for one particular program, but for all of them. There's the X server, a number of Wayland compositors, and a few more outlandish things like kmscon. And secondly, did you read https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html ? Xorg-on-hardware is pretty much dead. There hasn't been a release for years. What will remain is Xorg-on-Wayland, which is provided by xwayland. I do OpenChrome development on Gentoo Linux where 32-bit x86 ISA and X.Org X Server are still fully supported. Adding 3D acceleration will likely be done after 2D and video accelerations are mostly working. Video acceleration seems realistic. 2d and 3d not so much. 2d for reasons given in Daniel's blog. 3d because the hardware might be too old already. If VIA really only supports OpenGL-1.x-era features, you'd have to revive the old mesa branches to use it. But I can't say for sure. The proposed OpenChrome uAPI is essentially a cutdown version of the mostly 2D acceleration focused implementation (my opinion) being worked on and off since 2011. The limited addition of uAPI calls is merely a preparatory step for adding 2D acceleration in the near future (I have not started the work yet.). I assume you are aware that OpenChrome DDX is a user of DRM_VIA_GEM_CREATE, DRM_VIA_GEM_MAP, and DRM_VIA_GEM_UNMAP uAPIs. To my understanding, the DDX code only exists in a repository in a git tree of yours. That's not "userspace". For those who still choose to use older generation hardware, I think X.Org X Server still has a lot of life left in it, and I plan to continue modernizing the graphics stack for what I call "underserved" (i.e., neglected) graphics hardware. As I said we welcome drivers for old hardware. But your current proposal is not feasible and will cause friction with upstream. Here's a suggestion that is more promising. 1) Get an un-accelerated driver merged without new uapi, ioctls, etc. All you need is there already. We already agreed to take the code mostly as-is and do the cleanups later on. 2a) Stay around on dri-devel, send improvements and fixes for the merged code. 2b) In parallel, you can work on video, 3d, etc in both kernel and userspace. 3) When you have a feature ready, send a patchset to dri-devel with the kernel changes and another patchset to the respective userspace project (e.g., Mesa). They should refer to each other, so that reviewers can see both sides of the interface at the same time. Best regards Thomas Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com Sent: Tuesday, August 02, 2022 at 4:38 AM From: "Thomas Zimmermann" To: "Kevin Brace" Cc: dri-devel@lists.freedesktop.org Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h Hi Am 02.08.22 um 05:45 schrieb Kevin Brace: Hi Thomas, I hope I am comprehending this right. Yes, I am adding 3 new uAPI calls, not 6 of them. Correspondingly, there are 3 new structs added. That's understood. While I may drop one (unmap uAPI), I personally do not wish to drop the other two at this point. Instead, I may need to add setparam and / or getparam uAPI to pass PCI Device ID back to the userspace. This is mainly needed by Mesa, although there is no code for Mesa at this point. Exactly my point! There's no userspace for it. That's why Sam and me are asking you to remove all kinds if uapi changes or ioctls from the patchset until Mesa (or some other component)
[PATCH RFC] dma-buf: To check DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT status on debug
If core DMA-buf framework forgets to call dma_fence_enable_signaling()
before calling the dma_fence_is_signaled(). To handle this scenario on
debug kernel the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT needs to be checked
before checking the actual signaling status.
Signed-off-by: Arvind Yadav
---
include/linux/dma-fence.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 775cdc0b4f24..7c95c8d5e5f5 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -428,6 +428,10 @@ dma_fence_is_signaled_locked(struct dma_fence *fence)
static inline bool
dma_fence_is_signaled(struct dma_fence *fence)
{
+#ifdef CONFIG_DEBUG_FS
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags))
+ return true;
+#endif
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return true;
--
2.25.1
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Marco On Thu, 4 Aug 2022 at 11:28, Marco Felsch wrote: > > On 22-08-03, Dave Stevenson wrote: > > On Wed, 3 Aug 2022 at 13:31, Adam Ford wrote: > > ... > > > > Mine also states the DSI source needs to provide correct video timing > > > with start and stop sync packets. > > > > > > If I remember correctly, it seemed like Marek V wanted the hard coded > > > samsung,burst-clock-frequency to go away so the clock frequency could > > > be set dynamically. > > > > I've never worked with Exynos or imx8, but my view would be that > > samsung,burst-clock-frequency should only be used if > > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for > > adv7533/5). > > Some notes on that. The samsung,burst-clock-frequency is the > hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to > do with the MIPI_DSI_MODE_VIDEO_BURST. > > > Without that flag the DSI link frequency should be running at the rate > > defined by the mode clock, number of lanes, bpp, etc. > > IMHO the DSI link have only to guarantee the bandwidth is sufficient for > the mode. DSI spec 8.11.3 Non-Burst Mode with Sync Events "This mode is a simplification of the format described in Section 8.11.2 (Non-Burst Mode with Sync Pulses) ... Pixels are transmitted at the same rate as they would in a corresponding parallel display interface such as DPI-2." If you are running the DSI clock at anything other than that rate, then AIUI you are in a burst mode (although you may choose not to drop into LP mode). (One of my pet peeves that there is no documentation as to exactly what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI spec all modes of 8.11 say that the host can drop to LP during blanking if time allows, it surely has to be the time compression element of 8.11.4 Burst Mode). > > From the DSI spec (v 1.1 section 8.11.1): > > "Non-Burst Mode with Sync Pulses – enables the peripheral to > > accurately reconstruct original video timing, including sync pulse > > widths." > > "RGB pixel packets are time-compressed, leaving more time during a > > scan line for LP mode (saving power) or for multiplexing other > > transmissions onto the DSI link." > > How can the peripheral reconstruct the video timing off a quirky link > > frequency? > > If the ADV couldn't reconstruct the sync signals, then we should not get > any mode working but we get the 1080P mode working. > > > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1] > > reconfigures the clock setup of the DSI block, then I don't see how > > the Exynos driver can follow the DSI spec in that regard. > > Why do you think that the Exynos driver isn't following the spec? We > configure the host into video mode with sync signals which is working > for the 1080P mode. 1080p is working with samsung,burst-clock-frequency setting? As I say, I've not worked with this IP, I'm only looking at it from the outside having spent far too much time recently on the Pi DSI interface. exynos_drm_dsi.c seems to be doing a lot of PLL computation around burst-clock-frequency, and nothing with the pixel clock rate. Without knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG actually does in the hardware, I can only make guesses. Perhaps it does ditch the burst clock and switch the bit clock to be derived from the pixel clock of the upstream block, but that seems unlikely. Dave
Re: New subsystem for acceleration devices
On 04/08/2022 00:54, Dave Airlie wrote: On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: On Sun, 31 Jul 2022 at 22:04, Oded Gabbay wrote: Hi, Greg and I talked a couple of months ago about preparing a new accel subsystem for compute/acceleration devices that are not GPUs and I think your drivers that you are now trying to upstream fit it as well. We've had some submissions for not-GPUs to the drm subsystem recently. Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. why is creating a new subsystem at this time necessary? Are we just creating a subsystem to avoid the open source userspace consumer rules? Or do we have some concrete reasoning behind it? Dave. Hi Dave. The reason it happened now is because I saw two drivers, which are doing h/w acceleration for AI, trying to be accepted to the misc subsystem. Add to that the fact I talked with Greg a couple of months ago about doing a subsystem for any compute accelerators, which he was positive about, I thought it is a good opportunity to finally do it. I also honestly think that I can contribute much to these drivers from my experience with the habana driver (which is now deployed in mass at AWS) and contribute code from the habana driver to a common framework for AI drivers. Why not port the habana driver to drm now instead? I don't get why it wouldn't make sense? Stepping up to create a new subsystem is great, but we need rules around what belongs where, we can't just spawn new subsystems when we have no clear guidelines on where drivers should land. What are the rules for a new accel subsystem? Do we have to now retarget the 3 drivers that are queued up to use drm for accelerators, because 2 drivers don't? Isn't there three on the "don't prefer drm" side as well? Habana, Toshiba and Samsung? Just so the numbers argument is not misrepresented. Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't care in principle; is in order? More to the point, code sharing is a very compelling argument if it can be demonstrated to be significant, aka not needing to reinvent the same wheel. Perhaps one route forward could be a) to consider is to rename DRM to something more appropriate, removing rendering from the name and replacing with accelerators, co-processors, I don't know... Although I am not sure renaming the codebase, character device node names and userspace headers is all that feasible. Thought to mention it nevertheless, maybe it gives an idea to someone how it could be done. And b) allow the userspace rules to be considered per driver, or per class (is it a gpu or not should be a question that can be answered). Shouldn't be a blocker if it still matches the rules present elsewhere in the kernel. Those two would remove the two most contentions points as far as I understood the thread. Regards, Tvrtko There's a lot more to figure out here than merge some structures and it will be fine. I think the one area I can see a divide where a new subsystem is for accelerators that are single-user, one shot type things like media drivers (though maybe they could be just media drivers). I think anything that does command offloading to firmware or queues belongs in drm, because that is pretty much what the framework does. I think it might make sense to enhance some parts of drm to fit things in better, but that shouldn't block things getting started. I'm considering if, we should add an accelerator staging area to drm and land the 2-3 submissions we have and try and steer things towards commonality that way instead of holding them out of tree. I'd like to offload things from Greg by just not having people submit misc drivers at all for things that should go elsewhere. Dave. Regarding the open source userspace rules in drm - yes, I think your rules are too limiting for the relatively young AI scene, and I saw at the 2021 kernel summit that other people from the kernel community think that as well. But that's not the main reason, or even a reason at all for doing this. After all, at least for habana, we open-sourced our compiler and a runtime library. And Greg also asked those two drivers if they have matching open-sourced user-space code. And a final reason is that I thought this can also help in somewhat reducing the workload on Greg. I saw in the last kernel summit there was a concern about bringing more people to be kernel maintainers so I thought this is a step in the right direction. Oded
Re: [RFC PATCH 1/2] drm/panel-edp: Allow overriding the eDP EDID
On Fri, 29 Jul 2022, Doug Anderson wrote:
> Hi,
>
> On Thu, Jul 21, 2022 at 4:36 AM Dmitry Baryshkov
> wrote:
>>
>> On Thu, 21 Jul 2022 at 01:55, Douglas Anderson wrote:
>> >
>> > I found that writing to `/sys/kernel/debug/dri/*/eDP*/edid_override`
>> > wasn't working for me. I could see the new EDID take effect in
>> > `/sys/class/drm/card*-eDP*/edid` but userspace wasn't seeing it..
>> >
>> > The problem was that panel-edp was caching the EDID that it read and
>> > using that over and over again.
>> >
>> > Let's change panel-edp to look at the EDID that's stored in the
>> > connector. This is still a cache, which is important since this
>> > function is called multiple times and readin the EDID is slow, but
>> > this property is automatically updated by drm_get_edid() (which reads
>> > the EDID) and also updated when writing the edid_override in debugfs.
>> >
>> > Fixes: 63358e24ee79 ("drm/panel: panel-simple: Cache the EDID as long as
>> > we retain power")
>> > Signed-off-by: Douglas Anderson
>>
>> A different proposal for you to consider:
>> Change drm_get_edid/drm_do_get_edid to return int rather than struct
>> edid, while caching the EDID in the connector. Or maybe add a new API
>> drm_read_edid() and make drm_get_edid() deprecated in favour of it.
>> The goal should be to let all drivers use connector-cached EDID rather
>> than getting the EDID, parsing it and kfree()ing it immediately
>> afterwards.
>
> I think the majority of drivers don't actually want the cached EDID
> behavior so the edp-panel case is actually pretty rare. For everyone
> else I think DRM is handling things in a pretty reasonable way.
> Looking closely, it looks like there have been a bunch of patches
> landed in this area recently and so I assume people are happy enough
> with the current design for the majority of cases.
>
> I guess your point though, is that the way I'm using the API right now
> in ${SUBJECT} patch is a bit gross and maybe the DRM core needs a
> helper of some sort for this case? Essentially what we're saying is
> that we have inside knowledge this is a built-in panel and thus the
> EDID will never change and it's a waste of time to read it again and
> again. We could somehow tell the DRM core that.
>
> I guess I could add a function like drm_edid_read_if_needed(). That
> would essentially use the existing blob if it was there and read it
> otherwise. Does that work? Basically:
>
> def drm_edid_read_if_needed(...):
> if (connector->edid_blob_ptr)
> return dupe_edid(connector->edid_blob_ptr);
> return drm_edid_read(...);
>
> I guess maybe we'd want a _ddc variant too.
>
> Adding Jani since the recent patches I see touching this were his and
> there are even comments there about what to do about drivers that want
> to cache the EDID.
>
>
>> Most probably we should be able to move
>> drm_connector_update_edid_property() into drm_do_get_edid() and drop
>> it from the rest of the code. This might require additional thought
>> about locking, to ensure that nobody pulls the cached edid out from
>> under our feet.
>
> This all looks like it's moving now, actually. Looking around at
> recent changes, I see that now the property gets updated in a
> different call.
>
> Old (deprecated)
> 1. drm_get_edid() <-- Updates the EDID property
> 2. drm_add_edid_modes()
>
> New:
> 1. drm_edid_read()
> 2. drm_edid_connector_update() <-- Updates the EDID property
>
>
> > Extra "bonus" points to consider:
>> - Maybe it's time to add get_edid() to the drm_panel interface, teach
>> panel_bridge about it and let drm_bridge_connector handle all the
>> details?
>>
>> So, while this looks like a longer path, I think it's worth checking
>> that we can refactor this piece of code.
>
> It's certainly interesting to consider. At the moment, though, it
> doesn't look super easy to do. Points to note:
>
> 1. We don't necessarily want to cache the EDID for all display types.
> For builtin panels it makes sense to do so, but it's less obvious for
> external displays. _In theory_ we could try to cache the EDID for
> external devices if we're really certain that we'll notice when
> they're unplugged / re-plugged again but I'm not convinced that all
> drivers always handle this. In any case, I tend to assume that when
> we're dealing with external displays we're a little less interested in
> trying to optimize all of the milliseconds away. If nothing else there
> are hundreds of milliseconds of hotplug detect debounce happening for
> external displays. Yes, we could have a rule about only caching the
> EDID only for eDP displays but then the motivation of moving it out of
> edp-panel and to drm_bridge_connector is a lot less.
>
> 2. At the moment, drm_bridge_connector only calls get_modes() if it
> doesn't have get_edid() implemented. At the moment the panel-edp code
> actually _combines_ the EDID and any hardcoded modes that were
> specified. I think we'd have to resolve this difference if we do what
> you suggest. The panel-edp beh
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Marco On Thu, 4 Aug 2022 at 10:38, Marco Felsch wrote: > > Hi Dave, Adam, > > On 22-08-03, Dave Stevenson wrote: > > Hi Adam > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: > > ... > > > > > Did managed to get access to the ADV7535 programming guide? This is the > > > > black box here. Let me check if I can provide you a link with our repo > > > > so you can test our current DSIM state if you want. > > > > > > I do have access to the programming guide, but it's under NDA, but > > > I'll try to answer questions if I can. > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > from previously looking at these chips. > > Thanks for stepping into :) > > > Mine fairly plainly states: > > "The DSI receiver input supports DSI video mode operation only, and > > specifically, only supports nonburst mode with sync pulses". > > I've read this also, and we are working in nonburst mode with sync > pulses. I have no access to an MIPI-DSI analyzer therefore I can't > verify it. > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > HDMI pixel rate. > > On DSI side you don't have a pixel-clock instead there is bit-clock. You have an effective pixel clock, with a fixed conversion for the configuration. DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s As noted elsewhere, the DSI is DDR, so the clock lane itself is only running at 891 / 2 = 445.5MHz. > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > > even more explicit about the requirement of DSI timing matching > > Is it possible to share the key points of the requirements? "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This mode requires real time data generation as a pulse packet received becomes a pulse generated. Therefore this mode requires a continuous stream of data with correct video timing to avoid any visual artifacts." LP mode is supported on data lanes. Clock lane must remain in HS mode. "... the goal is to accurately convey DPI-type timing over DSI. This includes matching DPI pixel-transmission rates, and widths of timing events." > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > > be correct for 720p operation. > > It should be absolute no difference if you work on 891MHz with 2 lanes > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 > GBps. Has someone changed the number of lanes in use? I'd missed that if so, but I'll agree that 891MHz over 2 lanes should work for 720p60. I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one of the modes that is mandatory to use the timing generator (reg 0x27 bit 7 = 1). On 2 lanes it is not required. I don't know why it's referencing the 1000/1001 pixel clock rates and not the base one, as it's only a base clock change with the same timing (74.176MHz clock instead of 74.25MHz). > > If you do program the manual DSI divider register to allow a DSI pixel > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on > > There is no such DSI pixel rate to be precise, we only have a DSI bit > clock/rate. > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI > > tx to compensate for the differing data rates. I see no reference to > > such, and I'd be surprised if it was more than a half dozen pixels to > > compensate for the jitter in the cases where the internal timing > > generator is mandatory due to fractional bytes. > > This is interesting and would proofs our assumption that the device > don't have a FIFO :) > > Our assumptions (we don't have the datasheet/programming manual): > - HDMI part is fetching 3 bytes per HDMI pixclk > - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and > HDMI are in sync. So from bandwidth pov there are no differences > between: > - HDMI: 74.25 MHz * 24 Bit = 1782.0 MBit/s > - DSI:891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 ) > - DSI: 445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75) > > But the ratio is different and therefore the faster clocking option > let something 'overflow'. I'll agree that all looks consistent. > Anyway, but all this means that Adam should configure the > burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work > either and now we are back on my initial statement -> the driver needs > some attention. Things always need attention :-) I suspect that it's the use of the timing generator that is the issue. The programming guide does recommend using it for all modes, so that would be a sensible first step. I will say that we had a number of issues getting this chip to do anything, and it generally seemed happier on 2 or 3 lanes instead of 4. Suffice to say that we abandoned trying to use it, despite some assistance from ADI. Dave
[v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 40 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 3 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 7 +
6 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7763558..4eca317 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -703,6 +703,10 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc
*crtc)
mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
mixer[i].hw_dspp->idx);
+ if(ctl->ops.set_dspp_hierarchical_flush)
+ ctl->ops.set_dspp_hierarchical_flush(ctl,
+ mixer[i].hw_dspp->idx,
DSPP_SUB_PCC);
+
/* stage config flush mask */
ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 021eb2f..3b27a87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -58,7 +58,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_HIERARCHICAL_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index b85b24b..7922f6c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -185,6 +185,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_HIERARCHICAL_FLUSH: CTL config to support hierarchical flush
* @DPU_CTL_MAX
*/
enum {
@@ -192,6 +193,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_HIERARCHICAL_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 3584f5e..b34fc30 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -28,6 +28,8 @@
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_0_FLUSH 0x13C
+
#define CTL_MIXER_BORDER_OUTBIT(24)
#define CTL_FLUSH_MASK_CTL BIT(17)
@@ -292,6 +294,36 @@ static uint32_t dpu_hw_ctl_get_bitmask_dspp(struct
dpu_hw_ctl *ctx,
return flushbits;
}
+static uint32_t dpu_hw_ctl_get_bitmask_dspp_v1(struct dpu_hw_ctl *ctx,
+ enum dpu_dspp dspp)
+{
+ return BIT(29);
+}
+
+static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
+ enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
+{
+ uint32_t flushbits = 0, active = 0;
+
+ switch (dspp_sub_blk) {
+ case DSPP_SUB_IGC:
+ flushbits = BIT(2);
+ break;
+ case DSPP_SUB_PCC:
+ flushbits = BIT(4);
+ break;
+ case DSPP_SUB_GC:
+ flushbits = BIT(5);
+ break;
+ default:
+ return;
+ }
+
+ active = DPU_REG_READ(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4));
+
+ DPU_REG_WRITE(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4), active |
flushbits);
+}
+
static u32 dpu_hw_ctl_poll_reset_status(struct dpu_hw_ctl *ctx, u32 timeout_us)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -600,7 +632,13 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->setup_blendstage = dpu_hw_ctl_setup_blendstage;
ops->get_bitmask_sspp = dpu_hw_ctl_get_bitmask_sspp;
ops->get_bitmask_mixer = dpu_hw_ctl_get_bitmask_mixer;
- ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp;
+ if (cap & BIT(DPU_CTL_HIERARCHICAL_FLUSH)) {
+ ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp_v1;
+ ops->set_dspp_hierarchical_flush =
dpu_hw_ctl_set
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On 22-08-03, Dave Stevenson wrote: > On Wed, 3 Aug 2022 at 13:31, Adam Ford wrote: ... > > Mine also states the DSI source needs to provide correct video timing > > with start and stop sync packets. > > > > If I remember correctly, it seemed like Marek V wanted the hard coded > > samsung,burst-clock-frequency to go away so the clock frequency could > > be set dynamically. > > I've never worked with Exynos or imx8, but my view would be that > samsung,burst-clock-frequency should only be used if > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for > adv7533/5). Some notes on that. The samsung,burst-clock-frequency is the hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to do with the MIPI_DSI_MODE_VIDEO_BURST. > Without that flag the DSI link frequency should be running at the rate > defined by the mode clock, number of lanes, bpp, etc. IMHO the DSI link have only to guarantee the bandwidth is sufficient for the mode. > From the DSI spec (v 1.1 section 8.11.1): > "Non-Burst Mode with Sync Pulses – enables the peripheral to > accurately reconstruct original video timing, including sync pulse > widths." > "RGB pixel packets are time-compressed, leaving more time during a > scan line for LP mode (saving power) or for multiplexing other > transmissions onto the DSI link." > How can the peripheral reconstruct the video timing off a quirky link > frequency? If the ADV couldn't reconstruct the sync signals, then we should not get any mode working but we get the 1080P mode working. > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1] > reconfigures the clock setup of the DSI block, then I don't see how > the Exynos driver can follow the DSI spec in that regard. Why do you think that the Exynos driver isn't following the spec? We configure the host into video mode with sync signals which is working for the 1080P mode. Regards, Marco
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On 22-08-03, Adam Ford wrote: > On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson ... > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > > from previously looking at these chips. > > Thanks for the feedback. > > > Mine fairly plainly states: > > "The DSI receiver input supports DSI video mode operation only, and > > specifically, only supports nonburst mode with sync pulses". > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > > HDMI pixel rate. > > Mine also states the DSI source needs to provide correct video timing > with start and stop sync packets. > > If I remember correctly, it seemed like Marek V wanted the hard coded > samsung,burst-clock-frequency to go away so the clock frequency could > be set dynamically. As previously said, this is something on our TODO list too :) but needs a bit more infrastructure work. > I have attempted to do some of this work based on what I am seeing in > the NXP kernel, and I get get my monitor to sync at some resolutions, > but the screen is usually all green or all blue, so it's not really a > success. The clock part appears to be good enough to make the monitor > see some sort of signal, so I am going to investigate the calculation > of the rest of the video timings to see if I can fix the color issue. Please don't pay to much attention to the NXP kernel. No one have a glue where those porches came from. If I specify the burst-clock-freq. to 445.5 and set the lane number to 4 and hack in the porches values from NXP, than I get a 720P output too. But this isn't the way to go instead we should calc the porches settings and the burst-clock-frequency dynamiclly to provide more than just a few resolutions. But for that we need a clear understanding of how the ADV is working. I will prepare a repo to day and will send you a link with the hack patches in it, so you can test it :) Regards, Marco
Re: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function
On Tue, 19 Jul 2022, Jouni Högander wrote:
> Luminance range calculation was split out into drm_edid.c and is now
> part of edid parsing. Rely on values calculated during edid parsing and
> use these for caps->aux_max_input_signal and caps->aux_min_input_signal.
Harry, I'll merge patches 1 & 3 in this series through drm-misc-next,
because I think they're good to go, and fix stuff in i915.
Can I get your rb/ack to merge this patch as well, or do you want to
take this later via your tree?
BR,
Jani.
>
> v2: Use values calculated during edid parsing
>
> Cc: Roman Li
> Cc: Rodrigo Siqueira
> Cc: Harry Wentland
> Cc: Lyude Paul
> Cc: Mika Kahola
> Cc: Jani Nikula
> Cc: Manasi Navare
> Signed-off-by: Jouni Högander
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
> 1 file changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3e83fed540e8..eb7abdeb8653 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs
> amdgpu_dm_mode_config_helperfuncs = {
>
> static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
> {
> - u32 max_avg, min_cll, max, min, q, r;
> struct amdgpu_dm_backlight_caps *caps;
> struct amdgpu_display_manager *dm;
> struct drm_connector *conn_base;
> struct amdgpu_device *adev;
> struct dc_link *link = NULL;
> - static const u8 pre_computed_values[] = {
> - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> + struct drm_luminance_range_info *luminance_range;
> int i;
>
> if (!aconnector || !aconnector->dc_link)
> @@ -2933,8 +2930,6 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> caps = &dm->backlight_caps[i];
> caps->ext_caps = &aconnector->dc_link->dpcd_sink_ext_caps;
> caps->aux_support = false;
> - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
>
> if (caps->ext_caps->bits.oled == 1 /*||
> caps->ext_caps->bits.sdr_aux_backlight_control == 1 ||
> @@ -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> else if (amdgpu_backlight == 1)
> caps->aux_support = true;
>
> - /* From the specification (CTA-861-G), for calculating the maximum
> - * luminance we need to use:
> - * Luminance = 50*2**(CV/32)
> - * Where CV is a one-byte value.
> - * For calculating this expression we may need float point precision;
> - * to avoid this complexity level, we take advantage that CV is divided
> - * by a constant. From the Euclids division algorithm, we know that CV
> - * can be written as: CV = 32*q + r. Next, we replace CV in the
> - * Luminance expression and get 50*(2**q)*(2**(r/32)), hence we just
> - * need to pre-compute the value of r/32. For pre-computing the values
> - * We just used the following Ruby line:
> - * (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> - * The results of the above expressions can be verified at
> - * pre_computed_values.
> - */
> - q = max_avg >> 5;
> - r = max_avg % 32;
> - max = (1 << q) * pre_computed_values[r];
> -
> - // min luminance: maxLum * (CV/255)^2 / 100
> - q = DIV_ROUND_CLOSEST(min_cll, 255);
> - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> -
> - caps->aux_max_input_signal = max;
> - caps->aux_min_input_signal = min;
> + luminance_range = &conn_base->display_info.luminance_range;
> + caps->aux_min_input_signal = luminance_range->min_luminance;
> + caps->aux_max_input_signal = luminance_range->max_luminance;
> }
>
> void amdgpu_dm_update_connector_after_detect(
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support
Pavel Machek 於 2022年7月31日 週日 清晨5:42寫道： > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Copyright (C) 2022 Richtek Technology Corp. > > + * > > + * Author: Alice Chen > Add ">" at end of line. > > The series is quite big, would it be possible to submit LED changes > in separate series? > Hi Pavel, Our mfd dt-bindings depends on flash and LED dt-bindings, but our flash and LED config depend on mfd config. For the dependency consideration, we think submitting them in a patch series is better. Best Regards, Alice
Re: [PATCH] drm: fix whitespace in drm_plane_create_color_properties()
On Wed, 03 Aug 2022, Simon Ser wrote: > The drm_property_create_enum() call for "COLOR_RANGE" contains a tab > character in the middle of the argument list. > > Signed-off-by: Simon Ser Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_color_mgmt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c > b/drivers/gpu/drm/drm_color_mgmt.c > index 17c6c3eefcd6..d021497841b8 100644 > --- a/drivers/gpu/drm/drm_color_mgmt.c > +++ b/drivers/gpu/drm/drm_color_mgmt.c > @@ -575,7 +575,7 @@ int drm_plane_create_color_properties(struct drm_plane > *plane, > len++; > } > > - prop = drm_property_create_enum(dev, 0, "COLOR_RANGE", > + prop = drm_property_create_enum(dev, 0, "COLOR_RANGE", > enum_list, len); > if (!prop) > return -ENOMEM; -- Jani Nikula, Intel Open Source Graphics Center
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Dave, Adam, On 22-08-03, Dave Stevenson wrote: > Hi Adam > > On Wed, 3 Aug 2022 at 12:03, Adam Ford wrote: ... > > > Did managed to get access to the ADV7535 programming guide? This is the > > > black box here. Let me check if I can provide you a link with our repo > > > so you can test our current DSIM state if you want. > > > > I do have access to the programming guide, but it's under NDA, but > > I'll try to answer questions if I can. > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535 > from previously looking at these chips. Thanks for stepping into :) > Mine fairly plainly states: > "The DSI receiver input supports DSI video mode operation only, and > specifically, only supports nonburst mode with sync pulses". I've read this also, and we are working in nonburst mode with sync pulses. I have no access to an MIPI-DSI analyzer therefore I can't verify it. > Non-burst mode meaning that the DSI pixel rate MUST be the same as the > HDMI pixel rate. On DSI side you don't have a pixel-clock instead there is bit-clock. > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is > even more explicit about the requirement of DSI timing matching Is it possible to share the key points of the requirements? > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore > be correct for 720p operation. It should be absolute no difference if you work on 891MHz with 2 lanes or on 445.5 MHz with 4 lanes. What must be ensured is that you need the minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327 GBps. > If you do program the manual DSI divider register to allow a DSI pixel > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on There is no such DSI pixel rate to be precise, we only have a DSI bit clock/rate. > the ADV753x having at least a half-line FIFO between DSI rx and HDMI > tx to compensate for the differing data rates. I see no reference to > such, and I'd be surprised if it was more than a half dozen pixels to > compensate for the jitter in the cases where the internal timing > generator is mandatory due to fractional bytes. This is interesting and would proofs our assumption that the device don't have a FIFO :) Our assumptions (we don't have the datasheet/programming manual): - HDMI part is fetching 3 bytes per HDMI pixclk - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and HDMI are in sync. So from bandwidth pov there are no differences between: - HDMI: 74.25 MHz * 24 Bit = 1782.0 MBit/s - DSI:891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 ) - DSI: 445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75) But the ratio is different and therefore the faster clocking option let something 'overflow'. Anyway, but all this means that Adam should configure the burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work either and now we are back on my initial statement -> the driver needs some attention. Regards, Marco
Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values
On 04. 08. 22, 10:44, Helge Deller wrote: On 8/4/22 09:15, Helge Deller wrote: Hello Jiri, Thanks for looking into this patch! On 8/4/22 07:47, Jiri Slaby wrote: On 30. 07. 22, 20:49, Helge Deller wrote: The line and column numbers for the selection need to start at 1. Add the checks to prevent invalid input. Signed-off-by: Helge Deller Reported-by: syzbot+14b0e8f3fd1612e35...@syzkaller.appspotmail.com diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index f7755e73696e..58692a9b4097 100644 --- a/drivers/tty/vt/selection.c +++ b/drivers/tty/vt/selection.c @@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, struct tiocl_selection *v, return 0; } + if (!v->xs || !v->ys || !v->xe || !v->ye) + return -EINVAL; Hmm, I'm not sure about this. It potentially breaks userspace (by returning EINVAL now). Right. According to the code below, my interpretation is that all xs/ys/xe/ye values should be > 0. But of course I might be wrong on this, as I didn't find any documentation for TIOCL_SETSEL. And if userspace tries to set an invalid selection (e.g. by selecting row 0), my patch now returns -EINVAL, while it returned success before. And the code below should handle this just fine, right: v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1); v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1); v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1); It "handles it fine" in the sense that it can cope with the input and will not crash. But it returns (maybe?) unexpected results... After some more thinking maybe you are right. In case a user provided invalid values in the past, simply an unexpected selection was set, but nothing broke. Since the patch doesn't fix any critical issue, we could just drop this patch and leave it as is. We can still do a trial and revert it if something breaks... It's just that _noone_ knows with all this undocumented stuff ;). But in fact, 0 currently means full row/column. Isn't it on purpose? Today, we are out of luck, codesearch.debian.net gives no clue about users: https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb&literal=0 thanks, -- js suse labs
Re: [Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header
Hi Jani, > >> It moves overflows_type utility macro into drm util header from i915_utils > >> header. The overflows_type can be used to catch the truncation between data > >> types. And it adds safe_conversion() macro which performs a type conversion > >> (cast) of an source value into a new variable, checking that the > >> destination is large enough to hold the source value. > >> And it adds exact_type and exactly_pgoff_t macro to catch type mis-match > >> while compiling. > >> > >> v3: Add is_type_unsigned() macro (Mauro) > >> Modify overflows_type() macro to consider signed data types (Mauro) > >> Fix the problem that safe_conversion() macro always returns true > >> v4: Fix kernel-doc markups > >> > >> Signed-off-by: Gwan-gyeong Mun > >> Cc: Thomas Hellström > >> Cc: Matthew Auld > >> Cc: Nirmoy Das > >> Cc: Jani Nikula > >> Reviewed-by: Mauro Carvalho Chehab > >> --- > >> drivers/gpu/drm/i915/i915_utils.h | 5 +- > >> include/drm/drm_util.h| 77 +++ > >> 2 files changed, 78 insertions(+), 4 deletions(-) > > > > Jani and Mauro suggested to have this macro in > > include/drm/drm_util.h. > > I can't recall suggesting such a thing. The macros in question have > nothing specifically to do with i915 *or* drm. They are generic, and > should be in generic kernel headers. > > We must stop piling up generic and generally useful stuff in our own > headers. Yes, I agree with you and I think there was already such discussion whether to move this into generic kernel headers or in drm header. Gwan-gyeong, any thoughts or further plans to move this to a different place? It's been already three people (and I'm including myself here) recommending to have this in a different place. Andi > I thought I've been clear about this all along. Thanks, Jani! Andi
[PATCH v4 6/6] drm/ttm: Switch to using the new res callback
Apply new intersect and compatible callback instead
of having a generic placement range verfications.
v2: Added a separate callback for compatiblilty
checks (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 45 +++--
drivers/gpu/drm/ttm/ttm_bo.c| 9 +++--
drivers/gpu/drm/ttm/ttm_resource.c | 5 +--
3 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 170935c294f5..7d25a10395c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,11 +1328,12 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
- unsigned long num_pages = bo->resource->num_pages;
struct dma_resv_iter resv_cursor;
- struct amdgpu_res_cursor cursor;
struct dma_fence *f;
+ if (!amdgpu_bo_is_amdgpu_bo(bo))
+ return ttm_bo_eviction_valuable(bo, place);
+
/* Swapout? */
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -1351,40 +1352,20 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
return false;
}
- switch (bo->resource->mem_type) {
- case AMDGPU_PL_PREEMPT:
- /* Preemptible BOs don't own system resources managed by the
-* driver (pages, VRAM, GART space). They point to resources
-* owned by someone else (e.g. pageable memory in user mode
-* or a DMABuf). They are used in a preemptible context so we
-* can guarantee no deadlocks and good QoS in case of MMU
-* notifiers or DMABuf move notifiers from the resource owner.
-*/
+ /* Preemptible BOs don't own system resources managed by the
+* driver (pages, VRAM, GART space). They point to resources
+* owned by someone else (e.g. pageable memory in user mode
+* or a DMABuf). They are used in a preemptible context so we
+* can guarantee no deadlocks and good QoS in case of MMU
+* notifiers or DMABuf move notifiers from the resource owner.
+*/
+ if (bo->resource->mem_type == AMDGPU_PL_PREEMPT)
return false;
- case TTM_PL_TT:
- if (amdgpu_bo_is_amdgpu_bo(bo) &&
- amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
- return false;
- return true;
- case TTM_PL_VRAM:
- /* Check each drm MM node individually */
- amdgpu_res_first(bo->resource, 0, (u64)num_pages << PAGE_SHIFT,
-&cursor);
- while (cursor.remaining) {
- if (place->fpfn < PFN_DOWN(cursor.start + cursor.size)
- && !(place->lpfn &&
-place->lpfn <= PFN_DOWN(cursor.start)))
- return true;
-
- amdgpu_res_next(&cursor, cursor.size);
- }
+ if (bo->resource->mem_type == TTM_PL_TT &&
+ amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
return false;
- default:
- break;
- }
-
return ttm_bo_eviction_valuable(bo, place);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1bd006a5525..f066e8124c50 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ struct ttm_resource *res = bo->resource;
+ struct ttm_device *bdev = bo->bdev;
+
dma_resv_assert_held(bo->base.resv);
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
/* Don't evict this BO if it's outside of the
* requested placement range
*/
- if (place->fpfn >= (bo->resource->start + bo->resource->num_pages) ||
- (place->lpfn && place->lpfn <= bo->resource->start))
- return false;
-
- return true;
+ return ttm_resource_intersects(bdev, res, place, bo->base.size);
}
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 357249630c37..3d70e0f50a88 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -316,6 +316,8 @@ static bool ttm_resource_places_compat(struct ttm_resource
*res,
