Re: [PATCH v2 3/4] drm/mediatek: dsi: Use bitfield macros where useful
Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc6
next-20231222]
[cannot apply to drm-intel/for-linux-next]
[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/AngeloGioacchino-Del-Regno/drm-mediatek-dsi-Use-GENMASK-for-register-mask-definitions/20231222-164513
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231220135722.192080-4-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v2 3/4] drm/mediatek: dsi: Use bitfield macros where
useful
config: arm-allmodconfig
(https://download.01.org/0day-ci/archive/20231223/202312231512.ioid48la-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231223/202312231512.ioid48la-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202312231512.ioid48la-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/mediatek/mtk_dsi.c: In function 'mtk_dsi_phy_timconfig':
>> drivers/gpu/drm/mediatek/mtk_dsi.c:260:19: error: implicit declaration of
>> function 'FIELD_PREP' [-Werror=implicit-function-declaration]
260 | timcon0 = FIELD_PREP(LPX, timing->lpx) |
| ^~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +260 drivers/gpu/drm/mediatek/mtk_dsi.c
236
237 static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
238 {
239 u32 timcon0, timcon1, timcon2, timcon3;
240 u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, 100);
241 struct mtk_phy_timing *timing = >phy_timing;
242
243 timing->lpx = (60 * data_rate_mhz / (8 * 1000)) + 1;
244 timing->da_hs_prepare = (80 * data_rate_mhz + 4 * 1000) / 8000;
245 timing->da_hs_zero = (170 * data_rate_mhz + 10 * 1000) / 8000 +
1 -
246 timing->da_hs_prepare;
247 timing->da_hs_trail = timing->da_hs_prepare + 1;
248
249 timing->ta_go = 4 * timing->lpx - 2;
250 timing->ta_sure = timing->lpx + 2;
251 timing->ta_get = 4 * timing->lpx;
252 timing->da_hs_exit = 2 * timing->lpx + 1;
253
254 timing->clk_hs_prepare = 70 * data_rate_mhz / (8 * 1000);
255 timing->clk_hs_post = timing->clk_hs_prepare + 8;
256 timing->clk_hs_trail = timing->clk_hs_prepare;
257 timing->clk_hs_zero = timing->clk_hs_trail * 4;
258 timing->clk_hs_exit = 2 * timing->clk_hs_trail;
259
> 260 timcon0 = FIELD_PREP(LPX, timing->lpx) |
261FIELD_PREP(HS_PREP, timing->da_hs_prepare) |
262FIELD_PREP(HS_ZERO, timing->da_hs_zero) |
263FIELD_PREP(HS_TRAIL, timing->da_hs_trail);
264
265 timcon1 = FIELD_PREP(TA_GO, timing->ta_go) |
266FIELD_PREP(TA_SURE, timing->ta_sure) |
267FIELD_PREP(TA_GET, timing->ta_get) |
268FIELD_PREP(DA_HS_EXIT, timing->da_hs_exit);
269
270 timcon2 = FIELD_PREP(DA_HS_SYNC, 1) |
271FIELD_PREP(CLK_ZERO, timing->clk_hs_zero) |
272FIELD_PREP(CLK_TRAIL, timing->clk_hs_trail);
273
274 timcon3 = FIELD_PREP(CLK_HS_PREP, timing->clk_hs_prepare) |
275FIELD_PREP(CLK_HS_POST, timing->clk_hs_post) |
276FIELD_PREP(CLK_HS_EXIT, timing->clk_hs_exit);
277
278 writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
279 writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
280 writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
281 writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
282 }
283
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 07/11] nouveau/gsp: convert gsp errors to generic errors
On Thu, Dec 21, 2023, 10:33 PM Dave Airlie wrote:
> This should let the upper layers retry as needed on EAGAIN.
>
> There may be other values we will care about in the future, but
> this covers our present needs.
>
> Signed-off-by: Dave Airlie
>
> +static int
> +r535_rpc_status_to_errno(uint32_t rpc_status)
> +{
> + switch (rpc_status) {
> + case 0x55: /* NV_ERR_NOT_READY */
> + case 0x66: /* NV_ERR_TIMEOUT_RETRY */
> + return -EAGAIN;
> + case 0x51: /* NV_ERR_NO_MEMORY */
> + return -ENOMEM;
> + default:
> + return -EINVAL;
> + }
>
Shouldn't you also have this:
case 0:
return 0;
OOM in kdump kernel caused by commit b5bad8c16b9b
Hi David,
Recently, Redhat CKI reported a kdump kernel bootup failure caused by
OOM. After bisect, it only happened after commit b5bad8c16b9b
("nouveau/gsp: move to 535.113.01"). Reverting the commit can avoid the
OOM, kdump kernel can boot up successfully.
>From debugging, we can see that about extra 100M memory will be costed
when commit b5bad8c16b9b applied on the hpe machine with 2G memory.
Do you know if there's room to improve that to reduce the extra memory
cost?
I have opened a fedora bug to track this OOM, and copy the bug
description here for reference in case someone may not access the bug
easily.
Bug 2253165 - kdump kernel failed to boot up because a big memory chunk is
reserved
https://bugzilla.redhat.com/show_bug.cgi?id=2253165
CKI reported a failure on beaker machine hp-z210-01.ml3.eng.bos.redhat.com,
please see below CKI reports:
https://datawarehouse.cki-project.org/kcidb/tests/10508330
In that failure, crashkernel=256M and succeeded to reserve in 1st kernel.
However, in
kdump kernel it failed to boot up when it started to run init process. I set
crashkernel=320M to make kdump kernel boot up successfully and vmcore dumping
succeeded too.
After adding "rd.memdebug=4 memblock=debug" to kdump kernel cmdline, it appears
to have a big chunk of reserved memory in memblock of about 122M. I don't know
where it comes from. I doubt firmware stole that chunk from system memory to
cause the kdump kernel having oom.
[Tue Dec 5 22:32:38 2023] DMI: Hewlett-Packard HP Z210 Workstation/1587h, BIOS
J51 v01.20 09/16/2011
[Tue Dec 5 22:32:38 2023] tsc: Fast TSC calibration using PIT
[Tue Dec 5 22:32:38 2023] tsc: Detected 3092.940 MHz processor
[Tue Dec 5 22:32:38 2023] e820: update [mem 0x-0x0fff] usable ==>
reserved
[Tue Dec 5 22:32:38 2023] e820: remove [mem 0x000a-0x000f] usable
[Tue Dec 5 22:32:38 2023] last_pfn = 0x61000 max_arch_pfn = 0x4
[Tue Dec 5 22:32:38 2023] MTRR map: 4 entries (3 fixed + 1 variable; max 23),
built from 10 variable MTRRs
[Tue Dec 5 22:32:38 2023] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP
UC- WT
[Tue Dec 5 22:32:38 2023] x2apic: enabled by BIOS, switching to x2apic ops
[Tue Dec 5 22:32:38 2023] found SMP MP-table at [mem 0x000f4b80-0x000f4b8f]
[Tue Dec 5 22:32:38 2023] memblock_reserve:
[0x000f4b80-0x000f4b8f] smp_scan_config+0xca/0x150
[Tue Dec 5 22:32:38 2023] memblock_reserve:
[0x000f4b90-0x000f4e4b] smp_scan_config+0x13a/0x150
[Tue Dec 5 22:32:38 2023] memblock_reserve:
[0x5f60-0x5f610fff] setup_arch+0xd84/0xf10
[Tue Dec 5 22:32:38 2023] memblock_add:
[0x1000-0x0008f7ff] e820__memblock_setup+0x73/0xb0
[Tue Dec 5 22:32:38 2023] memblock_add:
[0x4d0e00b0-0x60ff81cf] e820__memblock_setup+0x73/0xb0
[Tue Dec 5 22:32:38 2023] memblock_add:
[0x60ff81d0-0x60ff81ff] e820__memblock_setup+0x73/0xb0
[Tue Dec 5 22:32:38 2023] memblock_add:
[0x60ff8200-0x60ff] e820__memblock_setup+0x73/0xb0
[Tue Dec 5 22:32:38 2023] MEMBLOCK configuration:
[Tue Dec 5 22:32:38 2023] memory size = 0x13fae750 reserved size =
0x07b7cc50
[Tue Dec 5 22:32:38 2023] memory.cnt = 0x2
[Tue Dec 5 22:32:38 2023] memory[0x0]
[0x1000-0x0008efff], 0x0008e000 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] memory[0x1]
[0x4d0e1000-0x60ff], 0x13f1f000 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] reserved.cnt = 0x5
[Tue Dec 5 22:32:38 2023] reserved[0x0]
[0x-0x], 0x0001 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] reserved[0x1]
[0x0008f400-0x000f], 0x00070c00 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] reserved[0x2]
[0x57b16000-0x5f610fff], 0x07afb000 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] reserved[0x3]
[0x60ff81d0-0x60ff821f], 0x0050 bytes flags: 0x0
[Tue Dec 5 22:32:38 2023] reserved[0x4]
[0x60ffe000-0x60ffefff], 0x1000 bytes flags: 0x0
Thanks
Baoquan
Re: State of affairs with Ilitek 9341 support
On Mon, 11 Dec 2023 at 21:19, Andy Shevchenko wrote: > > On Fri, Dec 08, 2023 at 09:18:20PM +0100, Noralf Trønnes wrote: > > On 12/8/23 17:00, Andy Shevchenko wrote: > > > Included authors and latest (non-white-space) contributors to the drivers > > > in question along with relevant mailing list and respective (active in the > > > area) maintainers. > > > > > > I already had risen the question in times when 4th (sic!) driver for the > > > same > > > hardware was about to be pulled into upstream that we have to somehow > > > reduce > > > the code base and unify device properties. > > > > > > So, the main question here "What is the plan and where are we now?" > > > > > > I admit that fbtft case is special as it supports, in particular, platform > > > device (parallel interface) and also well established in the embedded > > > world. > > > What about the rest? > > > > > > N.B. Besides the fact that panel drivers are too OF-centric, which is bad > > > practice for the new kernel code in general and has to be stopped. I.o.w. > > > seeing of_property_*() or alike in the driver after ca. 2020 should be > > > immediate NAK unless it's very well justified why it may not be used on > > > non-OF systems. > > Noralf, thanks for your response, my comments below. > > TBH I would also like to hear from maintainers, because it seems they got > an additional burden for no benefit. > > > Last year drivers/gpu/drm/tiny/panel-mipi-dbi.c was added to support all > > MIPI DBI compatible (ili9341) SPI displays. > > It loads the initialisation commands from a firmware file. For more info > > see https://github.com/notro/panel-mipi-dbi/wiki. > > > > When I started on fbtft in 2013 I didn't know about MIPI DBI so I made > > some common bus access functions and one driver per controller and that > > driver had an initialisation sequence to match the panel I had. Then I > > discovered that displays using the same controller could have different > > init sequences so I added a Device Tree property that could > > override the driver init. > > > > In 2015 fbtft was added to drivers/staging, but later that year fbdev > > was closed for new drivers so it was a dead end. > > > > I started to work on porting fbtft to DRM and almost 2 years later > > support for the MI0283QT panel (ILI9341) was added. > > I had now learned about MIPI DBI so a library to handle that was added. > > I had asked on the Device Tree ML about the property and I was > > told that I couldn't have that which meant that I couldn't get away with > > having just one driver for the MIPI DBI compatible display panels as I > > was first hoping for. > > > > I was aware that there was a challenge going from fbtft to DRM because > > in fbtft there is support for all panel setups using the > > property, but in DRM every panel needed support in a driver. So I > > started to look at adding Device Tree properties to describe the setup > > for one controller. This would make it easy to describe a new panel in > > Device Tree for a supported controller. Maxime Ripard came up with the > > idea to have the controller initialisation commands in a firmware file > > which meant that we could get away with having just one driver for all > > MIPI DBI SPI panels (which is the vast majority of these SPI pixel > > upload panels). > > > > This meant that SPI support could be removed from all the MIPI DBI > > compatible controllers in fbtft > > I believe it can't. Otherwise we _must_ provide the DT (device property) > parser that uses what is provided for fbtft SPI to be enabled in the other > driver. > > > since there's now a solution for them in > > DRM. The drivers themselves must stay since they also have parallel bus > > support which is lacking in DRM. My plan was to wait for panel-mipi-dbi > > to hit an LTS and then either prepare patches to remove MIPI DBI SPI > > support from fbtft or at least send an email to staging about the new > > driver. > > > Unfortunately my health problems got worse and many plans went > > out the window. > > Oh, sad to hear this, hope you will get better sooner than later! > > > ILI9341 DRM drivers > > > > - drivers/gpu/drm/tiny/mi0283qt.c > > This was the first driver added for the MI0283QT panel series > > > > - drivers/gpu/drm/tiny/ili9341.c > > Later ili9341 based panels was decided to be added to a controller > > specific driver. > > Why was it appeared in the first place? :-( > > > - drivers/gpu/drm/tiny/panel-mipi-dbi.c > > Generic MIPI DBI SPI driver that loads init commands from a firmware > > file. It uses of_property_read_string_index() and > > of_get_drm_panel_display_mode(). I don't know if it's possible to make > > device_property_*() versions of those. > > Everything like this is possible, just somebody needs to fulfill that. > And as I said, new OF-centric code, has to be NAKed by default. > > > - drivers/gpu/drm/panel/panel-ilitek-ili9341.c > > This driver supports the MIPI DPI (RGB) interface on the controller. > >
Re: BUG / design challenge: vmwgfx + PRIME handle free == clobbering errno
On Tue, Dec 19, 2023 at 11:15 AM Stefan Hoffmeister wrote: > > > Hi, > > vmwgfx implements drmPrimeFDToHandle in terms of the TTM resource manager. > > At the same time, the driver advertises > > .driver_features = > DRIVER_MODESET | DRIVER_RENDER | DRIVER_ATOMIC | DRIVER_GEM, > > Given that, a userland application will call drmCloseBufferHandle to > correctly release any previously acquired handle. > > In kernel language, this translates to ioctl > DRM_IOCTL_PRIME_FD_TO_HANDLE and DRM_IOCTL_GEM_CLOSE. > > Problems: > > a) because the application uses drmCloseBufferHandle, and that goes > through GEM (the driver claims "I am GEM"!), vmwgfx will always return > EINVAL, because the driver is _not_ GEM, but TTM on that aspect. > > This will always clobber errno for userspace, which is not at all > helpful for meaningful error handling. > > Additionally, the driver offers no formal API contract which would > allow applications to detect that the driver does not like be talked > to like a GEM driver, although it is _claims_ to be GEM driver. > > b) there is no (documented) means to release the handle acquired from > a call to drmPrimeFDToHandle; this implies that in principle any call > to drmPrimeFDToHandle will leak the handle. > > Questions: > > a) how can errno clobbering by vmwgfx with EINVAL be avoided? > > b) what is the correct way to release the TTM resources allocated > through drmPrimeFDToHandle? > > > For context: the KDE Plasma Desktop kwin DRM integration layer makes > extensive use of drmPrimeFDToHandle. With the way the VMware vmwgfx > driver behaves, I see these options: > > a) correctly check the return code of drmCloseBufferHandle and blindly > log all the EINVAL errors triggered by the VMware driver, putting > blame on the application for mis-managing handles > b) drop any return code from drmCloseBufferHandle onto the floor, > completely disregarding application integrity checking > c) hard-code a check for "vmwgfx" as the driver in use and spam "this > driver owned by VMware / Broadcom is broken, ignore the following > EINVAL and secondary effects" for integrity checks > > I do not like any of these options, to be honest. > > Many thanks for any input Thanks for the report! This is mainly an artifact of vmwgfx predating GEM and really basically all of drm, so the ioctl interface on top of which vmwgfx operates is a bit bonkers. I know there are a number of examples where drm graphics drivers were breaking the ioctl interface, but we've tried avoiding that in vmwgfx and so supporting our old userspace and new userspace, which are incompatible, is incredibly complex and fragile. Our approach was to, in general, deal with those as they come. Our userspace, also in general, deals with surfaces, which aren't GEM's, as you've noticed, but instead are backed by a GEM object, so expects the handle to prime to not be GEM's. As you can imagine it's a bit hard to make sure ioctl's for which userspace has the opposite expectations are working fine (we've done it for some already though, the "dumb" ones being an example). If you'd have an IGT test that tests for this without requiring CRC's then we'd get it fixed quickly. Otherwise making it work is difficult, not because this particular bug is difficult to fix, but because it's difficult to fix it while keeping the xorg drivers from 2012 working. We'll likely just make sure the prime ioctl's return proper GEM objects for clients that advertise certain cap's. Is KWin advertising DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT? That'd be a trivial, albeit unexpected, way of making sure the old userspace gets the semantics it expects, while making sure the new clients get proper behavior. z
Re: [PATCH] drm/vmwgfx: Keep a gem reference to user bos in surfaces
On Thu, Dec 21, 2023 at 5:54 AM Sverdlin, Alexander
wrote:
>
> Hi Zack,
>
> thank you for the patch!
>
> On Thu, 2023-09-28 at 00:13 -0400, Zack Rusin wrote:
> > From: Zack Rusin
> >
> > Surfaces can be backed (i.e. stored in) memory objects (mob's) which
> > are created and managed by the userspace as GEM buffers. Surfaces
> > grab only a ttm reference which means that the gem object can
> > be deleted underneath us, especially in cases where prime buffer
> > export is used.
> >
> > Make sure that all userspace surfaces which are backed by gem objects
> > hold a gem reference to make sure they're not deleted before vmw
> > surfaces are done with them, which fixes:
> > [ cut here ]
> > refcount_t: underflow; use-after-free.
> > WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28
> > refcount_warn_saturate+0xfb/0x150
> > Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common
> > vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm
> > gameport>
> > CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1
> > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
> > Platform, BIOS 6.00 11/12/2020
> > RIP: 0010:refcount_warn_saturate+0xfb/0x150
> > Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89
> > 48 c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff
> > ff ff 0f b>
> > RSP: 0018:bdc34344bba0 EFLAGS: 00010286
> > RAX: RBX: RCX: 0027
> > RDX: 960475ea1548 RSI: 0001 RDI: 960475ea1540
> > RBP: bdc34344bba8 R08: 0003 R09: 65646e75203a745f
> > R10: a5b32b20 R11: 72657466612d6573 R12: 96037d6a6400
> > R13: 9603484805b0 R14: 000b R15: 9603bed06060
> > FS: 7f5fd8520c40() GS:960475e8() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 7f5fda755000 CR3: 00010d012005 CR4: 003706e0
> > Call Trace:
> >
> > ? show_regs+0x6e/0x80
> > ? refcount_warn_saturate+0xfb/0x150
> > ? __warn+0x91/0x150
> > ? refcount_warn_saturate+0xfb/0x150
> > ? report_bug+0x19d/0x1b0
> > ? handle_bug+0x46/0x80
> > ? exc_invalid_op+0x1d/0x80
> > ? asm_exc_invalid_op+0x1f/0x30
> > ? refcount_warn_saturate+0xfb/0x150
> > drm_gem_object_handle_put_unlocked+0xba/0x110 [drm]
> > drm_gem_object_release_handle+0x6e/0x80 [drm]
> > drm_gem_handle_delete+0x6a/0xc0 [drm]
> > ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
> > vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx]
> > drm_ioctl_kernel+0xbc/0x160 [drm]
> > drm_ioctl+0x2d2/0x580 [drm]
> > ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
> > ? do_vmi_munmap+0xee/0x180
> > vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
> > vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
> > __x64_sys_ioctl+0x99/0xd0
> > do_syscall_64+0x5d/0x90
> > ? syscall_exit_to_user_mode+0x2a/0x50
> > ? do_syscall_64+0x6d/0x90
> > ? handle_mm_fault+0x16e/0x2f0
> > ? exit_to_user_mode_prepare+0x34/0x170
> > ? irqentry_exit_to_user_mode+0xd/0x20
> > ? irqentry_exit+0x3f/0x50
> > ? exc_page_fault+0x8e/0x190
> > entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> > RIP: 0033:0x7f5fda51aaff
> > Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44
> > 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00
> > f0 ff ff 7>
> > RSP: 002b:7ffd536a4d30 EFLAGS: 0246 ORIG_RAX: 0010
> > RAX: ffda RBX: 7ffd536a4de0 RCX: 7f5fda51aaff
> > RDX: 7ffd536a4de0 RSI: 40086442 RDI: 0003
> > RBP: 40086442 R08: 55fa603ada50 R09:
> > R10: 0001 R11: 0246 R12: 7ffd536a51b8
> > R13: 0003 R14: 55fa5ebb4c80 R15: 7f5fda90f040
> >
> > ---[ end trace ]---
> >
> > A lot of the analyis on the bug was done by Murray McAllister and
> > Ian Forbes.
> >
> > Reported-by: Murray McAllister
> > Cc: Ian Forbes
> > Signed-off-by: Zack Rusin
> > Fixes: a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle
> > too soon")
> > Cc: # v6.2+
>
> Do you remember the particular reason this was marked 6.2+?
That's because that's the kernel release where the commit this one is
fixing first landed.
> We see this on Debian 6.1.67 (which at least has the mentioned
> "drm/vmwgfx: Do not drop the reference to the handle too soon"):
The original had to be backported there. I'll ask someone on my team
to check the branches the original was backported to see if this
change even applies on those and then we'll see what we can do. In the
meantime if you know anyone on the Debian kernel team suggesting this
as a cherry-pick might also be a good idea.
z
Re: [PATCH] drm/msm/a6xx: Fix recovery vs runpm race
On Fri, Dec 22, 2023 at 11:58 AM Akhil P Oommen
wrote:
>
> On Mon, Dec 18, 2023 at 07:59:24AM -0800, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > a6xx_recover() is relying on the gpu lock to serialize against incoming
> > submits doing a runpm get, as it tries to temporarily balance out the
> > runpm gets with puts in order to power off the GPU. Unfortunately this
> > gets worse when we (in a later patch) will move the runpm get out of the
> > scheduler thread/work to move it out of the fence signaling path.
> >
> > Instead we can just simplify the whole thing by using force_suspend() /
> > force_resume() instead of trying to be clever.
>
> At some places, we take a pm_runtime vote and access the gpu
> registers assuming it will be powered until we drop the vote.
> a6xx_get_timestamp()
> is an example. If we do a force suspend, it may cause bus errors from
> those threads. Now you have to serialize every place we do runtime_get/put
> with a
> mutex. Or is there a better way to handle the 'later patch' you
> mentioned?
So I was running into issues, when I started adding an igt test to
stress test recovery vs multi-threaded submit, with cxpd not always
suspending and getting "cx gdsc did not collapse", which may be
related.
I was considering using force_suspend() on the gmu and cxpd if
gpu->hang==true, I'm not sure. I ran out of time to play with this
when I was in the office.
The issue the 'later patch' is trying to deal with is getting memory
allocations out of the "fence signaling path", ie. out from the
drm/sched kthread/worker. One way to do that, without dragging all of
runpm/device-link/etc into it is to do the runpm get in the submit
ioctl before enqueuing the job to the scheduler. But then we can hold
a lock to protect against racing with recovery.
BR,
-R
> -Akhil.
>
> >
> > Reported-by: David Heidelberg
> > Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10272
> > Fixes: abe2023b4cea ("drm/msm/gpu: Push gpu lock down past runpm")
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 ++--
> > 1 file changed, 2 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index 268737e59131..a5660d63535b 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -1244,12 +1244,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
> > dev_pm_genpd_add_notifier(gmu->cxpd, >pd_nb);
> > dev_pm_genpd_synced_poweroff(gmu->cxpd);
> >
> > - /* Drop the rpm refcount from active submits */
> > - if (active_submits)
> > - pm_runtime_put(>pdev->dev);
> > -
> > - /* And the final one from recover worker */
> > - pm_runtime_put_sync(>pdev->dev);
> > + pm_runtime_force_suspend(>pdev->dev);
> >
> > if (!wait_for_completion_timeout(>pd_gate,
> > msecs_to_jiffies(1000)))
> > DRM_DEV_ERROR(>pdev->dev, "cx gdsc didn't collapse\n");
> > @@ -1258,10 +1253,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
> >
> > pm_runtime_use_autosuspend(>pdev->dev);
> >
> > - if (active_submits)
> > - pm_runtime_get(>pdev->dev);
> > -
> > - pm_runtime_get_sync(>pdev->dev);
> > + pm_runtime_force_resume(>pdev->dev);
> >
> > gpu->active_submits = active_submits;
> > mutex_unlock(>active_lock);
> > --
> > 2.43.0
> >
Re: [PATCH] drm/msm/a6xx: Fix recovery vs runpm race
On Mon, Dec 18, 2023 at 07:59:24AM -0800, Rob Clark wrote:
>
> From: Rob Clark
>
> a6xx_recover() is relying on the gpu lock to serialize against incoming
> submits doing a runpm get, as it tries to temporarily balance out the
> runpm gets with puts in order to power off the GPU. Unfortunately this
> gets worse when we (in a later patch) will move the runpm get out of the
> scheduler thread/work to move it out of the fence signaling path.
>
> Instead we can just simplify the whole thing by using force_suspend() /
> force_resume() instead of trying to be clever.
At some places, we take a pm_runtime vote and access the gpu
registers assuming it will be powered until we drop the vote.
a6xx_get_timestamp()
is an example. If we do a force suspend, it may cause bus errors from
those threads. Now you have to serialize every place we do runtime_get/put with
a
mutex. Or is there a better way to handle the 'later patch' you
mentioned?
-Akhil.
>
> Reported-by: David Heidelberg
> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10272
> Fixes: abe2023b4cea ("drm/msm/gpu: Push gpu lock down past runpm")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 268737e59131..a5660d63535b 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1244,12 +1244,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
> dev_pm_genpd_add_notifier(gmu->cxpd, >pd_nb);
> dev_pm_genpd_synced_poweroff(gmu->cxpd);
>
> - /* Drop the rpm refcount from active submits */
> - if (active_submits)
> - pm_runtime_put(>pdev->dev);
> -
> - /* And the final one from recover worker */
> - pm_runtime_put_sync(>pdev->dev);
> + pm_runtime_force_suspend(>pdev->dev);
>
> if (!wait_for_completion_timeout(>pd_gate, msecs_to_jiffies(1000)))
> DRM_DEV_ERROR(>pdev->dev, "cx gdsc didn't collapse\n");
> @@ -1258,10 +1253,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
>
> pm_runtime_use_autosuspend(>pdev->dev);
>
> - if (active_submits)
> - pm_runtime_get(>pdev->dev);
> -
> - pm_runtime_get_sync(>pdev->dev);
> + pm_runtime_force_resume(>pdev->dev);
>
> gpu->active_submits = active_submits;
> mutex_unlock(>active_lock);
> --
> 2.43.0
>
Re: [PATCH 1/2] drm/bridge: add ->edid_read hook and drm_bridge_edid_read()
On Thu, 26 Oct 2023 at 12:40, Jani Nikula wrote:
>
> Add new struct drm_edid based ->edid_read hook and
> drm_bridge_edid_read() function to call the hook.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_bridge.c | 46 +++-
> include/drm/drm_bridge.h | 33 ++
> 2 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 30d66bee0ec6..e1cfba2ff583 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -27,8 +27,9 @@
> #include
>
> #include
> -#include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1206,6 +1207,47 @@ int drm_bridge_get_modes(struct drm_bridge *bridge,
> }
> EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
>
> +/**
> + * drm_bridge_edid_read - read the EDID data of the connected display
> + * @bridge: bridge control structure
> + * @connector: the connector to read EDID for
> + *
> + * If the bridge supports output EDID retrieval, as reported by the
> + * DRM_BRIDGE_OP_EDID bridge ops flag, call _bridge_funcs.edid_read to
> get
> + * the EDID and return it. Otherwise return NULL.
> + *
> + * If _bridge_funcs.edid_read is not set, fall back to using
> + * drm_bridge_get_edid() and wrapping it in struct drm_edid.
> + *
> + * RETURNS:
> + * The retrieved EDID on success, or NULL otherwise.
Wouldn't it be better to return an ERR_PTR instead of NULL?
> + */
> +const struct drm_edid *drm_bridge_edid_read(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> + return NULL;
> +
> + /* Transitional: Fall back to ->get_edid. */
> + if (!bridge->funcs->edid_read) {
> + const struct drm_edid *drm_edid;
> + struct edid *edid;
> +
> + edid = drm_bridge_get_edid(bridge, connector);
> + if (!edid)
> + return NULL;
> +
> + drm_edid = drm_edid_alloc(edid, (edid->extensions + 1) *
> EDID_LENGTH);
> +
> + kfree(edid);
> +
> + return drm_edid;
> + }
> +
> + return bridge->funcs->edid_read(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_edid_read);
[skipped the rest]
--
With best wishes
Dmitry
Re: [PATCH 2/6] drm/panel: Add driver for BOE TH101MB31IG002-28A panel
On Fri, Dec 22, 2023 at 2:32 PM Manuel Traut wrote:
>
> From: Segfault
>
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Segfault
Please use a real name instead...
> +MODULE_AUTHOR("Alexander Warnecke ");
like here.
[PATCH v4 23/29] drm/rockchip: inno_hdmi: Add variant support
In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the phy
configuration required, so those are part of the match_data. The values
have been taken from downstream. The pixelclocks in there are meant to be
max-inclusive.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- adapt to the newly introduced inno_hdmi_power_up / inno_hdmi_standby
functions
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 74 ++--
1 file changed, 69 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 44c311e7e2d3..34f0358e8d7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,17 @@
#include "inno_hdmi.h"
+struct inno_hdmi_phy_config {
+ unsigned long pixelclock;
+ u8 pre_emphasis;
+ u8 voltage_level_control;
+};
+
+struct inno_hdmi_variant {
+ struct inno_hdmi_phy_config *phy_configs;
+ struct inno_hdmi_phy_config *default_phy_config;
+};
+
struct inno_hdmi_i2c {
struct i2c_adapter adap;
@@ -47,6 +58,8 @@ struct inno_hdmi {
struct inno_hdmi_i2c *i2c;
struct i2c_adapter *ddc;
+
+ const struct inno_hdmi_variant *variant;
};
struct inno_hdmi_connector_state {
@@ -113,6 +126,30 @@ static const char coeff_csc[][24] = {
},
};
+static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
+ { 7425, 0x3f, 0xbb },
+ { 16500, 0x6f, 0xbb },
+ { ~0UL, 0x00, 0x00 }
+};
+
+static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
+unsigned long pixelclk)
+{
+ const struct inno_hdmi_phy_config *phy_configs =
+ hdmi->variant->phy_configs;
+ int i;
+
+ for (i = 0; phy_configs[i].pixelclock != ~0UL; i++) {
+ if (pixelclk <= phy_configs[i].pixelclock)
+ return i;
+ }
+
+ DRM_DEV_DEBUG(hdmi->dev, "No phy configuration for pixelclock %lu\n",
+ pixelclk);
+
+ return -EINVAL;
+}
+
static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
{
return readl_relaxed(hdmi->regs + (offset) * 0x04);
@@ -164,12 +201,25 @@ static void inno_hdmi_standby(struct inno_hdmi *hdmi)
hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
};
-static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi,
+ unsigned long mpixelclock)
{
+ struct inno_hdmi_phy_config *phy_config;
+ int ret = inno_hdmi_find_phy_config(hdmi, mpixelclock);
+
+ if (ret < 0) {
+ phy_config = hdmi->variant->default_phy_config;
+ DRM_DEV_ERROR(hdmi->dev,
+ "Using default phy configuration for TMDS rate
%lu",
+ mpixelclock);
+ } else {
+ phy_config = >variant->phy_configs[ret];
+ }
+
inno_hdmi_sys_power(hdmi, false);
- hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
- hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+ hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, phy_config->pre_emphasis);
+ hdmi_writeb(hdmi, HDMI_PHY_DRIVER, phy_config->voltage_level_control);
hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
@@ -406,6 +456,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
struct drm_display_mode *mode)
{
struct drm_display_info *display = >connector.display_info;
+ unsigned long mpixelclock = mode->clock * 1000;
/* Mute video and audio output */
hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -428,13 +479,13 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
* DCLK_LCDC, so we need to init the TMDS rate to mode pixel
* clock rate, and reconfigure the DDC clock.
*/
- inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
+ inno_hdmi_i2c_init(hdmi, mpixelclock);
/* Unmute video and audio output */
hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
- inno_hdmi_power_up(hdmi);
+ inno_hdmi_power_up(hdmi, mpixelclock);
return 0;
}
@@ -827,6 +878,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = data;
struct inno_hdmi *hdmi;
+ const struct inno_hdmi_variant *variant;
int irq;
int ret;
@@ -836,6 +888,12 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
hdmi->dev = dev;
+ variant =
[PATCH v4 28/29] ARM: dts: rockchip: Add HDMI node for RK3128
RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
arch/arm/boot/dts/rockchip/rk3128.dtsi | 33 ++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 1a3bc8b2bc6e..fb98873fd94e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -270,6 +270,11 @@ vop: vop@1010e000 {
vop_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vop_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vop>;
+ };
};
};
@@ -463,6 +468,34 @@ usb2phy_otg: otg-port {
};
};
+ hdmi: hdmi@20034000 {
+ compatible = "rockchip,rk3128-inno-hdmi";
+ reg = <0x20034000 0x4000>;
+ interrupts = ;
+ clocks = < PCLK_HDMI>, < DCLK_VOP>;
+ clock-names = "pclk", "ref";
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer _hpd _cec>;
+ power-domains = < RK3128_PD_VIO>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+ hdmi_in_vop: endpoint {
+ remote-endpoint = <_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
timer0: timer@20044000 {
compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
reg = <0x20044000 0x20>;
--
2.43.0
[PATCH v4 29/29] ARM: dts: rockchip: Enable HDMI output for XPI-3128
Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
.../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 03a97881519a..21c1678f4e91 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -47,6 +47,17 @@ dc_5v: dc-5v-regulator {
regulator-boot-on;
};
+ hdmi-connnector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <_connector_out>;
+ };
+ };
+ };
+
/*
* This is a vbus-supply, which also supplies the GL852G usb hub,
* thus has to be always-on
@@ -239,6 +250,10 @@ {
cpu-supply = <_arm>;
};
+_subsystem {
+ status = "okay";
+};
+
{
bus-width = <8>;
vmmc-supply = <_io>;
@@ -328,6 +343,16 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_connector_out: endpoint {
+ remote-endpoint = <_connector_in>;
+ };
+};
+
{
phy0: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
@@ -423,3 +448,7 @@ _host {
_otg {
status = "okay";
};
+
+ {
+ status = "okay";
+};
--
2.43.0
[PATCH v4 26/29] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
Now that we have proper pixelclock-based mode validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")
Signed-off-by: Alex Bee
Reviewed-by: Maxime Ripard
---
changes in v2:
- no changes
changes in v3:
- collect RB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index a074451a0c49..d7453c36d37a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -630,13 +630,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector
*connector,
return inno_hdmi_display_mode_valid(hdmi, mode);
}
-static int
-inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
- uint32_t maxX, uint32_t maxY)
-{
- return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
-}
-
static void inno_hdmi_connector_destroy(struct drm_connector *connector)
{
drm_connector_unregister(connector);
@@ -695,7 +688,7 @@ inno_hdmi_connector_duplicate_state(struct drm_connector
*connector)
}
static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
- .fill_modes = inno_hdmi_probe_single_connector_modes,
+ .fill_modes = drm_helper_probe_single_connector_modes,
.detect = inno_hdmi_connector_detect,
.destroy = inno_hdmi_connector_destroy,
.reset = inno_hdmi_connector_reset,
--
2.43.0
[PATCH v4 24/29] drm/rockchip: inno_hdmi: Add RK3128 support
This variant requires the phy reference clock to be enabled before the DDC
block can work and the (initial) DDC bus frequency is calculated based on
the rate of this clock. Besides the only difference is phy configuration
required to make the driver working for this variant as well.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 46 +---
1 file changed, 41 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 34f0358e8d7b..3b76929deefe 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -51,6 +51,7 @@ struct inno_hdmi {
struct device *dev;
struct clk *pclk;
+ struct clk *refclk;
void __iomem *regs;
struct drm_connectorconnector;
@@ -132,6 +133,12 @@ static struct inno_hdmi_phy_config
rk3036_hdmi_phy_configs[] = {
{ ~0UL, 0x00, 0x00 }
};
+static struct inno_hdmi_phy_config rk3128_hdmi_phy_configs[] = {
+ { 7425, 0x3f, 0xaa },
+ { 16500, 0x5f, 0xaa },
+ { ~0UL, 0x00, 0x00 }
+};
+
static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
unsigned long pixelclk)
{
@@ -911,6 +918,20 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
return ret;
}
+ hdmi->refclk = devm_clk_get_optional(hdmi->dev, "ref");
+ if (IS_ERR(hdmi->refclk)) {
+ DRM_DEV_ERROR(hdmi->dev, "Unable to get HDMI reference
clock\n");
+ ret = PTR_ERR(hdmi->refclk);
+ goto err_disable_pclk;
+ }
+
+ ret = clk_prepare_enable(hdmi->refclk);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev,
+ "Cannot enable HDMI reference clock: %d\n", ret);
+ goto err_disable_pclk;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
@@ -927,12 +948,16 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
}
/*
-* When IP controller haven't configured to an accurate video
-* timing, then the TMDS clock source would be switched to
-* PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-* and reconfigure the DDC clock.
+* When the controller isn't configured to an accurate
+* video timing and there is no reference clock available,
+* then the TMDS clock source would be switched to PCLK_HDMI,
+* so we need to init the TMDS rate to PCLK rate, and
+* reconfigure the DDC clock.
*/
- inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
+ if (hdmi->refclk)
+ inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->refclk));
+ else
+ inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
ret = inno_hdmi_register(drm, hdmi);
if (ret)
@@ -956,6 +981,8 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
err_put_adapter:
i2c_put_adapter(hdmi->ddc);
err_disable_clk:
+ clk_disable_unprepare(hdmi->refclk);
+err_disable_pclk:
clk_disable_unprepare(hdmi->pclk);
return ret;
}
@@ -969,6 +996,7 @@ static void inno_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->encoder.encoder.funcs->destroy(>encoder.encoder);
i2c_put_adapter(hdmi->ddc);
+ clk_disable_unprepare(hdmi->refclk);
clk_disable_unprepare(hdmi->pclk);
}
@@ -992,10 +1020,18 @@ static const struct inno_hdmi_variant
rk3036_inno_hdmi_variant = {
.default_phy_config = _hdmi_phy_configs[1],
};
+static const struct inno_hdmi_variant rk3128_inno_hdmi_variant = {
+ .phy_configs = rk3128_hdmi_phy_configs,
+ .default_phy_config = _hdmi_phy_configs[1],
+};
+
static const struct of_device_id inno_hdmi_dt_ids[] = {
{ .compatible = "rockchip,rk3036-inno-hdmi",
.data = _inno_hdmi_variant,
},
+ { .compatible = "rockchip,rk3128-inno-hdmi",
+ .data = _inno_hdmi_variant,
+ },
{},
};
MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
--
2.43.0
[PATCH v4 25/29] drm/rockchip: inno_hdmi: Add basic mode validation
As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks. If the
variant has a phy reference clock we can additionally validate against VESA
DMT'srecommendations.
Signed-off-by: Alex Bee
Reviewed-by: Maxime Ripard
---
changes in v2:
- rename inno_mode_valid -> inno_hdmi_display_mode_valid
- fixed max_tolerance calculation
- use abs_diff() instead of abs()
- call in inno_hdmi_display_mode_valid in atomic_check
changes in v3:
- collect RB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 42 ++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 3b76929deefe..a074451a0c49 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,8 @@
#include "inno_hdmi.h"
+#define INNO_HDMI_MIN_TMDS_CLOCK 2500U
+
struct inno_hdmi_phy_config {
unsigned long pixelclock;
u8 pre_emphasis;
@@ -497,6 +499,38 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
return 0;
}
+static enum drm_mode_status inno_hdmi_display_mode_valid(struct inno_hdmi
*hdmi,
+struct
drm_display_mode *mode)
+{
+ unsigned long mpixelclk, max_tolerance;
+ long rounded_refclk;
+
+ /* No support for double-clock modes */
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ return MODE_BAD;
+
+ mpixelclk = mode->clock * 1000;
+
+ if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
+ return MODE_CLOCK_LOW;
+
+ if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
+ return MODE_CLOCK_HIGH;
+
+ if (hdmi->refclk) {
+ rounded_refclk = clk_round_rate(hdmi->refclk, mpixelclk);
+ if (rounded_refclk < 0)
+ return MODE_BAD;
+
+ /* Vesa DMT standard mentions +/- 0.5% max tolerance */
+ max_tolerance = mpixelclk / 200;
+ if (abs_diff((unsigned long)rounded_refclk, mpixelclk) >
max_tolerance)
+ return MODE_NOCLOCK;
+ }
+
+ return MODE_OK;
+}
+
static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
@@ -529,6 +563,7 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_connector_state *conn_state)
{
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+ struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
struct drm_display_mode *mode = _state->adjusted_mode;
u8 vic = drm_match_cea_mode(mode);
struct inno_hdmi_connector_state *inno_conn_state =
@@ -549,7 +584,8 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
inno_conn_state->rgb_limited_range =
drm_default_rgb_quant_range(mode) ==
HDMI_QUANTIZATION_RANGE_LIMITED;
- return 0;
+ return inno_hdmi_display_mode_valid(hdmi,
+ _state->adjusted_mode) == MODE_OK ? 0 :
-EINVAL;
}
static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
@@ -590,7 +626,9 @@ static enum drm_mode_status
inno_hdmi_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return MODE_OK;
+ struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
+
+ return inno_hdmi_display_mode_valid(hdmi, mode);
}
static int
--
2.43.0
[PATCH v4 19/29] drm/rockchip: inno_hdmi: Subclass connector state
The data which is currently hold in hdmi_data should not be part of device
itself but of the connector state.
Introduce a connector state subclass and move the data from hdmi_data in
there.
Suggested-by: Maxime Ripard
Signed-off-by: Alex Bee
---
changes in v2:
- new patch
changes in v3:
- added missing customizations of reset and atomic_destroy_state connector
hooks
- moved inno_conn_state member assignments to atomic_check
changes in v4:
- added missing state destroy in reset hook
drivers/gpu/drm/rockchip/inno_hdmi.c | 117 ---
1 file changed, 90 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c306db90832a..e43fce968310 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,11 +26,6 @@
#include "inno_hdmi.h"
-struct hdmi_data_info {
- unsigned int enc_out_format;
- unsigned int colorimetry;
-};
-
struct inno_hdmi_i2c {
struct i2c_adapter adap;
@@ -52,8 +47,12 @@ struct inno_hdmi {
struct inno_hdmi_i2c *i2c;
struct i2c_adapter *ddc;
+};
- struct hdmi_data_info hdmi_data;
+struct inno_hdmi_connector_state {
+ struct drm_connector_state base;
+ unsigned intenc_out_format;
+ unsigned intcolorimetry;
};
static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -68,6 +67,9 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct
drm_connector *connector)
return container_of(connector, struct inno_hdmi, connector);
}
+#define to_inno_hdmi_conn_state(conn_state) \
+ container_of_const(conn_state, struct inno_hdmi_connector_state, base)
+
enum {
CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
@@ -246,6 +248,10 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
struct drm_display_mode *mode)
{
+ struct drm_connector *connector = >connector;
+ struct drm_connector_state *conn_state = connector->state;
+ struct inno_hdmi_connector_state *inno_conn_state =
+ to_inno_hdmi_conn_state(conn_state);
union hdmi_infoframe frame;
int rc;
@@ -257,9 +263,9 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
return rc;
}
- if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
+ if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
- else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
+ else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
@@ -269,7 +275,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
{
- struct hdmi_data_info *data = >hdmi_data;
+ struct drm_connector *connector = >connector;
+ struct drm_connector_state *conn_state = connector->state;
+ struct inno_hdmi_connector_state *inno_conn_state =
+ to_inno_hdmi_conn_state(conn_state);
int c0_c2_change = 0;
int csc_enable = 0;
int csc_mode = 0;
@@ -287,7 +296,7 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
*hdmi)
v_VIDEO_INPUT_CSP(0);
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
- if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+ if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
@@ -298,15 +307,15 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
*hdmi)
return 0;
}
- if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
- if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+ if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+ if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
auto_csc = AUTO_CSC_DISABLE;
c0_c2_change = C0_C2_CHANGE_DISABLE;
csc_enable = v_CSC_ENABLE;
}
} else {
- if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+ if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
auto_csc = AUTO_CSC_DISABLE;
c0_c2_change =
[PATCH v4 13/29] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
From: Maxime Ripard
The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.
Suggested-by: Johan Jonker
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 35
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 102195837206..5c9f1325441f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -206,11 +206,15 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
}
static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
- union hdmi_infoframe *frame, u32 frame_index,
- u32 mask, u32 disable, u32 enable)
+ union hdmi_infoframe *frame, u32 frame_index)
{
- if (mask)
- hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+ struct drm_connector *connector = >connector;
+
+ if (frame_index != INFOFRAME_AVI) {
+ drm_err(connector->dev,
+ "Unsupported infoframe type: %u\n", frame_index);
+ return 0;
+ }
hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
@@ -226,28 +230,11 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
int setup_rc,
for (i = 0; i < rc; i++)
hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
packed_frame[i]);
-
- if (mask)
- hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
}
return setup_rc;
}
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
- struct drm_display_mode *mode)
-{
- union hdmi_infoframe frame;
- int rc;
-
- rc = drm_hdmi_vendor_infoframe_from_display_mode(,
->connector,
-mode);
-
- return inno_hdmi_upload_frame(hdmi, rc, , INFOFRAME_VSI,
- m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
-}
-
static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
struct drm_display_mode *mode)
{
@@ -265,7 +252,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
- return inno_hdmi_upload_frame(hdmi, rc, , INFOFRAME_AVI, 0, 0, 0);
+ return inno_hdmi_upload_frame(hdmi, rc, , INFOFRAME_AVI);
}
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
@@ -408,10 +395,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
inno_hdmi_config_video_csc(hdmi);
- if (display->is_hdmi) {
+ if (display->is_hdmi)
inno_hdmi_config_video_avi(hdmi, mode);
- inno_hdmi_config_video_vsi(hdmi, mode);
- }
/*
* When IP controller have configured to an accurate video
--
2.43.0
[PATCH v4 27/29] ARM: dts: rockchip: Add display subsystem for RK3128
Add vop and display-subsystem nodes to RK3128's device tree.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..1a3bc8b2bc6e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -115,6 +115,12 @@ opp-12 {
};
};
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <_out>;
+ status = "disabled";
+ };
+
gpu_opp_table: opp-table-1 {
compatible = "operating-points-v2";
@@ -246,6 +252,27 @@ power-domain@RK3128_PD_GPU {
};
};
+ vop: vop@1010e000 {
+ compatible = "rockchip,rk3126-vop";
+ reg = <0x1010e000 0x300>;
+ interrupts = ;
+ clocks = < ACLK_LCDC0>, < DCLK_VOP>,
+< HCLK_LCDC0>;
+ clock-names = "aclk_vop", "dclk_vop",
+ "hclk_vop";
+ resets = < SRST_VOP_A>, < SRST_VOP_H>,
+< SRST_VOP_D>;
+ reset-names = "axi", "ahb",
+ "dclk";
+ power-domains = < RK3128_PD_VIO>;
+ status = "disabled";
+
+ vop_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
qos_gpu: qos@1012d000 {
compatible = "rockchip,rk3128-qos", "syscon";
reg = <0x1012d000 0x20>;
--
2.43.0
[PATCH v4 12/29] drm/rockchip: inno_hdmi: Remove tmds rate from structure
From: Maxime Ripard
The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.
We can simply make that rate an argument to that function, which also
removes a workaround to initialize the divider at probe time when we
don't have a mode yet.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v3:
- imported patch
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 04344ee1265d..102195837206 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -56,8 +56,6 @@ struct inno_hdmi {
struct inno_hdmi_i2c *i2c;
struct i2c_adapter *ddc;
- unsigned int tmds_rate;
-
struct hdmi_data_info hdmi_data;
};
@@ -134,11 +132,11 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16
offset,
hdmi_writeb(hdmi, offset, temp);
}
-static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
+static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi, unsigned long long rate)
{
- int ddc_bus_freq;
+ unsigned long long ddc_bus_freq = rate >> 2;
- ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+ do_div(ddc_bus_freq, HDMI_SCL_RATE);
hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
@@ -421,8 +419,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
* DCLK_LCDC, so we need to init the TMDS rate to mode pixel
* clock rate, and reconfigure the DDC clock.
*/
- hdmi->tmds_rate = mode->clock * 1000;
- inno_hdmi_i2c_init(hdmi);
+ inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
/* Unmute video and audio output */
hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -800,8 +797,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
* PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
* and reconfigure the DDC clock.
*/
- hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
- inno_hdmi_i2c_init(hdmi);
+ inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
ret = inno_hdmi_register(drm, hdmi);
if (ret)
--
2.43.0
[PATCH v4 17/29] drm/rockchip: inno_hdmi: Drop irq struct member
The struct member irq isn't used anywhere. Drop it.
Signed-off-by: Alex Bee
Reviewed-by: Maxime Ripard
---
changes in v2:
- new patch
changes in v3:
- collect RB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 51c1a69dfcc0..138cd4287dea 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -45,7 +45,6 @@ struct inno_hdmi_i2c {
struct inno_hdmi {
struct device *dev;
- int irq;
struct clk *pclk;
void __iomem *regs;
--
2.43.0
[PATCH v4 20/29] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.
This enables color space conversion for those modes and sets the
quantization range accordingly in the AVI infoframe.
Signed-off-by: Alex Bee
---
changes in v2:
- made rgb_limited_range part of the new custom connector state
changes in v3:
- moved assignment of rgb_limited_range to atomic check
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 60 +++-
1 file changed, 42 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e43fce968310..f3b90b479ab9 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -53,6 +53,7 @@ struct inno_hdmi_connector_state {
struct drm_connector_state base;
unsigned intenc_out_format;
unsigned intcolorimetry;
+ boolrgb_limited_range;
};
static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -270,6 +271,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
+ drm_hdmi_avi_infoframe_quant_range(,
+ connector, mode,
+
inno_conn_state->rgb_limited_range ?
+
HDMI_QUANTIZATION_RANGE_LIMITED :
+
HDMI_QUANTIZATION_RANGE_FULL);
+ } else {
+ frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+ frame.avi.ycc_quantization_range =
+ HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+ }
+
return inno_hdmi_upload_frame(hdmi, , HDMI_INFOFRAME_TYPE_AVI);
}
@@ -297,29 +310,37 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
*hdmi)
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
- value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
- hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
- hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
- m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
- v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
- v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
- return 0;
- }
-
- if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
- if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
- csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+ if (inno_conn_state->rgb_limited_range) {
+ csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
auto_csc = AUTO_CSC_DISABLE;
c0_c2_change = C0_C2_CHANGE_DISABLE;
csc_enable = v_CSC_ENABLE;
+
+ } else {
+ value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+ hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+ hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+ m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+ v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+ v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+ return 0;
}
} else {
- if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
- csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
- auto_csc = AUTO_CSC_DISABLE;
- c0_c2_change = C0_C2_CHANGE_DISABLE;
- csc_enable = v_CSC_ENABLE;
+ if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+ if (inno_conn_state->enc_out_format ==
HDMI_COLORSPACE_YUV444) {
+ csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+ auto_csc = AUTO_CSC_DISABLE;
+ c0_c2_change = C0_C2_CHANGE_DISABLE;
+ csc_enable = v_CSC_ENABLE;
+ }
+ } else {
+ if (inno_conn_state->enc_out_format ==
HDMI_COLORSPACE_YUV444) {
+ csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
+ auto_csc = AUTO_CSC_DISABLE;
+ c0_c2_change = C0_C2_CHANGE_DISABLE;
+
[PATCH v4 08/29] drm/rockchip: inno_hdmi: no need to store vic
From: Maxime Ripard
The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
[made checkpatch happy]
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 299770e481b7..d99896f1a73a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
#include "inno_hdmi.h"
struct hdmi_data_info {
- int vic;
bool sink_has_audio;
unsigned int enc_in_format;
unsigned int enc_out_format;
@@ -443,16 +442,15 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
struct drm_display_mode *mode)
{
struct drm_display_info *display = >connector.display_info;
-
- hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+ u8 vic = drm_match_cea_mode(mode);
hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
- if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
- (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
- (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
- (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+ if (vic == 6 || vic == 7 ||
+ vic == 21 || vic == 22 ||
+ vic == 2 || vic == 3 ||
+ vic == 17 || vic == 18)
hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
else
hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
--
2.43.0
[PATCH v4 10/29] drm/rockchip: inno_hdmi: Remove useless input format
From: Maxime Ripard
The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
[made checkpatch happy]
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 41
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 58aff7a9c09a..7c75feedacad 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
#include "inno_hdmi.h"
struct hdmi_data_info {
- unsigned int enc_in_format;
unsigned int enc_out_format;
unsigned int colorimetry;
};
@@ -328,47 +327,30 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
*hdmi)
v_VIDEO_INPUT_CSP(0);
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
- if (data->enc_in_format == data->enc_out_format) {
- if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
- (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
- value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
- hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
- hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
- m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
- v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
- v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
- return 0;
- }
+ if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+ value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+ hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+ hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+ m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+ v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+ v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+ return 0;
}
if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
- if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
- (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+ if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
auto_csc = AUTO_CSC_DISABLE;
c0_c2_change = C0_C2_CHANGE_DISABLE;
csc_enable = v_CSC_ENABLE;
- } else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
- (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
- csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
- auto_csc = AUTO_CSC_ENABLE;
- c0_c2_change = C0_C2_CHANGE_DISABLE;
- csc_enable = v_CSC_DISABLE;
}
} else {
- if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
- (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+ if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
auto_csc = AUTO_CSC_DISABLE;
c0_c2_change = C0_C2_CHANGE_DISABLE;
csc_enable = v_CSC_ENABLE;
- } else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
- (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
- csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
- auto_csc = AUTO_CSC_ENABLE;
- c0_c2_change = C0_C2_CHANGE_DISABLE;
- csc_enable = v_CSC_DISABLE;
}
}
@@ -443,7 +425,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
struct drm_display_info *display = >connector.display_info;
u8 vic = drm_match_cea_mode(mode);
- hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
if (vic == 6 || vic == 7 ||
--
2.43.0
[PATCH v4 21/29] drm/rockchip: inno_hdmi: Don't power up the phy after resetting
inno_hdmi_reset is only ever called when initializing the controller. At this point it’s completely uneccessary to power up the PHY, since all what has to work at this point is the DDC bus. The phy will be powered up correctly when a mode is set in inno_hdmi_encoder_enable and disabled in inno_hdmi_encoder_disable. Set it to LOWER_PWR after resetting the controller. Signed-off-by: Alex Bee --- changes in v3: - new patch changes in v4: - none drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c index f3b90b479ab9..52b49f44a4f4 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -202,7 +202,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi) val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH; hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val); - inno_hdmi_set_pwr_mode(hdmi, NORMAL); + inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR); } static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, -- 2.43.0
[PATCH v4 16/29] drm/rockchip: inno_hdmi: Remove unused drm device pointer
From: Maxime Ripard
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 49367ca24125..51c1a69dfcc0 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -44,7 +44,6 @@ struct inno_hdmi_i2c {
struct inno_hdmi {
struct device *dev;
- struct drm_device *drm_dev;
int irq;
struct clk *pclk;
@@ -757,7 +756,6 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
return -ENOMEM;
hdmi->dev = dev;
- hdmi->drm_dev = drm;
hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hdmi->regs))
--
2.43.0
[PATCH v4 09/29] drm/rockchip: inno_hdmi: Remove unneeded has audio flag
From: Maxime Ripard
The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d99896f1a73a..58aff7a9c09a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
#include "inno_hdmi.h"
struct hdmi_data_info {
- bool sink_has_audio;
unsigned int enc_in_format;
unsigned int enc_out_format;
unsigned int colorimetry;
@@ -554,7 +553,6 @@ static int inno_hdmi_connector_get_modes(struct
drm_connector *connector)
edid = drm_get_edid(connector, hdmi->ddc);
if (edid) {
- hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
--
2.43.0
[PATCH v4 18/29] drm/rockchip: inno_hdmi: Remove useless include
The inclusion syscon.h isn't used anywhere. Remove it. Signed-off-by: Alex Bee Reviewed-by: Maxime Ripard --- changes in v2: - new patch changes in v3: - collect RB changes in v4: - none drivers/gpu/drm/rockchip/inno_hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c index 138cd4287dea..c306db90832a 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -10,7 +10,6 @@ #include #include #include -#include #include #include #include -- 2.43.0
[PATCH v4 04/29] drm/rockchip: inno_hdmi: Remove useless mode_fixup
From: Maxime Ripard
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 345253e033c5..0b1740b38c7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder
*encoder)
inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
}
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adj_mode)
-{
- return true;
-}
-
static int
inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
.enable = inno_hdmi_encoder_enable,
.disable= inno_hdmi_encoder_disable,
- .mode_fixup = inno_hdmi_encoder_mode_fixup,
.mode_set = inno_hdmi_encoder_mode_set,
.atomic_check = inno_hdmi_encoder_atomic_check,
};
--
2.43.0
[PATCH v4 11/29] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
Now that the unneeded support for YUV based input formats is gone, the csc
coefficients for those formats can be dropped as well.
Signed-off-by: Alex Bee
---
changes in v2:
- new patch
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 37
1 file changed, 37 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7c75feedacad..04344ee1265d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -74,49 +74,12 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct
drm_connector *connector)
}
enum {
- CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
- CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
- CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
CSC_RGB_0_255_TO_RGB_16_235_8BIT,
};
static const char coeff_csc[][24] = {
- /*
-* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-* R = 1.164*Y + 1.596*V - 204
-* G = 1.164*Y - 0.391*U - 0.813*V + 154
-* B = 1.164*Y + 2.018*U - 258
-*/
- {
- 0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
- 0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
- 0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
- },
- /*
-* YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-* R = Y + 1.402*V - 248
-* G = Y - 0.344*U - 0.714*V + 135
-* B = Y + 1.772*U - 227
-*/
- {
- 0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
- 0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
- 0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
- },
- /*
-* YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-* R = 1.164*Y + 1.793*V - 248
-* G = 1.164*Y - 0.213*U - 0.534*V + 77
-* B = 1.164*Y + 2.115*U - 289
-*/
- {
- 0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
- 0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
- 0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
- },
-
/*
* RGB2YUV:601 SD mode:
* Cb = -0.291G - 0.148R + 0.439B + 128
--
2.43.0
[PATCH v4 03/29] drm/rockchip: inno_hdmi: Fix video timing
The controller wants the difference between *total and *sync_start in the
HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
certain non-VIC modes. See downstream commit [0].
[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c
Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Co-developed-by: Zheng Yang
Signed-off-by: Zheng Yang
Signed-off-by: Alex Bee
---
changes in v2:
- none
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..345253e033c5 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -412,7 +412,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi
*hdmi,
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
- value = mode->hsync_start - mode->hdisplay;
+ value = mode->htotal - mode->hsync_start;
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
@@ -427,7 +427,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi
*hdmi,
value = mode->vtotal - mode->vdisplay;
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
- value = mode->vsync_start - mode->vdisplay;
+ value = mode->vtotal - mode->vsync_start;
hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
value = mode->vsync_end - mode->vsync_start;
--
2.43.0
[PATCH v4 06/29] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
From: Maxime Ripard
The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 14d2ba92a606..48c4f010b260 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -491,22 +491,25 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
}
static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adj_mode)
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
{
+ struct drm_display_mode *adj_mode = _state->adjusted_mode;
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
inno_hdmi_setup(hdmi, adj_mode);
}
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+ struct drm_atomic_state *state)
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
@@ -527,10 +530,10 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
}
static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
- .enable = inno_hdmi_encoder_enable,
- .disable= inno_hdmi_encoder_disable,
- .mode_set = inno_hdmi_encoder_mode_set,
- .atomic_check = inno_hdmi_encoder_atomic_check,
+ .atomic_check = inno_hdmi_encoder_atomic_check,
+ .atomic_enable = inno_hdmi_encoder_enable,
+ .atomic_disable = inno_hdmi_encoder_disable,
+ .atomic_mode_set= inno_hdmi_encoder_mode_set,
};
static enum drm_connector_status
--
2.43.0
[PATCH v4 22/29] drm/rockchip: inno_hdmi: Split power mode setting
This splits setting the power mode of the controller / phy in two
functions. It's done in preparation of setting up the phy based on the
pixelclock.
No functional changes intended.
Signed-off-by: Alex Bee
---
changes in v3:
- new patch
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 54 +---
drivers/gpu/drm/rockchip/inno_hdmi.h | 5 ---
2 files changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 52b49f44a4f4..44c311e7e2d3 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -154,38 +154,31 @@ static void inno_hdmi_sys_power(struct inno_hdmi *hdmi,
bool enable)
hdmi_modb(hdmi, HDMI_SYS_CTRL, m_POWER, v_PWR_OFF);
}
-static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
+static void inno_hdmi_standby(struct inno_hdmi *hdmi)
{
- switch (mode) {
- case NORMAL:
- inno_hdmi_sys_power(hdmi, false);
+ inno_hdmi_sys_power(hdmi, false);
- hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
- hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
-
- hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
- hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
- hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
- hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
- hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
- hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
-
- inno_hdmi_sys_power(hdmi, true);
- break;
+ hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
+ hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
+ hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
+ hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+};
- case LOWER_PWR:
- inno_hdmi_sys_power(hdmi, false);
- hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
- hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
- hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
- hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+{
+ inno_hdmi_sys_power(hdmi, false);
- break;
+ hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
+ hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+ hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+ hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
+ hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
+ hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
+ hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
+ hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
- default:
- DRM_DEV_ERROR(hdmi->dev, "Unknown power mode %d\n", mode);
- }
-}
+ inno_hdmi_sys_power(hdmi, true);
+};
static void inno_hdmi_reset(struct inno_hdmi *hdmi)
{
@@ -202,7 +195,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
- inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+ inno_hdmi_standby(hdmi);
}
static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
@@ -441,6 +434,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
+ inno_hdmi_power_up(hdmi);
+
return 0;
}
@@ -460,7 +455,6 @@ static void inno_hdmi_encoder_enable(struct drm_encoder
*encoder,
return;
inno_hdmi_setup(hdmi, _state->adjusted_mode);
- inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
@@ -468,7 +462,7 @@ static void inno_hdmi_encoder_disable(struct drm_encoder
*encoder,
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
- inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+ inno_hdmi_standby(hdmi);
}
static int
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h
b/drivers/gpu/drm/rockchip/inno_hdmi.h
index 93245b55f967..a7edf3559e60 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.h
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
@@ -10,11 +10,6 @@
#define DDC_SEGMENT_ADDR 0x30
-enum PWR_MODE {
- NORMAL,
- LOWER_PWR,
-};
-
#define HDMI_SCL_RATE (100*1000)
#define DDC_BUS_FREQ_L 0x4b
#define DDC_BUS_FREQ_H 0x4c
--
2.43.0
[PATCH v4 07/29] drm/rockchip: inno_hdmi: Get rid of mode_set
From: Maxime Ripard
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 48c4f010b260..299770e481b7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -490,21 +490,22 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
return 0;
}
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
-{
- struct drm_display_mode *adj_mode = _state->adjusted_mode;
- struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
-
- inno_hdmi_setup(hdmi, adj_mode);
-}
-
static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+
+ conn_state = drm_atomic_get_new_connector_state(state,
>connector);
+ if (WARN_ON(!conn_state))
+ return;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ if (WARN_ON(!crtc_state))
+ return;
+ inno_hdmi_setup(hdmi, _state->adjusted_mode);
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
@@ -533,7 +534,6 @@ static struct drm_encoder_helper_funcs
inno_hdmi_encoder_helper_funcs = {
.atomic_check = inno_hdmi_encoder_atomic_check,
.atomic_enable = inno_hdmi_encoder_enable,
.atomic_disable = inno_hdmi_encoder_disable,
- .atomic_mode_set= inno_hdmi_encoder_mode_set,
};
static enum drm_connector_status
--
2.43.0
[PATCH v4 15/29] drm/rockchip: inno_hdmi: Switch to infoframe type
From: Maxime Ripard
The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.
This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 10466c2aa520..49367ca24125 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,33 +205,34 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
+ enum hdmi_infoframe_type type)
{
struct drm_connector *connector = >connector;
- if (frame_index != INFOFRAME_AVI) {
+ if (type != HDMI_INFOFRAME_TYPE_AVI) {
drm_err(connector->dev,
- "Unsupported infoframe type: %u\n", frame_index);
+ "Unsupported infoframe type: %u\n", type);
return;
}
- hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+ hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
}
static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
- union hdmi_infoframe *frame, u32 frame_index)
+ union hdmi_infoframe *frame, enum
hdmi_infoframe_type type)
{
struct drm_connector *connector = >connector;
u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
ssize_t rc, i;
- if (frame_index != INFOFRAME_AVI) {
+ if (type != HDMI_INFOFRAME_TYPE_AVI) {
drm_err(connector->dev,
- "Unsupported infoframe type: %u\n", frame_index);
+ "Unsupported infoframe type: %u\n", type);
return 0;
}
- inno_hdmi_disable_frame(hdmi, frame_index);
+ inno_hdmi_disable_frame(hdmi, type);
rc = hdmi_infoframe_pack(frame, packed_frame,
sizeof(packed_frame));
@@ -255,7 +256,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
>connector,
mode);
if (rc) {
- inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+ inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
return rc;
}
@@ -266,7 +267,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
- return inno_hdmi_upload_frame(hdmi, , INFOFRAME_AVI);
+ return inno_hdmi_upload_frame(hdmi, , HDMI_INFOFRAME_TYPE_AVI);
}
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
--
2.43.0
[PATCH v4 14/29] drm/rockchip: inno_hdmi: Move infoframe disable to separate function
From: Maxime Ripard
The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.
In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it obvious what
we are doing in the error path.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 46 ++--
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 5c9f1325441f..10466c2aa520 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,34 +205,44 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
- union hdmi_infoframe *frame, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
{
struct drm_connector *connector = >connector;
if (frame_index != INFOFRAME_AVI) {
drm_err(connector->dev,
"Unsupported infoframe type: %u\n", frame_index);
- return 0;
+ return;
}
hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+}
- if (setup_rc >= 0) {
- u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
- ssize_t rc, i;
-
- rc = hdmi_infoframe_pack(frame, packed_frame,
-sizeof(packed_frame));
- if (rc < 0)
- return rc;
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
+ union hdmi_infoframe *frame, u32 frame_index)
+{
+ struct drm_connector *connector = >connector;
+ u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+ ssize_t rc, i;
- for (i = 0; i < rc; i++)
- hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
- packed_frame[i]);
+ if (frame_index != INFOFRAME_AVI) {
+ drm_err(connector->dev,
+ "Unsupported infoframe type: %u\n", frame_index);
+ return 0;
}
- return setup_rc;
+ inno_hdmi_disable_frame(hdmi, frame_index);
+
+ rc = hdmi_infoframe_pack(frame, packed_frame,
+sizeof(packed_frame));
+ if (rc < 0)
+ return rc;
+
+ for (i = 0; i < rc; i++)
+ hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+ packed_frame[i]);
+
+ return 0;
}
static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -244,6 +254,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
rc = drm_hdmi_avi_infoframe_from_display_mode(,
>connector,
mode);
+ if (rc) {
+ inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+ return rc;
+ }
if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
@@ -252,7 +266,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
- return inno_hdmi_upload_frame(hdmi, rc, , INFOFRAME_AVI);
+ return inno_hdmi_upload_frame(hdmi, , INFOFRAME_AVI);
}
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
--
2.43.0
[PATCH v4 01/29] dt-bindings: display: rockchip, inno-hdmi: Document RK3128 compatible
The integration for this SoC is different from the currently existing: It needs it's PHY's reference clock rate to calculate the DDC bus frequency correctly. The controller is also part of a powerdomain, so this gets added as an mandatory property for this variant. Signed-off-by: Alex Bee Reviewed-by: Conor Dooley --- changes in v2: - clarify that the controller itself is part of the powerdomain - simplify clock-names - made power-domains property only allowed (and required) for new variant changes in v3: - collect RB changes in v4: - none .../display/rockchip/rockchip,inno-hdmi.yaml | 40 ++- 1 file changed, 38 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml index 96889c86849a..be78dcfa1c76 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml @@ -14,6 +14,7 @@ properties: compatible: enum: - rockchip,rk3036-inno-hdmi + - rockchip,rk3128-inno-hdmi reg: maxItems: 1 @@ -22,10 +23,19 @@ properties: maxItems: 1 clocks: -maxItems: 1 +minItems: 1 +items: + - description: The HDMI controller main clock + - description: The HDMI PHY reference clock clock-names: -const: pclk +minItems: 1 +items: + - const: pclk + - const: ref + + power-domains: +maxItems: 1 ports: $ref: /schemas/graph.yaml#/properties/ports @@ -55,6 +65,32 @@ required: - pinctrl-names - ports +allOf: + - if: + properties: +compatible: + contains: +const: rockchip,rk3036-inno-hdmi + +then: + properties: +power-domains: false + + - if: + properties: +compatible: + contains: +const: rockchip,rk3128-inno-hdmi + +then: + properties: +clocks: + minItems: 2 +clock-names: + minItems: 2 + required: +- power-domains + additionalProperties: false examples: -- 2.43.0
[PATCH v4 05/29] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
From: Maxime Ripard
The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0b1740b38c7b..14d2ba92a606 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -62,7 +62,6 @@ struct inno_hdmi {
unsigned int tmds_rate;
struct hdmi_data_info hdmi_data;
- struct drm_display_mode previous_mode;
};
static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -498,9 +497,6 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder
*encoder,
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
inno_hdmi_setup(hdmi, adj_mode);
-
- /* Store the display mode for plugin/DPMS poweron events */
- drm_mode_copy(>previous_mode, adj_mode);
}
static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
--
2.43.0
[PATCH v4 02/29] drm/rockchip: vop: Add output selection registers for RK312x
In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.
In order to support that, this splits output from RK3036 and defines an
separate one for RK3126 with the registers required to enable the
appropriate output and setup the correct polarity.
Signed-off-by: Alex Bee
---
changes in v2:
- rephrase commit message
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 -
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index c51ca82320cb..b9ee02061d5b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -227,11 +227,22 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
.type = DRM_PLANE_TYPE_CURSOR },
};
+static const struct vop_output rk3126_output = {
+ .pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+ .hdmi_pin_pol = VOP_REG(RK3126_INT_SCALER, 0x7, 4),
+ .hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+ .hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
+ .rgb_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 24),
+ .rgb_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 25),
+ .mipi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 28),
+ .mipi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 29),
+};
+
static const struct vop_data rk3126_vop = {
.intr = _intr,
.common = _common,
.modeset = _modeset,
- .output = _output,
+ .output = _output,
.win = rk3126_vop_win_data,
.win_size = ARRAY_SIZE(rk3126_vop_win_data),
.max_output = { 1920, 1080 },
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 406e981c75bd..fbf1bcc68625 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -872,6 +872,9 @@
/* rk3036 register definition end */
/* rk3126 register definition */
+#define RK3126_INT_SCALER 0x0c
+
+/* win1 register */
#define RK3126_WIN1_MST0x4c
#define RK3126_WIN1_DSP_INFO 0x50
#define RK3126_WIN1_DSP_ST 0x54
--
2.43.0
[PATCH v4 00/29] Add HDMI support for RK3128
This is version 4 of my series that aims to add support for the display controller (VOP) and the HDMI controller block of RK3128 (which is very similar to the one found in RK3036). The original intention of this series was to add support for this slightly different integration but is by now, driven by maintainer's feedback, exploded to be a rework of inno-hdmi driver in large parts. It is, however, a change for the better. The VOP part is very simple - everything we need for HDMI support is already there. I only needed to split the output selection registers from RK3036. The VOP has an IOMMU attached, but it has a serious silicon bug: Registers can only be written, but not be read. As it's not possible to use it with the IOMMU driver in it's current state I'm not adding it here and we have to live with CMA for now - which works fine also. I got response from the vendor, that there is no possibility to read the registers and an workaround must be implemented in software in order to use it. The inno-hdmi driver currently gets a lot of attention [0-2] and I'm hooking in now also. As requested I incorporated some of Maxime's series [0] (and tested them). I have intentionally not removed any code dealing with output format conversion in this series. In contrast to the input format, which is always RGB on this platform and certainly can be dropped, that can be implemented later. And secondly I need the conversion for RGB full range to RGB limited range for this series. I did also some smaller driver cleanups from my side and implemented a custom connector state which now holds the data that belongs there and it is not longer in the device structure and, of course, addressed the feedback from v1 [3] and v2 [4]. There hasn't been any feedback to v3[5] so far, but I fixed an issue with the new custom connector reset hook: If there is a connector state already it needs to be destroyed in there as well. Please see individual patches for detailed changelog. Note: Patches are based and tested on next-20231213. [0] https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-0-6538e19d6...@kernel.org [1] https://lore.kernel.org/all/20231204123315.28456-1-keith.z...@starfivetech.com [2] https://lore.kernel.org/all/2601b669-c570-f39d-8cf9-bff56c939...@gmail.com [3] https://lore.kernel.org/all/20231213195125.212923-1-knaerz...@gmail.com/ [4] https://lore.kernel.org/all/20231216162639.125215-1-knaerz...@gmail.com/ [5] https://lore.kernel.org/all/20231219170100.188800-1-knaerz...@gmail.com/ Alex Bee (17): dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible drm/rockchip: vop: Add output selection registers for RK312x drm/rockchip: inno_hdmi: Fix video timing drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents drm/rockchip: inno_hdmi: Drop irq struct member drm/rockchip: inno_hdmi: Remove useless include drm/rockchip: inno_hdmi: Subclass connector state drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range drm/rockchip: inno_hdmi: Don't power up the phy after resetting drm/rockchip: inno_hdmi: Split power mode setting drm/rockchip: inno_hdmi: Add variant support drm/rockchip: inno_hdmi: Add RK3128 support drm/rockchip: inno_hdmi: Add basic mode validation drm/rockchip: inno_hdmi: Drop custom fill_modes hook ARM: dts: rockchip: Add display subsystem for RK3128 ARM: dts: rockchip: Add HDMI node for RK3128 ARM: dts: rockchip: Enable HDMI output for XPI-3128 Maxime Ripard (12): drm/rockchip: inno_hdmi: Remove useless mode_fixup drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode drm/rockchip: inno_hdmi: Switch encoder hooks to atomic drm/rockchip: inno_hdmi: Get rid of mode_set drm/rockchip: inno_hdmi: no need to store vic drm/rockchip: inno_hdmi: Remove unneeded has audio flag drm/rockchip: inno_hdmi: Remove useless input format drm/rockchip: inno_hdmi: Remove tmds rate from structure drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support drm/rockchip: inno_hdmi: Move infoframe disable to separate function drm/rockchip: inno_hdmi: Switch to infoframe type drm/rockchip: inno_hdmi: Remove unused drm device pointer .../display/rockchip/rockchip,inno-hdmi.yaml | 40 +- .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 + arch/arm/boot/dts/rockchip/rk3128.dtsi| 60 ++ drivers/gpu/drm/rockchip/inno_hdmi.c | 549 +++--- drivers/gpu/drm/rockchip/inno_hdmi.h | 5 - drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +- drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 3 + 7 files changed, 484 insertions(+), 215 deletions(-) base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e -- 2.43.0
Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate
Dne petek, 22. december 2023 ob 10:10:25 CET je Frank Oltmanns napisal(a):
>
> On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote:
> > Ok, I've done more detailed testing, and it seems this patch results in
> > lots of dropped frames. I'm sorry for not being more thorough earlier.
> > I'll do some more testing without this patch and might have to either
> > remove it from V2 of this series.
> >
> > I need to see if the same stability can be achieved when running
> > PLL-MIPI outside its specied range.
>
> I've done some more (load) testing and observing the panel for dropped
> frames.
>
> The conclusion I draw from those results is that this patch isn't
> necessary for the pinephone. It would be enough to use the correct clock
> rate based on the existing values [*]:
> - .clock = 69000,
> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
>
> I've asked in the postmarketOS community for a bit more testing. They
> already have a merge request that contains these changes [2].
This patch sounds reasonable and IMO should be merged.
Best regards,
Jernej
>
> This means that we would continue to drive PLL-MIPI outside it's
> specified range. I have, so far, not experienced any downside of doing
> so. It seems enough to fix the ratios that are part of the first four
> patches in this series without introducing a min and max rate.
>
> In conclusion, I'll soon (after some more feedback from the fine folks
> at postmarketOS) submit a V2 that addresses the fixes requested in the
> first four patches of this series. I'll drop the existing PATCH 5 and
> replace it with the one I sent in February [1] instead.
>
> After that, just for fun, I'll probably look into min_rate and max_rate
> for nkm clocks and which consequences it has on the pinephone. I might
> or might not send a follow up series for that. However, if the pinephone
> runs stable without it, it's not a high priority for me.
>
> Best regards,
> Frank
>
> [*] I've already submitted a patch in February '23 [1]. It was of little
> use back then because the A64's PLL-MIPI clock was not able to run
> close to that rate. But since kernel 6.6 PLL-MIPI is able to set
> it's parent rate, so that it can come quite close to the required
> rate:
> + Panel requires 74.844 MHz with the current timings.
> +-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4).
> +-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4)
>
> The 6.6 kernel the following rates are possible:
> + PLL-MIPI: ~448.984615 MHz
> +-> tcon-data-clock: ~112.246153
> +-> panel: ~74.830768 MHz
>
> Which leaves us with a vertical refresh rate of ~59.989 Hz,
> deviating less then 0.2% from the ideal 60Hz. That's probably closer
> than the accumulated accuracy of all involved components can
> reliably achieve. I'd say, let's leave it at that.
>
> [1]: https://lore.kernel.org/lkml/20230219114553.288057-2-fr...@oltmanns.dev/
> [2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645
> >
> > Best regards,
> > Frank
> >
> > On 2023-12-20 at 16:18:49 +0100, Jernej Škrabec
> > wrote:
> >> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
> >>>
> >>> On 2023-12-19 at 18:04:29 +0100, Jernej Škrabec
> >>> wrote:
> >>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns
> >>> > napisal(a):
> >>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
> >>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
> >>> >> than 500 MHz.
> >>> >>
> >>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
> >>> >> that is high enough to drive PLL-MIPI within its limits.
> >>> >>
> >>> >> Signed-off-by: Frank Oltmanns
> >>> >
> >>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
> >>> > minimum frequency limit in clock driver. If you add it, clock framework
> >>> > should find rate that is high enough and divisible with target rate.
> >>>
> >>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
> >>> this panel has to run exactly at 6 * panel clock. Let me start by
> >>> showing the relevant part of the clock tree (this is on the pinephone
> >>> after applying the patches):
> >>> pll-video0 39360
> >>>pll-mipi500945454
> >>> tcon0500945454
> >>> tcon-data-clock 125236363
> >>>
> >>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
> >>> rate [1]. It's a fixed divisor
> >>>
> >>> The panel I'm proposing to change is defined as this:
> >>>
> >>> static const struct st7703_panel_desc xbd599_desc = {
> >>> .mode = _mode,
> >>> .lanes = 4,
> >>> .mode_flags = MIPI_DSI_MODE_VIDEO |
> >>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> >>> .format = MIPI_DSI_FMT_RGB888,
> >>> .init_sequence =
Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
On 2023-12-20 18:25, John Paul Adrian Glaubitz wrote: Hi Sam, On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote: The leon3_generic machine is maintained by different people so I'd suggest contacting them: see [1] for their contact details. I see there is an avocado boot test for the leon3_generic machine included within the QEMU source tree, but it uses a downloadable image of HelenOS rather than Linux. Thanks for the pointer, I will try to reach out to them when I have something a bit more solid than "it does not work". I tried to hack around a little in qemu and I have an idea where things goes wrong. The leon_generic assumes another address layout than what is used by the kernel, so the very first jump to a kernel address fails. The MKLINUXIMG second stage bootloader sets up MMU tables and the SPARC OPENPROM interface for LEON systems, so you need to run the vmlinux image through that. You can find it (and our other Linux related releases) via https://gaisler.com/index.php/downloads/linux. The manual is at https://www.gaisler.com/doc/mklinuximg.pdf and the latest release at https://gaisler.com/anonftp/linux/linux-2.6/kernel/mklinuximg-2.0.15.tar.bz2 With a sparc-linux-gcc in the PATH (or using CROSS_COMPILE to point out a toolchain stem) you can do: mklinuximg vmlinux image.ram and then run the resulting image.ram in e.g. QEMU 8.2.0 with qemu-system-sparc -nographic -M leon3_generic -m 256 -kernel image.ram This at least boots the kernel and let me log in when quickly testing a few images with root filesystems in initramfs, admittedly with our kernel patches in place. I would argue that before we start introducing larger changes to arch/sparc, we should settle the maintainership question first. Once we have an active maintainer again, we can have a more extended discussion about what to keep and how to name things. I agree. Cheers, Andreas
Re: [RFC PATCH 2/2] dt-bindings: display: msm: mass-rename files
On 12/22/2023 5:08 AM, Rob Herring wrote:
On Thu, 21 Dec 2023 12:25:06 +0200, Dmitry Baryshkov wrote:
Rename the Qualcomm MSM Display schemas to follow the main compatible
string instead of just using the block type. This follows the
established practice for YAML file names.
Cc: Aiqun Yu (Maria)
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
.../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
.../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
.../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} | 2 +-
.../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/display/msm/{gmu.yaml =>
qcom,adreno-gmu.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{gpu.yaml =>
qcom,adreno.yaml} (99%)
rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml =>
qcom,hdmi-tx.yaml} (98%)
rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml =>
qcom,mdp4.yaml} (97%)
rename Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml
=> qcom,mdss-dsi-ctrl.yaml} (99%)
Acked-by: Rob Herring
Nice to see names get more unified!
--
Thx and BRs,
Aiqun(Maria) Yu
[PATCH 6/6] dt-bindings: display: rockchip: dw-hdmi: Add missing sound-dai-cells property
The sound-dai-cells property is used, e.g. in rk356x.dtsi
Signed-off-by: Manuel Traut
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 7e59dee15a5f..43250255fb6f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -94,6 +94,9 @@ properties:
- const: default
- const: unwedge
+ '#sound-dai-cells':
+const: 0
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -145,6 +148,7 @@ examples:
interrupts = ;
clocks = < PCLK_HDMI_CTRL>, < SCLK_HDMI_HDCP>;
clock-names = "iahb", "isfr";
+#sound-dai-cells = <0>;
ports {
port {
--
2.43.0
[v1 2/2] drm/panel: Add support for Truly NT36672E panel driver
Add support for the 1080x2408 Truly NT36672E video mode
DSI panel driver.
Signed-off-by: Ritesh Kumar
---
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-truly-nt36672e.c | 644 +++
3 files changed, 654 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-truly-nt36672e.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..25ef55edeff7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -817,6 +817,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_TRULY_NT36672E
+ tristate "Truly NT36672E"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Truly NT36672E DSI Video
Mode
+ LCD panel module. The panel has a resolution of 1080x2408 and uses 24
bit
+ RGB per pixel.
+
config DRM_PANEL_VISIONOX_RM69299
tristate "Visionox RM69299"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..913643ba298c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_TRULY_NT36672E) += panel-truly-nt36672e.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_VTDR6130) += panel-visionox-vtdr6130.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_R66451) += panel-visionox-r66451.o
diff --git a/drivers/gpu/drm/panel/panel-truly-nt36672e.c
b/drivers/gpu/drm/panel/panel-truly-nt36672e.c
new file mode 100644
index ..bef5139225a5
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-truly-nt36672e.c
@@ -0,0 +1,644 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+static const char * const regulator_names[] = {
+ "vddi",
+ "avdd",
+ "avee",
+};
+
+static const unsigned long regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10,
+};
+
+static const unsigned long regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100,
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ u32 width_mm;
+ u32 height_mm;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+ const char *panel_name;
+ int (*init_sequence)(struct mipi_dsi_device *dsi);
+};
+
+struct truly_nt36672e {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[3];
+ const struct panel_desc *desc;
+};
+
+static inline struct truly_nt36672e *to_truly_nt36672e(struct drm_panel *panel)
+{
+ return container_of(panel, struct truly_nt36672e, panel);
+}
+
+static int truly_nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi)
+{
+ mipi_dsi_dcs_write_seq(dsi, 0xff, 0x10);
+ mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00, 0xaa,
0x02,
+ 0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7, 0x0c,
0xb7);
+
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x1b, 0xa0);
+ mipi_dsi_dcs_write_seq(dsi, 0xff, 0x20);
+ mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0x01, 0x66);
+ mipi_dsi_dcs_write_seq(dsi, 0x06, 0x40);
+ mipi_dsi_dcs_write_seq(dsi, 0x07, 0x38);
+ mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x83);
+ mipi_dsi_dcs_write_seq(dsi, 0x69, 0x91);
+ mipi_dsi_dcs_write_seq(dsi, 0x95, 0xd1);
+ mipi_dsi_dcs_write_seq(dsi, 0x96, 0xd1);
+ mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x64);
+ mipi_dsi_dcs_write_seq(dsi, 0xf3, 0x54);
+ mipi_dsi_dcs_write_seq(dsi, 0xf4, 0x64);
+ mipi_dsi_dcs_write_seq(dsi, 0xf5, 0x54);
+ mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x64);
+ mipi_dsi_dcs_write_seq(dsi, 0xf7, 0x54);
+ mipi_dsi_dcs_write_seq(dsi, 0xf8, 0x64);
+ mipi_dsi_dcs_write_seq(dsi, 0xf9, 0x54);
+ mipi_dsi_dcs_write_seq(dsi, 0xff, 0x24);
+ mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0x01, 0x0f);
+ mipi_dsi_dcs_write_seq(dsi, 0x03, 0x0c);
+ mipi_dsi_dcs_write_seq(dsi, 0x05, 0x1d);
+
[PATCH 5/6] arm64: dts: rockchip: Fix some dtb-check warnings
devicetree checks show some warnings:
video-codec@fdea0400: 'interrupt-names' is a required property
from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
hdmi@fe0a: Unevaluated properties are not allowed ('power-domains' were
unexpected)
from schema $id:
http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m']
from schema $id: http://devicetree.org/schemas/sound/rockchip,i2s-tdm.yaml#
phy@fe87: 'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml#
Fix them by
- setting a interrupt-name for the video-codec
- remove the unevaluated power-domain property from hdmi
- set reset-names according to the spec for i2s
- add a power-domain property for the CSI phy
Signed-off-by: Manuel Traut
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index c19c0f1b3778..651156759582 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -597,6 +597,7 @@ vpu: video-codec@fdea0400 {
compatible = "rockchip,rk3568-vpu";
reg = <0x0 0xfdea 0x0 0x800>;
interrupts = ;
+ interrupt-names = "vdpu";
clocks = < ACLK_VPU>, < HCLK_VPU>;
clock-names = "aclk", "hclk";
iommus = <_mmu>;
@@ -819,7 +820,6 @@ hdmi: hdmi@fe0a {
clock-names = "iahb", "isfr", "cec", "ref";
pinctrl-names = "default";
pinctrl-0 = <_scl _sda _cec>;
- power-domains = < RK3568_PD_VO>;
reg-io-width = <4>;
rockchip,grf = <>;
#sound-dai-cells = <0>;
@@ -1123,7 +1123,7 @@ i2s2_2ch: i2s@fe42 {
dmas = < 4>, < 5>;
dma-names = "tx", "rx";
resets = < SRST_M_I2S2_2CH>;
- reset-names = "m";
+ reset-names = "tx-m", "rx-m";
rockchip,grf = <>;
pinctrl-names = "default";
pinctrl-0 = <_sclktx
@@ -1739,6 +1739,7 @@ csi_dphy: phy@fe87 {
clocks = < PCLK_MIPICSIPHY>;
clock-names = "pclk";
#phy-cells = <0>;
+ power-domains = < RK3568_PD_VO>;
resets = < SRST_P_MIPICSIPHY>;
reset-names = "apb";
rockchip,grf = <>;
--
2.43.0
[PATCH 0/6] arm64: rockchip: Pine64 pinetab2 support
This adds support for the BOE TH101MB31IG002 LCD Panel used in Pinetab2 [1] and Pinetab-V [2] as well as the devictrees for the Pinetab2 v0.1 and v2.0. The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has been adapted and the LCD init section was simplified. The Pinetab2 devicetree patch was retrieved from [4]. Some renaming was needed to pass the dtb-checks, the brightness-levels are specified as range and steps instead of a list of values. The last to patches fix some dtb-checker warnings that showed up with the new device-trees. [1] https://wiki.pine64.org/wiki/PineTab2 [2] https://wiki.pine64.org/wiki/PineTab-V [3] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-driver.patch?ref_type=heads [4] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-device-trees.patch?ref_type=heads Signed-off-by: Manuel Traut --- Manuel Traut (4): dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel dt-bindings: arm64: rockchip: Add Pine64 Pinetab2 arm64: dts: rockchip: Fix some dtb-check warnings dt-bindings: display: rockchip: dw-hdmi: Add missing sound-dai-cells property Segfault (2): drm/panel: Add driver for BOE TH101MB31IG002-28A panel arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2 .../devicetree/bindings/arm/rockchip.yaml |8 + .../display/panel/boe,th101mb31ig002-28a.yaml | 73 ++ .../display/rockchip/rockchip,dw-hdmi.yaml |4 + arch/arm64/boot/dts/rockchip/Makefile |2 + .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 26 + .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 46 + arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 1032 arch/arm64/boot/dts/rockchip/rk356x.dtsi |5 +- drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile |1 + .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c | 307 ++ 11 files changed, 1513 insertions(+), 2 deletions(-) --- base-commit: 24e0d2e527a39f64caeb2e6be39ad5396fb2da5e change-id: 20231222-pinetab2-faa77e01db6f Best regards, -- Manuel Traut
[PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
From: Segfault
This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.
v1.0 is not included as no units are known to exist.
Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display
WiFi is not added, since the driver is not ready for mainline.
Signed-off-by: Segfault
Signed-off-by: Manuel Traut
---
arch/arm64/boot/dts/rockchip/Makefile |2 +
.../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 26 +
.../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 46 +
arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 1032
4 files changed, 1106 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..ef66c0937a9b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
new file mode 100644
index ..ba244545ba26
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+ model = "Pine64 PineTab2 v0.1";
+ compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2",
"rockchip,rk3566";
+};
+
+ {
+ reset-gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ display {
+ lcd0_rst_l: lcd0-rst-l {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_wl {
+ gpio = < RK_PA0 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
new file mode 100644
index ..f401ff802175
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+ model = "Pine64 PineTab2 v2.0";
+ compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2",
"rockchip,rk3566";
+};
+
+_keys {
+ pinctrl-0 = <_id_det>, <_int_l>;
+
+ event-hall-sensor {
+ debounce-interval = <20>;
+ gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
+ label = "Hall Sensor";
+ linux,code = ;
+ linux,input-type = ;
+ wakeup-event-action = ;
+ wakeup-source;
+ };
+};
+
+ {
+ reset-gpios = < RK_PC6 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ display {
+ lcd0_rst_l: lcd0-rst-l {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ hall {
+ hall_int_l: hall-int-l {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_wl {
+ gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
new file mode 100644
index ..6d320cfee338
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -0,0 +1,1032 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rk3566.dtsi"
+
+/ {
+ chassis-type = "tablet";
+
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <25>;
+
+ button-vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <297500>;
+ };
+
+ button-vol-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <1750>;
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 25000 0>;
+ brightness-levels = <20 220>;
+
[PATCH 3/6] dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
Add devicvetree binding documentation for Pine64 Pinetab2 which uses the Rockchip RK3566 SoC. Signed-off-by: Manuel Traut --- Documentation/devicetree/bindings/arm/rockchip.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5f7c6c4aad8f..96d54b0587ab 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -635,6 +635,14 @@ properties: - const: pine64,pinenote - const: rockchip,rk3566 + - description: Pine64 PineTab2 +items: + - enum: + - pine64,pinetab2-v0.1 + - pine64,pinetab2-v2.0 + - const: pine64,pinetab2 + - const: rockchip,rk3566 + - description: Pine64 PinePhonePro items: - const: pine64,pinephone-pro -- 2.43.0
[v1 0/2] Add support for Truly NT36672E LCD DSI panel
Add support for the 1080x2408 Truly NT36672E LCD DSI mode panel found on the Qualcomm QCM6490 MTP board. The driver will come with the uncompressed video mode support. Ritesh Kumar (2): dt-bindings: display: panel: Add Truly NT36672E LCD DSI panel drm/panel: Add support for Truly NT36672E panel driver .../display/panel/truly,nt36672e.yaml | 66 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-truly-nt36672e.c | 644 ++ 4 files changed, 720 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml create mode 100644 drivers/gpu/drm/panel/panel-truly-nt36672e.c -- 2.17.1
[PATCH 1/6] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 Pinetab2 and PinetabV.
Signed-off-by: Manuel Traut
---
.../display/panel/boe,th101mb31ig002-28a.yaml | 73 ++
1 file changed, 73 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index ..a8a5e1b4439b
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A Pine64 Pinetab2 DSI Display Panel
+
+maintainers:
+ - Manuel Traut
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+# BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+ - boe,th101mb31ig002-28a
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ power-supply:
+description: core voltage supply
+
+
+ ports: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - power-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,th101mb31ig002-28a";
+reg = <0>;
+backlight = <_lcd0>;
+enable-gpios = < 45 0>;
+rotation = <90>;
+power-supply = <_3v3>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
+panel_in_dsi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_out_con>;
+};
+};
+};
+};
+};
+
+...
--
2.43.0
[PATCH 2/6] drm/panel: Add driver for BOE TH101MB31IG002-28A panel
From: Segfault
The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 Pinetab2 and PinetabV.
Signed-off-by: Segfault
Signed-off-by: Manuel Traut
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c | 307 +
3 files changed, 319 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..927ddd10e688 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_BOE_TH101MB31UIG002_28A
+ tristate "Boe TH101MB31UIG002-28A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Boe
+ TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+ resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+ interface to the host and has a built-in LED backlight.
+
config DRM_PANEL_BOE_TV101WUM_NL6
tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..dd6e1ac9d0a2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) +=
panel-asus-z00t-tm5p5-n35596.
obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) +=
panel-boe-th101mb31ig002-28a.o
obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index ..ac1dc99a0300
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke
+ * Copyright (c) 2023 Manuel Traut
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct boe_th101mb31ig002 {
+ struct drm_panel panel;
+ bool enabled;
+ bool prepared;
+
+ struct mipi_dsi_device *dsi;
+
+ struct regulator *power;
+ struct gpio_desc *enable;
+ struct gpio_desc *reset;
+
+ enum drm_panel_orientation orientation;
+};
+
+static int boe_th101mb31ig002_disable(struct drm_panel *panel)
+{
+ struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+
+ if (!ctx->enabled)
+ return 0;
+
+ mipi_dsi_dcs_set_display_off(ctx->dsi);
+ msleep(120);
+ ctx->enabled = false;
+
+ return 0;
+}
+
+static int boe_th101mb31ig002_unprepare(struct drm_panel *panel)
+{
+ struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+
+ if (!ctx->prepared)
+ return 0;
+
+ mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+ msleep(220);
+ gpiod_set_value_cansleep(ctx->reset, 1);
+ gpiod_set_value_cansleep(ctx->enable, 0);
+ regulator_disable(ctx->power);
+ ctx->prepared = false;
+
+ return 0;
+}
+
+static int boe_th101mb31ig002_prepare(struct drm_panel *panel)
+{
+ struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ int ret;
+
+ if (ctx->prepared)
+ return 0;
+
+ ret = regulator_enable(ctx->power);
+ if (ret) {
+ dev_err(>dev, "Failed to enable power supply: %d\n", ret);
+ return ret;
+ }
+
+ gpiod_set_value_cansleep(ctx->enable, 1);
+ msleep(120);
+ gpiod_direction_output(ctx->reset, 1);
+ msleep(120);
+ gpiod_direction_output(ctx->reset, 0);
+ msleep(120);
+
+ mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+ mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+ mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+ mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50,
[v1 1/2] dt-bindings: display: panel: Add Truly NT36672E LCD DSI panel
Document Truly NT36672E FHD+ LCD DSI panel.
Signed-off-by: Ritesh Kumar
---
.../display/panel/truly,nt36672e.yaml | 66 +++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml
b/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml
new file mode 100644
index ..39ab05c5b103
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/truly,nt36672e.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Truly NT36672E LCD DSI Panel
+
+maintainers:
+ - Ritesh Kumar
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: truly,nt36672e
+
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ vddi-supply: true
+ avdd-supply: true
+ avee-supply: true
+ port: true
+ reset-gpios: true
+ backlight: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vddi-supply
+ - avdd-supply
+ - avee-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+#include
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "truly,nt36672e";
+reg = <0>;
+
+reset-gpios = < 44 GPIO_ACTIVE_HIGH>;
+
+vddi-supply = <_l8c_1p8>;
+avdd-supply = <_avdd>;
+avee-supply = <_avee>;
+
+backlight = <_backlight>;
+
+port {
+panel0_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+...
--
2.17.1
Re: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> +
> + {
> + assigned-clocks = < PLL_GPLL>, < PLL_PPLL>, <
> PLL_VPLL>; + assigned-clock-rates = <12>, <2>,
> <5>; +};
Attachment seem to work and for this I also have the attached patch in my
patch set.
IIRC without it you get an error in dmesg immediately at boot up which is
visible on the PT2 *if* you have immediate visual output (which is not (yet?)
the case in my image/kernel).
Cheers,
Diederik>From d782a64f3b51ffb2f33d3ba3e11e2ebc416542e3 Mon Sep 17 00:00:00 2001
From: Jonas Karlman
Date: Thu, 17 Aug 2023 17:52:47 +0200
Subject: [PATCH 6/8] arm64: dts: rk3566-pinetab2: Fix cru assigned clocks
Jonas Karlman provided/linked to the patch on IRC.
Seems related to upstream commit 64b69474edf3b885c19a89bb165f978ba1b4be00.
Signed-off-by: Diederik de Haas
Link: https://github.com/Kwiboo/u-boot-rockchip/blob/rk3568-2023.10/arch/arm/dts/rk3566-pinetab2-u-boot.dtsi#L11-L15
Link: https://lore.kernel.org/all/20230110225547.1563119-2-jo...@kwiboo.se/
---
arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
index bbd7ed53602a..4a5bee5a28a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -288,8 +288,9 @@ {
};
{
- assigned-clocks = < PLL_GPLL>, < PLL_PPLL>, < PLL_VPLL>;
- assigned-clock-rates = <12>, <2>, <5>;
+ assigned-clocks = < CLK_RTC_32K>, < PLL_GPLL>, < PLL_PPLL>, < PLL_VPLL>;
+ assigned-clock-rates = <32768>, <12>, <2>, <5>;
+ assigned-clock-parents = < CLK_RTC32K_FRAC>;
};
_dphy {
--
2.42.0
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> + rk817-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <_det_l>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "PineTab2";
> + simple-audio-card,mclk-fs = <256>;
> +
> + simple-audio-card,widgets =
> + "Microphone", "Mic Jack",
> + "Headphone", "Headphones",
> + "Microphone", "Microphone",
> + "Speaker", "Speakers";
> +
> + simple-audio-card,routing =
> + "MICL", "Microphone",
> + "MICR", "Mic Jack",
> + "Headphones", "HPOL",
> + "Headphones", "HPOR",
> + "Speaker Amplifier INL", "HPOL",
> + "Speaker Amplifier INR", "HPOR",
> + "Speakers", "Speaker Amplifier OUTL",
> + "Speakers", "Speaker Amplifier OUTR";
> +
> + simple-audio-card,hp-det-gpio = < RK_PC6
> GPIO_ACTIVE_HIGH>; + simple-audio-card,aux-devs =
> <_amp>;
> + simple-audio-card,pin-switches = "Speakers", "Microphone";
> +
> + simple-audio-card,cpu {
> + sound-dai = <_8ch>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <>;
> + };
> + };
Not sure if it's right (or allowed) to post a different patch as attachment,
but I have been using a different audio configuration (see attachment).
I haven't yet tried if/how it works via HDMI yet, but the speakers and
headphones work fine.
This patch is based on the following commit:
https://github.com/TuxThePenguin0/linux/commit/
872b829a3511cfa853bd3af3bd4f30be1cb3d1ab
I've added 'Danct12' to the To list as they are the maintainer of the primary
PT2 image and we worked together to get to this audio config.
I don't if they still use it.
(I've been using my own kernel/image for a while now).
Cheers,
Diederik>From 17efeb0ae766886345ff0574c534079742539b56 Mon Sep 17 00:00:00 2001
From: Scott Santucci
Date: Mon, 17 Jul 2023 13:06:20 +0200
Subject: [PATCH 3/8] arm64: dts: rk3566-pinetab2: Fix audio configuration
The audio configuration of the PineTab2 matches the `rk817_ext` alsa
ucm2 profile, so switch the configuration to that. Use `rk817_ext` and
not `rk817_int` as the PineTab2 uses an external amplifier.
Also the headphones plugged/unplugged detection is backwards, so apply
the fix provided by Danct12 .
Signed-off-by: Diederik de Haas
Link: https://github.com/dreemurrs-embedded/Pine64-Arch/pull/555
---
arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
index a766f21bd6f8..59e4bf2f77c7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -116,14 +116,14 @@ rk817-sound {
pinctrl-names = "default";
pinctrl-0 = <_det_l>;
simple-audio-card,format = "i2s";
- simple-audio-card,name = "PineTab2";
+ simple-audio-card,name = "rk817_ext";
simple-audio-card,mclk-fs = <256>;
simple-audio-card,widgets =
"Microphone", "Mic Jack",
"Headphone", "Headphones",
"Microphone", "Microphone",
- "Speaker", "Speakers";
+ "Speaker", "Internal Speakers";
simple-audio-card,routing =
"MICL", "Microphone",
@@ -132,12 +132,12 @@ rk817-sound {
"Headphones", "HPOR",
"Speaker Amplifier INL", "HPOL",
"Speaker Amplifier INR", "HPOR",
- "Speakers", "Speaker Amplifier OUTL",
- "Speakers", "Speaker Amplifier OUTR";
+ "Internal Speakers", "Speaker Amplifier OUTL",
+ "Internal Speakers", "Speaker Amplifier OUTR";
- simple-audio-card,hp-det-gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,hp-det-gpio = < RK_PC6 GPIO_ACTIVE_LOW>;
simple-audio-card,aux-devs = <_amp>;
- simple-audio-card,pin-switches = "Speakers", "Microphone";
+ simple-audio-card,pin-switches = "Internal Speakers", "Microphone";
simple-audio-card,cpu {
sound-dai = <_8ch>;
--
2.42.0
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/6] arm64: rockchip: Pine64 pinetab2 support
On Friday, 22 December 2023 12:05:40 CET Manuel Traut wrote: > [3] > https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/ > mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A- > driver.patch?ref_type=heads > [4] > https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/ > mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-de > vice-trees.patch?ref_type=heads FWIW I believe the actual sources are from https://github.com/TuxThePenguin0/linux/commits/device/pine64-pinetab2_stable signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/6] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
On Friday, 22 December 2023 12:05:41 CET Manuel Traut wrote: > +title: BOE TH101MB31IG002-28A Pine64 Pinetab2 DSI Display Panel s/Pine64 Pinetab2 // ? It is used by the PT2 but I assume it's a 'standalone' panel? signature.asc Description: This is a digitally signed message part.
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: Add the xe repo to drm-tip and the dim tools. For now use the sha1 of the first drm-xe-next pull request for drm-tip, since that branch tip is currently adapted for our CI testing. Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Oded Gabbay Cc: daniel.vet...@ffwll.ch Cc: Maarten Lankhorst Cc: dim-to...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Thomas Hellström Reviewed-by: Lucas De Marchi Lucas De Marchi --- nightly.conf | 7 +++ 1 file changed, 7 insertions(+) diff --git a/nightly.conf b/nightly.conf index 24126b61b797..accd3ff2cc39 100644 --- a/nightly.conf +++ b/nightly.conf @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " +drm_tip_repos[drm-xe]=" +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git +https://gitlab.freedesktop.org/drm/xe/kernel.git +" drm_tip_repos[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel ssh://git.freedesktop.org/git/drm-intel @@ -65,14 +69,17 @@ drm_tip_config=( "drm drm-fixes" "drm-misc drm-misc-fixes" "drm-intel drm-intel-fixes" + "drm-xedrm-xe-fixes" "drm drm-next" "drm-misc drm-misc-next-fixes" "drm-intel drm-intel-next-fixes" + "drm-xedrm-xe-next-fixes" "drm-misc drm-misc-next" "drm-intel drm-intel-next" "drm-intel drm-intel-gt-next" + "drm-xedrm-xe-next b6e1b7081768" "drm-intel topic/core-for-CI" "drm-misc topic/i915-ttm" -- 2.42.0
Re: [PATCH 5/6] arm64: dts: rockchip: Fix some dtb-check warnings
On 22/12/2023 12:05, Manuel Traut wrote:
> devicetree checks show some warnings:
>
> video-codec@fdea0400: 'interrupt-names' is a required property
> from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
>
> hdmi@fe0a: Unevaluated properties are not allowed ('power-domains' were
> unexpected)
> from schema $id:
> http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
>
...
> @@ -819,7 +820,6 @@ hdmi: hdmi@fe0a {
> clock-names = "iahb", "isfr", "cec", "ref";
> pinctrl-names = "default";
> pinctrl-0 = <_scl _sda _cec>;
> - power-domains = < RK3568_PD_VO>;
> reg-io-width = <4>;
> rockchip,grf = <>;
> #sound-dai-cells = <0>;
> @@ -1123,7 +1123,7 @@ i2s2_2ch: i2s@fe42 {
> dmas = < 4>, < 5>;
> dma-names = "tx", "rx";
> resets = < SRST_M_I2S2_2CH>;
> - reset-names = "m";
> + reset-names = "tx-m", "rx-m";
That's not correct. Look at line above. How many entries it has?
Do not fix warnings just to make the warning disappear. Your change here
clearly suggests you did just that.
Best regards,
Krzysztof
Re: [PATCH 6/6] dt-bindings: display: rockchip: dw-hdmi: Add missing sound-dai-cells property
On 22/12/2023 12:05, Manuel Traut wrote: > The sound-dai-cells property is used, e.g. in rk356x.dtsi Better to see here rather explanation why dai cells are needed, unless you aren't sure and just want to fix warning. > > Signed-off-by: Manuel Traut > --- > .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml| 4 > > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > index 7e59dee15a5f..43250255fb6f 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > @@ -94,6 +94,9 @@ properties: >- const: default >- const: unwedge > Please add $ref to dai-common.yaml in allOf. > + '#sound-dai-cells': > +const: 0 > + Best regards, Krzysztof
Re: [git pull] drm fixes for 6.7-rc7
The pull request you sent on Fri, 22 Dec 2023 14:59:38 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-12-22 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8afe6f0e0e257bf7f79f5996c037e8977dcc8cc1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 3/6] dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
On 22/12/2023 12:05, Manuel Traut wrote: > Add devicvetree binding documentation for Pine64 Pinetab2 > which uses the Rockchip RK3566 SoC. > > Signed-off-by: Manuel Traut > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/6] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
On 22/12/2023 12:05, Manuel Traut wrote:
> Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
> used e.g. in the Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Manuel Traut
> ---
> +
> +maintainers:
> + - Manuel Traut
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> +# BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
> + - boe,th101mb31ig002-28a
> +
> + reg:
reg: true
> +description: the virtual channel number of a DSI peripheral
> +
> + backlight:
: true
> +description: phandle of the backlight device attached to the panel
Because there is really no need to repeat obvious.
> +
> + enable-gpios:
> +description: a GPIO spec for the enable pin
Ditto
> +
> + power-supply:
> +description: core voltage supply
Ditto
> +
> +
And drop redundant blank lines.
> + ports: true
Hm, why ports? From where did you copy it?
> + rotation: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - power-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "boe,th101mb31ig002-28a";
> +reg = <0>;
> +backlight = <_lcd0>;
> +enable-gpios = < 45 0>;
Use define for GPIO flag.
Best regards,
Krzysztof
Re: [PATCH 0/2] drm/bridge: start moving towards struct drm_edid
On Fri, 22 Dec 2023, Jani Nikula wrote: > On Fri, 22 Dec 2023, Neil Armstrong wrote: >> On 19/12/2023 13:15, Jani Nikula wrote: >>> On Tue, 14 Nov 2023, Jani Nikula wrote: On Thu, 26 Oct 2023, Jani Nikula wrote: > This is just the first two patches of a lengthy series that I'm not > really sure how to proceed with. Basically the series converts all of > drm/bridge to the new struct drm_edid infrastructure. It's safer than > struct edid, because it contains meta information about the allocated > size of the EDID, instead of relying on the size (number of extensions) > originating from outside of the kernel. > > The rest is at [1]. The commit messages are lacking, and I don't really > have the toolchain to even build test most of it. But I think this is > where drm/bridge should go. Among all of drm, I think bridge has the > most uses of struct edid that do not originate from the drm_get_edid() > family of functions, which means the validity checks are somewhat > inconsistent, and having the meta information is more crucial. > > Bridge maintainers, please instruct how to best proceed with this. Ping. >>> >>> Ping. >> >> Sorry for the delay, I would have preferred changing the get_edid to return >> a drm_edid, but I understand the task is too high, could you instead use >> @get_drm_edid instead of @edid_read ? > > edid_read matches the changes in drm_edid.c, going from drm_get_edid() > to drm_edid_read(). > > There's a nice symmetry when ->get_edid() hooks using drm_get_edid() are > converted to ->edid_read() hooks using drm_edid_read(). > >> And perhaps convert one very common bridge to this so we can validate >> the change in CI. > > So I did convert all of bridge over a few months back, and pushed the > branch to [1]. Should I brush that up and send the entire series? I > don't really know what's common and what's not. Okay, I rebased and pushed [1]. Probably doesn't make sense to send a patch bomb like that right now... BR, Jani. [1] https://gitlab.freedesktop.org/jani/linux/-/commits/drm-edid-bridge -- Jani Nikula, Intel
Re: [v1 0/2] Add support for Truly NT36672E LCD DSI panel
On 22/12/2023 12:07, Ritesh Kumar wrote: > Add support for the 1080x2408 Truly NT36672E LCD DSI mode panel Google does not find anything for "Truly NT36672E", so I have some doubts whether you used correct vendor name or product ID. Best regards, Krzysztof
Re: [v1 2/2] drm/panel: Add support for Truly NT36672E panel driver
On 22/12/2023 12:07, Ritesh Kumar wrote: > Add support for the 1080x2408 Truly NT36672E video mode > DSI panel driver. > > Signed-off-by: Ritesh Kumar > --- > drivers/gpu/drm/panel/Kconfig| 9 + > drivers/gpu/drm/panel/Makefile | 1 + Integrate it with existing Novatek driver or at least consult its maintainers what to do. Best regards, Krzysztof
Re: [PATCH] drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer
Hi,
On Fri, Dec 22, 2023 at 2:29 AM Pin-yen Lin wrote:
>
> Hi Douglas,
>
> On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson
> wrote:
> >
> > Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> > parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> > someone manually tries to do an AUX transfer (like via `i2cdump ${bus}
> > 0x50 i`) while the panel is off we don't just get a simple transfer
> > error. Instead, the whole ps8640 gets thrown for a loop and goes into
> > a bad state.
> >
> > Let's put the function to wait for the HPD (and the magical 50 ms
> > after first reset) back in when we're doing an AUX transfer. This
> > shouldn't actually make things much slower (assuming the panel is on)
> > because we should immediately poll and see the HPD high. Mostly this
> > is just an extra i2c transfer to the bridge.
> >
> > Fixes: f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide
> > wait_hpd_asserted() in struct drm_dp_aux")
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > drivers/gpu/drm/bridge/parade-ps8640.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index 541e4f5afc4c..fb5e9ae9ad81 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> > @@ -346,6 +346,11 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux
> > *aux,
> > int ret;
> >
> > pm_runtime_get_sync(dev);
> > + ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000);
> > + if (ret) {
> > + pm_runtime_put_sync_suspend(dev);
> > + return ret;
> > + }
> > ret = ps8640_aux_transfer_msg(aux, msg);
> > pm_runtime_mark_last_busy(dev);
> > pm_runtime_put_autosuspend(dev);
> > --
> > 2.43.0.472.g3155946c3a-goog
> >
>
> I think commit 9294914dd550 ("drm/bridge: parade-ps8640: Link device
> to ensure suspend/resume order") is trying to address the same
> problem, but we see this issue here because the device link is missing
> DL_FLAG_PM_RUNTIME. I prefer to add DL_FLAG_PM_RUNTIME here so we
> don't need to add a _ps8640_wait_hpd_asserted() after every
> pm_runtime_get_*() call.
I disagree. We've had several discussions on the lists about this
topic before, though since I'm technically on vacation right now I'm
not going to go look them up. In general "pm_runtime" is not
sufficient for powering up DRM components. While DRM components can
use pm_runtime themselves (as we are doing here), powering up another
DRM component by grabbing a pm_runtime reference isn't right. There is
a reason for the complexity of the DRM prepare/enable and all the
current debates about the right order to call components in prepare()
just demonstrates further that a simple pm_runtime reference isn't
enough.
It can be noted that, with ${SUBJECT} patch we _aren't_ powering up
the panel. I actually tested two cases on sc7180-lazor. In one case I
just closed the lid, which powered off the panel, but the touchscreen
kept the panel power rail on. In this case with my patch I could still
read the panel EDID. I then hacked the touchscreen off. Now when I
closed the lid I'd get a timeout. This is different than if we tried
to get a pm_runtime reference to the panel.
> As a side note, I've verified both this patch and DL_FLAG_PM_RUNTIME
> in our downstream v5.15 kernel and panel-edp driver. Both of them
> successfully wait for HPD asserted when the timeout used to happen,
> but the panel is black in that situation. That being said, this patch
> still brings us to a better state. Originally, panel_edp_resume()
> would return an error when the timeout occurs, so the panel-edp driver
> is stuck at an unexpected state. With this patch or
> DL_FLAG_PM_RUNTIME, the runtime PM callbacks won't fail and a system
> suspend/resume brings the panel back.
OK. I'm going to shut off email for real this time while I enjoy some
time off. Hopefully the above convinces you. Otherwise I guess we can
continue to debate in mid-January.
-Doug
Re: [v1 1/2] dt-bindings: display: panel: Add Truly NT36672E LCD DSI panel
On 22/12/2023 12:07, Ritesh Kumar wrote: > Document Truly NT36672E FHD+ LCD DSI panel. > > Signed-off-by: Ritesh Kumar > --- > .../display/panel/truly,nt36672e.yaml | 66 +++ > 1 file changed, 66 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml > > diff --git > a/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml > b/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml > new file mode 100644 > index ..39ab05c5b103 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml > @@ -0,0 +1,66 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/truly,nt36672e.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Truly NT36672E LCD DSI Panel > + > +maintainers: > + - Ritesh Kumar > + > +allOf: > + - $ref: panel-common.yaml# > + > +properties: > + compatible: > +const: truly,nt36672e Eee? This is existing Novatek, isn't it? > + > + reg: > +maxItems: 1 > +description: DSI virtual channel > + > + vddi-supply: true > + avdd-supply: true > + avee-supply: true > + port: true > + reset-gpios: true > + backlight: true > + > +additionalProperties: false This goes after required:. Best regards, Krzysztof
Re: [PATCH v3 03/14] drm/panthor: Add the device logical block
On Fri, 22 Dec 2023 13:26:22 +
Liviu Dudau wrote:
> Hi Boris,
>
> On Mon, Dec 04, 2023 at 06:32:56PM +0100, Boris Brezillon wrote:
> > The panthor driver is designed in a modular way, where each logical
> > block is dealing with a specific HW-block or software feature. In order
> > for those blocks to communicate with each other, we need a central
> > panthor_device collecting all the blocks, and exposing some common
> > features, like interrupt handling, power management, reset, ...
> >
> > This what this panthor_device logical block is about.
> >
> > v3:
> > - Add acks for the MIT+GPL2 relicensing
> > - Fix 32-bit support
> > - Shorten the sections protected by panthor_device::pm::mmio_lock to fix
> > lock ordering issues.
> > - Rename panthor_device::pm::lock into panthor_device::pm::mmio_lock to
> > better reflect what this lock is protecting
> > - Use dev_err_probe()
> > - Make sure we call drm_dev_exit() when something fails half-way in
> > panthor_device_reset_work()
> > - Replace CSF_GPU_LATEST_FLUSH_ID_DEFAULT with a constant '1' and a
> > comment to explain. Also remove setting the dummy flush ID on suspend.
> > - Remove drm_WARN_ON() in panthor_exception_name()
> > - Check pirq->suspended in panthor_xxx_irq_raw_handler()
> >
> > Signed-off-by: Boris Brezillon
> > Signed-off-by: Steven Price
> > Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> > Acked-by: Grant Likely # MIT+GPL2
> > relicensing,Linaro
> > Acked-by: Boris Brezillon # MIT+GPL2
> > relicensing,Collabora
> > ---
> > drivers/gpu/drm/panthor/panthor_device.c | 497 +++
> > drivers/gpu/drm/panthor/panthor_device.h | 381 +
> > 2 files changed, 878 insertions(+)
> > create mode 100644 drivers/gpu/drm/panthor/panthor_device.c
> > create mode 100644 drivers/gpu/drm/panthor/panthor_device.h
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> > b/drivers/gpu/drm/panthor/panthor_device.c
> > new file mode 100644
> > index ..40038bac147a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panthor/panthor_device.c
> > @@ -0,0 +1,497 @@
> > +// SPDX-License-Identifier: GPL-2.0 or MIT
> > +/* Copyright 2018 Marty E. Plummer */
> > +/* Copyright 2019 Linaro, Ltd, Rob Herring */
> > +/* Copyright 2023 Collabora ltd. */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include "panthor_sched.h"
> > +#include "panthor_device.h"
> > +#include "panthor_devfreq.h"
> > +#include "panthor_gpu.h"
> > +#include "panthor_fw.h"
> > +#include "panthor_mmu.h"
> > +#include "panthor_regs.h"
> > +
> > +static int panthor_clk_init(struct panthor_device *ptdev)
> > +{
> > + ptdev->clks.core = devm_clk_get(ptdev->base.dev, NULL);
> > + if (IS_ERR(ptdev->clks.core))
> > + return dev_err_probe(ptdev->base.dev,
> > +PTR_ERR(ptdev->clks.core),
> > +"get 'core' clock failed");
> > +
> > + ptdev->clks.stacks = devm_clk_get_optional(ptdev->base.dev, "stacks");
> > + if (IS_ERR(ptdev->clks.stacks))
> > + return dev_err_probe(ptdev->base.dev,
> > +PTR_ERR(ptdev->clks.stacks),
> > +"get 'stacks' clock failed");
> > +
> > + ptdev->clks.coregroup = devm_clk_get_optional(ptdev->base.dev,
> > "coregroup");
> > + if (IS_ERR(ptdev->clks.coregroup))
> > + return dev_err_probe(ptdev->base.dev,
> > +PTR_ERR(ptdev->clks.coregroup),
> > +"get 'coregroup' clock failed");
> > +
> > + drm_info(>base, "clock rate = %lu\n",
> > clk_get_rate(ptdev->clks.core));
> > + return 0;
> > +}
> > +
> > +void panthor_device_unplug(struct panthor_device *ptdev)
> > +{
> > + /* FIXME: This is racy. */
> > + if (drm_dev_is_unplugged(>base))
> > + return;
> > +
> > + drm_WARN_ON(>base, pm_runtime_get_sync(ptdev->base.dev) < 0);
> > +
> > + /* Call drm_dev_unplug() so any access to HW block happening after
> > +* that point get rejected.
> > +*/
> > + drm_dev_unplug(>base);
> > +
> > + /* Now, try to cleanly shutdown the GPU before the device resources
> > +* get reclaimed.
> > +*/
> > + panthor_sched_unplug(ptdev);
> > + panthor_fw_unplug(ptdev);
> > + panthor_mmu_unplug(ptdev);
> > + panthor_gpu_unplug(ptdev);
> > +
> > + pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> > + pm_runtime_put_sync_suspend(ptdev->base.dev);
> > +}
> > +
> > +static void panthor_device_reset_cleanup(struct drm_device *ddev, void
> > *data)
> > +{
> > + struct panthor_device *ptdev = container_of(ddev, struct
> > panthor_device, base);
> > +
> > + cancel_work_sync(>reset.work);
> > + destroy_workqueue(ptdev->reset.wq);
> > +}
> > +
> > +static void panthor_device_reset_work(struct work_struct *work)
> > +{
> > + struct panthor_device *ptdev =
Re: [PATCH 1/3] drm/i915/gt: Support fixed CCS mode
Quoting Andi Shyti (2023-12-21 19:08:22)
> The CCS mode involves assigning CCS engines to slices depending
> on the number of slices and the number of engines the user wishes
> to set.
>
> In this patch, the default CCS setting is established during the
> initial GT settings. It involves assigning only one CCS to all
> the slices.
>
> Based on a patch by Chris Wilson
> and Tejas Upadhyay .
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Niranjana Vishwanathapura
> Cc: Tejas Upadhyay
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -207,6 +207,26 @@ struct intel_gt {
> [MAX_ENGINE_INSTANCE + 1];
> enum intel_submission_method submission_method;
>
> + /*
> +* Track fixed mapping between CCS engines and compute slices.
> +*
> +* In order to w/a HW that has the inability to dynamically load
> +* balance between CCS engines and EU in the compute slices, we have
> to
> +* reconfigure a static mapping on the fly. We track the current CCS
> +* configuration (determined by inspection of the user's engine
> +* selection during execbuf) and compare it against the current
> +* CCS_MODE (which maps CCS engines to compute slices). If there is
> +* only a single engine selected, we can map it to all available
> +* compute slices for maximal single task performance (fast/narrow).
> If
> +* there are more then one engine selected, we have to reduce the
> +* number of slices allocated to each engine (wide/slow), fairly
> +* distributing the EU between the equivalent engines.
> +*/
This comment is outdated as we don't consider execbuf but the sysfs
configuration.
Regards, Joonas
> + struct {
> + struct mutex mutex;
> + u32 mode;
> + } ccs;
> +
> /*
> * Default address space (either GGTT or ppGTT depending on arch).
> *
Re: [PATCH v3 03/14] drm/panthor: Add the device logical block
Hi Boris,
On Mon, Dec 04, 2023 at 06:32:56PM +0100, Boris Brezillon wrote:
> The panthor driver is designed in a modular way, where each logical
> block is dealing with a specific HW-block or software feature. In order
> for those blocks to communicate with each other, we need a central
> panthor_device collecting all the blocks, and exposing some common
> features, like interrupt handling, power management, reset, ...
>
> This what this panthor_device logical block is about.
>
> v3:
> - Add acks for the MIT+GPL2 relicensing
> - Fix 32-bit support
> - Shorten the sections protected by panthor_device::pm::mmio_lock to fix
> lock ordering issues.
> - Rename panthor_device::pm::lock into panthor_device::pm::mmio_lock to
> better reflect what this lock is protecting
> - Use dev_err_probe()
> - Make sure we call drm_dev_exit() when something fails half-way in
> panthor_device_reset_work()
> - Replace CSF_GPU_LATEST_FLUSH_ID_DEFAULT with a constant '1' and a
> comment to explain. Also remove setting the dummy flush ID on suspend.
> - Remove drm_WARN_ON() in panthor_exception_name()
> - Check pirq->suspended in panthor_xxx_irq_raw_handler()
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+GPL2
> relicensing,Collabora
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 497 +++
> drivers/gpu/drm/panthor/panthor_device.h | 381 +
> 2 files changed, 878 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_device.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_device.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> new file mode 100644
> index ..40038bac147a
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -0,0 +1,497 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2018 Marty E. Plummer */
> +/* Copyright 2019 Linaro, Ltd, Rob Herring */
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "panthor_sched.h"
> +#include "panthor_device.h"
> +#include "panthor_devfreq.h"
> +#include "panthor_gpu.h"
> +#include "panthor_fw.h"
> +#include "panthor_mmu.h"
> +#include "panthor_regs.h"
> +
> +static int panthor_clk_init(struct panthor_device *ptdev)
> +{
> + ptdev->clks.core = devm_clk_get(ptdev->base.dev, NULL);
> + if (IS_ERR(ptdev->clks.core))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.core),
> + "get 'core' clock failed");
> +
> + ptdev->clks.stacks = devm_clk_get_optional(ptdev->base.dev, "stacks");
> + if (IS_ERR(ptdev->clks.stacks))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.stacks),
> + "get 'stacks' clock failed");
> +
> + ptdev->clks.coregroup = devm_clk_get_optional(ptdev->base.dev,
> "coregroup");
> + if (IS_ERR(ptdev->clks.coregroup))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.coregroup),
> + "get 'coregroup' clock failed");
> +
> + drm_info(>base, "clock rate = %lu\n",
> clk_get_rate(ptdev->clks.core));
> + return 0;
> +}
> +
> +void panthor_device_unplug(struct panthor_device *ptdev)
> +{
> + /* FIXME: This is racy. */
> + if (drm_dev_is_unplugged(>base))
> + return;
> +
> + drm_WARN_ON(>base, pm_runtime_get_sync(ptdev->base.dev) < 0);
> +
> + /* Call drm_dev_unplug() so any access to HW block happening after
> + * that point get rejected.
> + */
> + drm_dev_unplug(>base);
> +
> + /* Now, try to cleanly shutdown the GPU before the device resources
> + * get reclaimed.
> + */
> + panthor_sched_unplug(ptdev);
> + panthor_fw_unplug(ptdev);
> + panthor_mmu_unplug(ptdev);
> + panthor_gpu_unplug(ptdev);
> +
> + pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> + pm_runtime_put_sync_suspend(ptdev->base.dev);
> +}
> +
> +static void panthor_device_reset_cleanup(struct drm_device *ddev, void *data)
> +{
> + struct panthor_device *ptdev = container_of(ddev, struct
> panthor_device, base);
> +
> + cancel_work_sync(>reset.work);
> + destroy_workqueue(ptdev->reset.wq);
> +}
> +
> +static void panthor_device_reset_work(struct work_struct *work)
> +{
> + struct panthor_device *ptdev = container_of(work, struct
> panthor_device, reset.work);
> + int ret = 0, cookie;
> +
> + if (atomic_read(>pm.state) != PANTHOR_DEVICE_PM_STATE_ACTIVE) {
> + /*
> + * No need for a reset as the device has been (or will be)
> +
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On 12/22/23 13:25, Thomas Hellström wrote: Hi, On 12/22/23 13:01, Jani Nikula wrote: On Fri, 22 Dec 2023, Thomas Hellström wrote: Add the xe repo to drm-tip and the dim tools. For now use the sha1 of the first drm-xe-next pull request for drm-tip, since that branch tip is currently adapted for our CI testing. I guess we'll need xe CI to switch to drm-tip based testing, and then force push drm-xe-next to drop that core-for-CI thing. But I think it's fine. Yes, that's in the plan. However, please first push v6.7-rc6 to drm-xe-fixes and current drm-next to drm-xe-next-fixes as a starting point. AFAICT the branches don't exist yet. Yes, I have that queued-up. Still waiting for the right people to wake up, though, since I'm ATM lacking the right to create those branches in the xe repo. I did a dry-run building drm-tip with these patches s/patches/branches/ ... present in a clone of the xe repo for testing purposes... Other than that, LGTM. Thanks, Thomas BR, Jani. Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Oded Gabbay Cc: daniel.vet...@ffwll.ch Cc: Maarten Lankhorst Cc: dim-to...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Thomas Hellström --- nightly.conf | 7 +++ 1 file changed, 7 insertions(+) diff --git a/nightly.conf b/nightly.conf index 24126b61b797..accd3ff2cc39 100644 --- a/nightly.conf +++ b/nightly.conf @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " +drm_tip_repos[drm-xe]=" +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git +https://gitlab.freedesktop.org/drm/xe/kernel.git +" drm_tip_repos[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel ssh://git.freedesktop.org/git/drm-intel @@ -65,14 +69,17 @@ drm_tip_config=( "drm drm-fixes" "drm-misc drm-misc-fixes" "drm-intel drm-intel-fixes" + "drm-xe drm-xe-fixes" "drm drm-next" "drm-misc drm-misc-next-fixes" "drm-intel drm-intel-next-fixes" + "drm-xe drm-xe-next-fixes" "drm-misc drm-misc-next" "drm-intel drm-intel-next" "drm-intel drm-intel-gt-next" + "drm-xe drm-xe-next b6e1b7081768" "drm-intel topic/core-for-CI" "drm-misc topic/i915-ttm"
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
Hi, On 12/22/23 13:01, Jani Nikula wrote: On Fri, 22 Dec 2023, Thomas Hellström wrote: Add the xe repo to drm-tip and the dim tools. For now use the sha1 of the first drm-xe-next pull request for drm-tip, since that branch tip is currently adapted for our CI testing. I guess we'll need xe CI to switch to drm-tip based testing, and then force push drm-xe-next to drop that core-for-CI thing. But I think it's fine. Yes, that's in the plan. However, please first push v6.7-rc6 to drm-xe-fixes and current drm-next to drm-xe-next-fixes as a starting point. AFAICT the branches don't exist yet. Yes, I have that queued-up. Still waiting for the right people to wake up, though, since I'm ATM lacking the right to create those branches in the xe repo. I did a dry-run building drm-tip with these patches present in a clone of the xe repo for testing purposes... Other than that, LGTM. Thanks, Thomas BR, Jani. Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Oded Gabbay Cc: daniel.vet...@ffwll.ch Cc: Maarten Lankhorst Cc: dim-to...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Thomas Hellström --- nightly.conf | 7 +++ 1 file changed, 7 insertions(+) diff --git a/nightly.conf b/nightly.conf index 24126b61b797..accd3ff2cc39 100644 --- a/nightly.conf +++ b/nightly.conf @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " +drm_tip_repos[drm-xe]=" +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git +https://gitlab.freedesktop.org/drm/xe/kernel.git +" drm_tip_repos[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel ssh://git.freedesktop.org/git/drm-intel @@ -65,14 +69,17 @@ drm_tip_config=( "drm drm-fixes" "drm-misc drm-misc-fixes" "drm-intel drm-intel-fixes" + "drm-xedrm-xe-fixes" "drm drm-next" "drm-misc drm-misc-next-fixes" "drm-intel drm-intel-next-fixes" + "drm-xedrm-xe-next-fixes" "drm-misc drm-misc-next" "drm-intel drm-intel-next" "drm-intel drm-intel-gt-next" + "drm-xedrm-xe-next b6e1b7081768" "drm-intel topic/core-for-CI" "drm-misc topic/i915-ttm"
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Fri, 22 Dec 2023, Thomas Hellström wrote: > Add the xe repo to drm-tip and the dim tools. > For now use the sha1 of the first drm-xe-next pull request for drm-tip, > since that branch tip is currently adapted for our CI testing. I guess we'll need xe CI to switch to drm-tip based testing, and then force push drm-xe-next to drop that core-for-CI thing. But I think it's fine. However, please first push v6.7-rc6 to drm-xe-fixes and current drm-next to drm-xe-next-fixes as a starting point. AFAICT the branches don't exist yet. Other than that, LGTM. BR, Jani. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > Cc: Oded Gabbay > Cc: daniel.vet...@ffwll.ch > Cc: Maarten Lankhorst > Cc: dim-to...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Thomas Hellström > --- > nightly.conf | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/nightly.conf b/nightly.conf > index 24126b61b797..accd3ff2cc39 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip.git > " > +drm_tip_repos[drm-xe]=" > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > +https://gitlab.freedesktop.org/drm/xe/kernel.git > +" > drm_tip_repos[drm-intel]=" > ssh://git.freedesktop.org/git/drm/drm-intel > ssh://git.freedesktop.org/git/drm-intel > @@ -65,14 +69,17 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > + "drm-xe drm-xe-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > + "drm-xe drm-xe-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > + "drm-xe drm-xe-next b6e1b7081768" > > "drm-intel topic/core-for-CI" > "drm-misc topic/i915-ttm" -- Jani Nikula, Intel
[PATCH] drm/tilcdc: request and mapp iomem with devres
tilcdc currently just ioremaps its iomem, without doing the (a bit more
robust) request on the memory first. The devm_ functions provide a handy
way to both request and ioremap the memory with automatic cleanup.
Replace the manual ioremap with the devm_ version.
Suggested-by: Thomas Zimmermann
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 8ebd7134ee21..2ad3f44a6e2d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -182,9 +182,6 @@ static void tilcdc_fini(struct drm_device *dev)
if (priv->clk)
clk_put(priv->clk);
- if (priv->mmio)
- iounmap(priv->mmio);
-
if (priv->wq)
destroy_workqueue(priv->wq);
@@ -201,7 +198,6 @@ static int tilcdc_init(const struct drm_driver *ddrv,
struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct device_node *node = dev->of_node;
struct tilcdc_drm_private *priv;
- struct resource *res;
u32 bpp = 0;
int ret;
@@ -226,17 +222,10 @@ static int tilcdc_init(const struct drm_driver *ddrv,
struct device *dev)
goto init_failed;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to get memory resource\n");
- ret = -EINVAL;
- goto init_failed;
- }
-
- priv->mmio = ioremap(res->start, resource_size(res));
- if (!priv->mmio) {
- dev_err(dev, "failed to ioremap\n");
- ret = -ENOMEM;
+ priv->mmio = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->mmio)) {
+ dev_err(dev, "failed to request / ioremap\n");
+ ret = PTR_ERR(priv->mmio);
goto init_failed;
}
--
2.43.0
[PATCH] nightly.conf: Add the xe repo to drm-tip
Add the xe repo to drm-tip and the dim tools. For now use the sha1 of the first drm-xe-next pull request for drm-tip, since that branch tip is currently adapted for our CI testing. Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Oded Gabbay Cc: daniel.vet...@ffwll.ch Cc: Maarten Lankhorst Cc: dim-to...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Thomas Hellström --- nightly.conf | 7 +++ 1 file changed, 7 insertions(+) diff --git a/nightly.conf b/nightly.conf index 24126b61b797..accd3ff2cc39 100644 --- a/nightly.conf +++ b/nightly.conf @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " +drm_tip_repos[drm-xe]=" +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git +https://gitlab.freedesktop.org/drm/xe/kernel.git +" drm_tip_repos[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel ssh://git.freedesktop.org/git/drm-intel @@ -65,14 +69,17 @@ drm_tip_config=( "drmdrm-fixes" "drm-misc drm-misc-fixes" "drm-intel drm-intel-fixes" + "drm-xe drm-xe-fixes" "drmdrm-next" "drm-misc drm-misc-next-fixes" "drm-intel drm-intel-next-fixes" + "drm-xe drm-xe-next-fixes" "drm-misc drm-misc-next" "drm-intel drm-intel-next" "drm-intel drm-intel-gt-next" + "drm-xe drm-xe-next b6e1b7081768" "drm-intel topic/core-for-CI" "drm-misc topic/i915-ttm" -- 2.42.0
Re: [PATCH] drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer
Hi Douglas,
On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson wrote:
>
> Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> someone manually tries to do an AUX transfer (like via `i2cdump ${bus}
> 0x50 i`) while the panel is off we don't just get a simple transfer
> error. Instead, the whole ps8640 gets thrown for a loop and goes into
> a bad state.
>
> Let's put the function to wait for the HPD (and the magical 50 ms
> after first reset) back in when we're doing an AUX transfer. This
> shouldn't actually make things much slower (assuming the panel is on)
> because we should immediately poll and see the HPD high. Mostly this
> is just an extra i2c transfer to the bridge.
>
> Fixes: f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted()
> in struct drm_dp_aux")
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 541e4f5afc4c..fb5e9ae9ad81 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -346,6 +346,11 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux
> *aux,
> int ret;
>
> pm_runtime_get_sync(dev);
> + ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000);
> + if (ret) {
> + pm_runtime_put_sync_suspend(dev);
> + return ret;
> + }
> ret = ps8640_aux_transfer_msg(aux, msg);
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> --
> 2.43.0.472.g3155946c3a-goog
>
I think commit 9294914dd550 ("drm/bridge: parade-ps8640: Link device
to ensure suspend/resume order") is trying to address the same
problem, but we see this issue here because the device link is missing
DL_FLAG_PM_RUNTIME. I prefer to add DL_FLAG_PM_RUNTIME here so we
don't need to add a _ps8640_wait_hpd_asserted() after every
pm_runtime_get_*() call.
As a side note, I've verified both this patch and DL_FLAG_PM_RUNTIME
in our downstream v5.15 kernel and panel-edp driver. Both of them
successfully wait for HPD asserted when the timeout used to happen,
but the panel is black in that situation. That being said, this patch
still brings us to a better state. Originally, panel_edp_resume()
would return an error when the timeout occurs, so the panel-edp driver
is stuck at an unexpected state. With this patch or
DL_FLAG_PM_RUNTIME, the runtime PM callbacks won't fail and a system
suspend/resume brings the panel back.
Regards,
Pin-yen
[PATCH v4 3/4] dt-bindings: display: Add SSD133x OLED controllers
Add a Device Tree binding schema for the OLED panels based on the
Solomon SSD133x family of controllers.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Rob Herring
---
(no changes since v3)
Changes in v3:
- Move solomon,ssd-common.yaml ref before the properties section and
width/height constraints after the other properties (Conor Dooley).
Changes in v2:
- Unconditionally set the width and height constraints (Conor Dooley).
- Fix indentation in the DTS examples (Krzysztof Kozlowski).
.../bindings/display/solomon,ssd133x.yaml | 57 +++
1 file changed, 57 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
new file mode 100644
index ..e93879b3da5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD133x OLED Display Controllers
+
+maintainers:
+ - Javier Martinez Canillas
+
+allOf:
+ - $ref: solomon,ssd-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - solomon,ssd1331
+
+ solomon,width:
+default: 96
+
+ solomon,height:
+default: 64
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@3c {
+compatible = "solomon,ssd1331";
+reg = <0x3c>;
+reset-gpios = < 7>;
+};
+
+};
+ - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@0 {
+compatible = "solomon,ssd1331";
+reg = <0x0>;
+reset-gpios = < 7>;
+dc-gpios = < 8>;
+spi-max-frequency = <1000>;
+};
+};
--
2.43.0
[PATCH v4 2/4] dt-bindings: display: ssd132x: Add vendor prefix to width and height
Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers")
used the wrong properties for width and height, instead of the correct
"solomon,width" and "solomon,height" properties.
Fix this by adding the vendor prefix to the width and height properties.
Fixes: 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers")
Reported-by: Conor Dooley
Closes:
https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
---
(no changes since v1)
.../devicetree/bindings/display/solomon,ssd132x.yaml | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
index 37975ee61c5a..dd7939989cf4 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
@@ -30,9 +30,9 @@ allOf:
const: solomon,ssd1322
then:
properties:
-width:
+solomon,width:
default: 480
-height:
+solomon,height:
default: 128
- if:
@@ -42,9 +42,9 @@ allOf:
const: solomon,ssd1325
then:
properties:
-width:
+solomon,width:
default: 128
-height:
+solomon,height:
default: 80
- if:
@@ -54,9 +54,9 @@ allOf:
const: solomon,ssd1327
then:
properties:
-width:
+solomon,width:
default: 128
-height:
+solomon,height:
default: 128
unevaluatedProperties: false
--
2.43.0
[PATCH v4 4/4] drm/ssd130x: Add support for the SSD133x OLED controller family
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
matrix OLED panels, add a modesetting pipeline to support the chip family.
The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths
but only the 256-color mode (DRM_FORMAT_RGB332) is implemented for now.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Jocelyn Falempe
---
Changes in v4:
- Fix typo in commit message (Jocelyn Falempe).
drivers/gpu/drm/solomon/ssd130x-i2c.c | 5 +
drivers/gpu/drm/solomon/ssd130x-spi.c | 7 +
drivers/gpu/drm/solomon/ssd130x.c | 370 ++
drivers/gpu/drm/solomon/ssd130x.h | 5 +-
4 files changed, 386 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index f2ccab9c06d9..a047dbec4e48 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -105,6 +105,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = _variants[SSD1327_ID],
},
+ /* ssd133x family */
+ {
+ .compatible = "solomon,ssd1331",
+ .data = _variants[SSD1331_ID],
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ssd130x_of_match);
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 84e035a7ab3f..84bfde31d172 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -142,6 +142,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = _variants[SSD1327_ID],
},
+ /* ssd133x family */
+ {
+ .compatible = "solomon,ssd1331",
+ .data = _variants[SSD1331_ID],
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ssd130x_of_match);
@@ -166,6 +171,8 @@ static const struct spi_device_id ssd130x_spi_table[] = {
{ "ssd1322", SSD1322_ID },
{ "ssd1325", SSD1325_ID },
{ "ssd1327", SSD1327_ID },
+ /* ssd133x family */
+ { "ssd1331", SSD1331_ID },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, ssd130x_spi_table);
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index bef293922b98..447d0c7c88c6 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -119,6 +119,26 @@
#define SSD130X_SET_VCOMH_VOLTAGE 0xbe
#define SSD132X_SET_FUNCTION_SELECT_B 0xd5
+/* ssd133x commands */
+#define SSD133X_SET_COL_RANGE 0x15
+#define SSD133X_SET_ROW_RANGE 0x75
+#define SSD133X_CONTRAST_A 0x81
+#define SSD133X_CONTRAST_B 0x82
+#define SSD133X_CONTRAST_C 0x83
+#define SSD133X_SET_MASTER_CURRENT 0x87
+#define SSD132X_SET_PRECHARGE_A0x8a
+#define SSD132X_SET_PRECHARGE_B0x8b
+#define SSD132X_SET_PRECHARGE_C0x8c
+#define SSD133X_SET_DISPLAY_START 0xa1
+#define SSD133X_SET_DISPLAY_OFFSET 0xa2
+#define SSD133X_SET_DISPLAY_NORMAL 0xa4
+#define SSD133X_SET_MASTER_CONFIG 0xad
+#define SSD133X_POWER_SAVE_MODE0xb0
+#define SSD133X_PHASES_PERIOD 0xb1
+#define SSD133X_SET_CLOCK_FREQ 0xb3
+#define SSD133X_SET_PRECHARGE_VOLTAGE 0xbb
+#define SSD133X_SET_VCOMH_VOLTAGE 0xbe
+
#define MAX_CONTRAST 255
const struct ssd130x_deviceinfo ssd130x_variants[] = {
@@ -180,6 +200,12 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_width = 128,
.default_height = 128,
.family_id = SSD132X_FAMILY,
+ },
+ /* ssd133x family */
+ [SSD1331_ID] = {
+ .default_width = 96,
+ .default_height = 64,
+ .family_id = SSD133X_FAMILY,
}
};
EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
@@ -589,6 +615,117 @@ static int ssd132x_init(struct ssd130x_device *ssd130x)
return 0;
}
+static int ssd133x_init(struct ssd130x_device *ssd130x)
+{
+ int ret;
+
+ /* Set color A contrast */
+ ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_A, 0x91);
+ if (ret < 0)
+ return ret;
+
+ /* Set color B contrast */
+ ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_B, 0x50);
+ if (ret < 0)
+ return ret;
+
+ /* Set color C contrast */
+ ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_C, 0x7d);
+ if (ret < 0)
+ return ret;
+
+ /* Set master current */
+ ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_SET_MASTER_CURRENT, 0x06);
+ if (ret < 0)
+ return ret;
+
+ /* Set column start
[PATCH v4 0/4] drm/solomon: Add support for the SSD133x controller family
Hello, This patch-set adds support for the family of SSD133x Solomon controllers, such as the SSD1331. These are used for RGB Dot Matrix OLED/PLED panels. This is a v4 that addresses issues pointed out in v3: https://lists.freedesktop.org/archives/dri-devel/2023-December/435686.html The patches were tested on a Waveshare SSD1331 display using glmark2-drm, fbcon, fbtests and the retroarch emulator. The binding schema were tested using the `make W=1 dt_binding_check` target. Patch #1 and #2 are fixes for the DT binding schema of the existing SSD130x and SSD132x families. Patch #3 adds a DT binding schema for the SSD133x controllers and patch #4 extends the ssd130x DRM driver to support the SSD133x controller family. Best regards, Javier Changes in v4: - Fix typo in commit message (Jocelyn Falempe). - Add collected tags. Changes in v3: - Move solomon,ssd-common.yaml ref before the properties section and width/height constraints after the other properties (Conor Dooley). Changes in v2: - Unconditionally set the width and height constraints (Conor Dooley). - Fix indentation in the DTS examples (Krzysztof Kozlowski). Javier Martinez Canillas (4): dt-bindings: display: ssd1307fb: Add vendor prefix to width and height dt-bindings: display: ssd132x: Add vendor prefix to width and height dt-bindings: display: Add SSD133x OLED controllers drm/ssd130x: Add support for the SSD133x OLED controller family .../bindings/display/solomon,ssd1307fb.yaml | 20 +- .../bindings/display/solomon,ssd132x.yaml | 12 +- .../bindings/display/solomon,ssd133x.yaml | 57 +++ drivers/gpu/drm/solomon/ssd130x-i2c.c | 5 + drivers/gpu/drm/solomon/ssd130x-spi.c | 7 + drivers/gpu/drm/solomon/ssd130x.c | 370 ++ drivers/gpu/drm/solomon/ssd130x.h | 5 +- 7 files changed, 459 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd133x.yaml -- 2.43.0
[PATCH v4 1/4] dt-bindings: display: ssd1307fb: Add vendor prefix to width and height
The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default
width and height values") used the wrong properties for width and height,
instead of the correct "solomon,width" and "solomon,height" properties.
Fix this by adding the vendor prefix to the width and height properties.
Fixes: 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and
height values")
Reported-by: Conor Dooley
Closes:
https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
---
(no changes since v1)
.../bindings/display/solomon,ssd1307fb.yaml | 20 +--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 3afbb52d1b7f..153ff86fb405 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -131,9 +131,9 @@ allOf:
const: sinowealth,sh1106
then:
properties:
-width:
+solomon,width:
default: 132
-height:
+solomon,height:
default: 64
solomon,dclk-div:
default: 1
@@ -149,9 +149,9 @@ allOf:
- solomon,ssd1305
then:
properties:
-width:
+solomon,width:
default: 132
-height:
+solomon,height:
default: 64
solomon,dclk-div:
default: 1
@@ -167,9 +167,9 @@ allOf:
- solomon,ssd1306
then:
properties:
-width:
+solomon,width:
default: 128
-height:
+solomon,height:
default: 64
solomon,dclk-div:
default: 1
@@ -185,9 +185,9 @@ allOf:
- solomon,ssd1307
then:
properties:
-width:
+solomon,width:
default: 128
-height:
+solomon,height:
default: 39
solomon,dclk-div:
default: 2
@@ -205,9 +205,9 @@ allOf:
- solomon,ssd1309
then:
properties:
-width:
+solomon,width:
default: 128
-height:
+solomon,height:
default: 64
solomon,dclk-div:
default: 1
--
2.43.0
Re: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen wrote: > > > It is protected/shielded/fortified from all the kernel and userspace, > > > but a more familiar word to describe that is inaccessible. > > > "Inaccessible buffer" per se OTOH sounds like a useless concept. > > > > > > It is not secure, because it does not involve security in any way. In > > > fact, given it's so fragile, I'd classify it as mildly opposite of > > > secure, as e.g. clients of a Wayland compositor can potentially DoS the > > > compositor with it by simply sending such a dmabuf. Or DoS the whole > > > system. > > > > I hear what you are saying and DoS is a known problem and attack vector, > > but regardless, we have use cases where we don't want to expose > > information in the clear and where we also would like to have some > > guarantees about correctness. That is where various secure elements and > > more generally security is needed. > > > > So, it sounds like we have two things here, the first is the naming and > > the meaning behind it. I'm pretty sure the people following and > > contributing to this thread can agree on a name that makes sense. Would > > you personally be OK with "restricted" as the name? It sounds like that. > > I would. I'm also just a by-stander, not a maintainer of kernel > anything. I have no power to accept nor reject anything here. I'd also personally be OK with "restricted", I think it's a lot better than "secure". In general I agree with everything Pekka said.
Re: [PATCH v3 4/4] drm/ssd130x: Add support for the SSD133x OLED controller family
Jocelyn Falempe writes: Hello Jocelyn, Thanks a lot for your review! > On 19/12/2023 21:34, Javier Martinez Canillas wrote: >> The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot >> matrix OLED panels, add a modesetting pipeline to support the chip family. >> >> The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths >> but only the former is implemented for now. This is because the 256 color >> depth format matches a fourcc code already present in DRM (RGB8), but the >> 65k pixel format does not match the existing RG16 fourcc code format. >> >> Instead of a R:G:B 5:6:5, the controller expects the 16-bit pixels to be >> R:G:B 6:5:6, and so a new fourcc needs to be added to support this format. > > small typo here, R:G:B 6:5:6 => that's 17 bits > Oh, tanks for pointing that out. It seems to be a typo in the SSD1331 controller datasheet itself: https://cdn-shop.adafruit.com/datasheets/SSD1331_1.2.pdf "Each pixel has 16-bit data. Three sub-pixels for color A, B and C have 6 bits, 5 bits and 6 bits respectively." I blindly copied what the datasheet said without relizing that it was 17 bits indeed! So looking again at "Table 9 - Data bus usage under different bus width and color depth mode" in the datasheet shared above, it seems the format has the same sub-pixel layout than DRM_FORMAT_RGB565. But I tested with that format and the colors were off, and the same for DRM_FORMAT_BGR565. Now, even when only using 256 colors the images are pretty decent as you can see in https://fosstodon.org/@javierm/111591985174504541 I'll reword the commit message and drop the comment about that RGB format and explain that only DRM_FORMAT_RGB332 is supported for now. > other than that, it looks good to me, feel free to add: > Reviewed-by: Jocelyn Falempe > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 0/2] drm/bridge: start moving towards struct drm_edid
On Fri, 22 Dec 2023, Neil Armstrong wrote: > On 19/12/2023 13:15, Jani Nikula wrote: >> On Tue, 14 Nov 2023, Jani Nikula wrote: >>> On Thu, 26 Oct 2023, Jani Nikula wrote: This is just the first two patches of a lengthy series that I'm not really sure how to proceed with. Basically the series converts all of drm/bridge to the new struct drm_edid infrastructure. It's safer than struct edid, because it contains meta information about the allocated size of the EDID, instead of relying on the size (number of extensions) originating from outside of the kernel. The rest is at [1]. The commit messages are lacking, and I don't really have the toolchain to even build test most of it. But I think this is where drm/bridge should go. Among all of drm, I think bridge has the most uses of struct edid that do not originate from the drm_get_edid() family of functions, which means the validity checks are somewhat inconsistent, and having the meta information is more crucial. Bridge maintainers, please instruct how to best proceed with this. >>> >>> Ping. >> >> Ping. > > Sorry for the delay, I would have preferred changing the get_edid to return > a drm_edid, but I understand the task is too high, could you instead use > @get_drm_edid instead of @edid_read ? edid_read matches the changes in drm_edid.c, going from drm_get_edid() to drm_edid_read(). There's a nice symmetry when ->get_edid() hooks using drm_get_edid() are converted to ->edid_read() hooks using drm_edid_read(). > And perhaps convert one very common bridge to this so we can validate > the change in CI. So I did convert all of bridge over a few months back, and pushed the branch to [1]. Should I brush that up and send the entire series? I don't really know what's common and what's not. BR, Jani. > > Neil > >> >>> >>> The two patches posted here could be merged, to add something to build >>> the later commits on gradually. >>> >>> BR, >>> Jani. >>> Thanks, Jani. [1] https://gitlab.freedesktop.org/jani/linux/-/commits/drm-edid-bridge Jani Nikula (2): drm/bridge: add ->edid_read hook and drm_bridge_edid_read() drm/bridge: switch to drm_bridge_read_edid() drivers/gpu/drm/drm_bridge.c | 46 +- drivers/gpu/drm/drm_bridge_connector.c | 16 - include/drm/drm_bridge.h | 33 ++ 3 files changed, 86 insertions(+), 9 deletions(-) >> > -- Jani Nikula, Intel
Re: [PATCH] locking/ww_mutex: Adjust to lockdep nest_lock requirements
0] ? __lock_acquire (kernel/locking/lockdep.c:5055 (discriminator 9)) [ 9.778839][ T10] ? exc_overflow (arch/x86/kernel/traps.c:250) [ 9.778839][ T10] ? __lock_acquire (kernel/locking/lockdep.c:5055 (discriminator 9)) [ 9.778839][ T10] ? kvm_sched_clock_read (arch/x86/kernel/kvmclock.c:91) [ 9.778839][ T10] lock_acquire (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5755) [ 9.778839][ T10] ? stress_inorder_work (kernel/locking/test-ww_mutex.c:457) [ 9.778839][ T10] ? lock_is_held_type (kernel/locking/lockdep.c:5494 kernel/locking/lockdep.c:5824) [ 9.778839][ T10] __ww_mutex_lock+0xb1/0xd84 [ 9.778839][ T10] ? stress_inorder_work (kernel/locking/test-ww_mutex.c:457) [ 9.778839][ T10] ww_mutex_lock (kernel/locking/mutex.c:878) [ 9.778839][ T10] stress_inorder_work (kernel/locking/test-ww_mutex.c:457) [ 9.778839][ T10] process_scheduled_works (kernel/workqueue.c:2630 include/linux/jump_label.h:207 include/trace/events/workqueue.h:108 kernel/workqueue.c:2635 kernel/workqueue.c:2703) [ 9.778839][ T10] worker_thread (include/linux/list.h:373 kernel/workqueue.c:841 kernel/workqueue.c:2785) [ 9.778839][ T10] kthread (kernel/kthread.c:390) [ 9.778839][ T10] ? rescuer_thread (kernel/workqueue.c:2730) [ 9.778839][ T10] ? kthread_complete_and_exit (kernel/kthread.c:341) [ 9.778839][ T10] ret_from_fork (arch/x86/kernel/process.c:153) [ 9.778839][ T10] ? kthread_complete_and_exit (kernel/kthread.c:341) [ 9.778839][ T10] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) [ 9.778839][ T10] entry_INT80_32 (arch/x86/entry/entry_32.S:947) [9.778839][ T10] irq event stamp: 14037 [ 9.778839][ T10] hardirqs last enabled at (14037): irqentry_exit (kernel/entry/common.c:435) [ 9.778839][ T10] hardirqs last disabled at (14036): common_interrupt (arch/x86/kernel/irq.c:247) [ 9.778839][ T10] softirqs last enabled at (8978): __do_softirq (arch/x86/include/asm/preempt.h:27 kernel/softirq.c:400 kernel/softirq.c:582) [ 9.778839][ T10] softirqs last disabled at (8969): do_softirq_own_stack (arch/x86/kernel/irq_32.c:57 arch/x86/kernel/irq_32.c:147) [9.778839][ T10] ---[ end trace ]--- [9.917906][ T36] torture_spin_lock_write_delay: delay = 25 jiffies. [ 10.273181][ T36] torture_spin_lock_write_delay: delay = 25 jiffies. [ 10.621916][ T36] torture_spin_lock_write_delay: delay = 25 jiffies. [ 10.788923][ T36] torture_spin_lock_write_delay: delay = 25 jiffies. [ 10.919665][ T36] torture_spin_lock_write_delay: delay = 26 jiffies. [ 11.085916][ T36] torture_spin_lock_write_delay: delay = 25 jiffies. [ 11.471931][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 11.784602][T1] All ww mutex selftests passed The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20231222/202312221708.b143534-oliver.s...@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v3 4/4] drm/ssd130x: Add support for the SSD133x OLED controller family
On 19/12/2023 21:34, Javier Martinez Canillas wrote:
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
matrix OLED panels, add a modesetting pipeline to support the chip family.
The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths
but only the former is implemented for now. This is because the 256 color
depth format matches a fourcc code already present in DRM (RGB8), but the
65k pixel format does not match the existing RG16 fourcc code format.
Instead of a R:G:B 5:6:5, the controller expects the 16-bit pixels to be
R:G:B 6:5:6, and so a new fourcc needs to be added to support this format.
small typo here, R:G:B 6:5:6 => that's 17 bits
other than that, it looks good to me, feel free to add:
Reviewed-by: Jocelyn Falempe
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/solomon/ssd130x-i2c.c | 5 +
drivers/gpu/drm/solomon/ssd130x-spi.c | 7 +
drivers/gpu/drm/solomon/ssd130x.c | 370 ++
drivers/gpu/drm/solomon/ssd130x.h | 5 +-
4 files changed, 386 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index f2ccab9c06d9..a047dbec4e48 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -105,6 +105,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = _variants[SSD1327_ID],
},
+ /* ssd133x family */
+ {
+ .compatible = "solomon,ssd1331",
+ .data = _variants[SSD1331_ID],
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ssd130x_of_match);
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 84e035a7ab3f..84bfde31d172 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -142,6 +142,11 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1327",
.data = _variants[SSD1327_ID],
},
+ /* ssd133x family */
+ {
+ .compatible = "solomon,ssd1331",
+ .data = _variants[SSD1331_ID],
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ssd130x_of_match);
@@ -166,6 +171,8 @@ static const struct spi_device_id ssd130x_spi_table[] = {
{ "ssd1322", SSD1322_ID },
{ "ssd1325", SSD1325_ID },
{ "ssd1327", SSD1327_ID },
+ /* ssd133x family */
+ { "ssd1331", SSD1331_ID },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, ssd130x_spi_table);
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index bef293922b98..447d0c7c88c6 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -119,6 +119,26 @@
#define SSD130X_SET_VCOMH_VOLTAGE 0xbe
#define SSD132X_SET_FUNCTION_SELECT_B 0xd5
+/* ssd133x commands */
+#define SSD133X_SET_COL_RANGE 0x15
+#define SSD133X_SET_ROW_RANGE 0x75
+#define SSD133X_CONTRAST_A 0x81
+#define SSD133X_CONTRAST_B 0x82
+#define SSD133X_CONTRAST_C 0x83
+#define SSD133X_SET_MASTER_CURRENT 0x87
+#define SSD132X_SET_PRECHARGE_A0x8a
+#define SSD132X_SET_PRECHARGE_B0x8b
+#define SSD132X_SET_PRECHARGE_C0x8c
+#define SSD133X_SET_DISPLAY_START 0xa1
+#define SSD133X_SET_DISPLAY_OFFSET 0xa2
+#define SSD133X_SET_DISPLAY_NORMAL 0xa4
+#define SSD133X_SET_MASTER_CONFIG 0xad
+#define SSD133X_POWER_SAVE_MODE0xb0
+#define SSD133X_PHASES_PERIOD 0xb1
+#define SSD133X_SET_CLOCK_FREQ 0xb3
+#define SSD133X_SET_PRECHARGE_VOLTAGE 0xbb
+#define SSD133X_SET_VCOMH_VOLTAGE 0xbe
+
#define MAX_CONTRAST 255
const struct ssd130x_deviceinfo ssd130x_variants[] = {
@@ -180,6 +200,12 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_width = 128,
.default_height = 128,
.family_id = SSD132X_FAMILY,
+ },
+ /* ssd133x family */
+ [SSD1331_ID] = {
+ .default_width = 96,
+ .default_height = 64,
+ .family_id = SSD133X_FAMILY,
}
};
EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
@@ -589,6 +615,117 @@ static int ssd132x_init(struct ssd130x_device *ssd130x)
return 0;
}
+static int ssd133x_init(struct ssd130x_device *ssd130x)
+{
+ int ret;
+
+ /* Set color A contrast */
+ ret = ssd130x_write_cmd(ssd130x, 2, SSD133X_CONTRAST_A, 0x91);
+ if (ret < 0)
+ return ret;
+
+ /* Set color B contrast */
+ ret =
Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate
On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote:
> Ok, I've done more detailed testing, and it seems this patch results in
> lots of dropped frames. I'm sorry for not being more thorough earlier.
> I'll do some more testing without this patch and might have to either
> remove it from V2 of this series.
>
> I need to see if the same stability can be achieved when running
> PLL-MIPI outside its specied range.
I've done some more (load) testing and observing the panel for dropped
frames.
The conclusion I draw from those results is that this patch isn't
necessary for the pinephone. It would be enough to use the correct clock
rate based on the existing values [*]:
- .clock = 69000,
+ .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
I've asked in the postmarketOS community for a bit more testing. They
already have a merge request that contains these changes [2].
This means that we would continue to drive PLL-MIPI outside it's
specified range. I have, so far, not experienced any downside of doing
so. It seems enough to fix the ratios that are part of the first four
patches in this series without introducing a min and max rate.
In conclusion, I'll soon (after some more feedback from the fine folks
at postmarketOS) submit a V2 that addresses the fixes requested in the
first four patches of this series. I'll drop the existing PATCH 5 and
replace it with the one I sent in February [1] instead.
After that, just for fun, I'll probably look into min_rate and max_rate
for nkm clocks and which consequences it has on the pinephone. I might
or might not send a follow up series for that. However, if the pinephone
runs stable without it, it's not a high priority for me.
Best regards,
Frank
[*] I've already submitted a patch in February '23 [1]. It was of little
use back then because the A64's PLL-MIPI clock was not able to run
close to that rate. But since kernel 6.6 PLL-MIPI is able to set
it's parent rate, so that it can come quite close to the required
rate:
+ Panel requires 74.844 MHz with the current timings.
+-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4).
+-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4)
The 6.6 kernel the following rates are possible:
+ PLL-MIPI: ~448.984615 MHz
+-> tcon-data-clock: ~112.246153
+-> panel: ~74.830768 MHz
Which leaves us with a vertical refresh rate of ~59.989 Hz,
deviating less then 0.2% from the ideal 60Hz. That's probably closer
than the accumulated accuracy of all involved components can
reliably achieve. I'd say, let's leave it at that.
[1]: https://lore.kernel.org/lkml/20230219114553.288057-2-fr...@oltmanns.dev/
[2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645
>
> Best regards,
> Frank
>
> On 2023-12-20 at 16:18:49 +0100, Jernej Škrabec
> wrote:
>> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
>>>
>>> On 2023-12-19 at 18:04:29 +0100, Jernej Škrabec
>>> wrote:
>>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns
>>> > napisal(a):
>>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
>>> >> than 500 MHz.
>>> >>
>>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
>>> >> that is high enough to drive PLL-MIPI within its limits.
>>> >>
>>> >> Signed-off-by: Frank Oltmanns
>>> >
>>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
>>> > minimum frequency limit in clock driver. If you add it, clock framework
>>> > should find rate that is high enough and divisible with target rate.
>>>
>>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
>>> this panel has to run exactly at 6 * panel clock. Let me start by
>>> showing the relevant part of the clock tree (this is on the pinephone
>>> after applying the patches):
>>> pll-video0 39360
>>>pll-mipi500945454
>>> tcon0500945454
>>> tcon-data-clock 125236363
>>>
>>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
>>> rate [1]. It's a fixed divisor
>>>
>>> The panel I'm proposing to change is defined as this:
>>>
>>> static const struct st7703_panel_desc xbd599_desc = {
>>> .mode = _mode,
>>> .lanes = 4,
>>> .mode_flags = MIPI_DSI_MODE_VIDEO |
>>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
>>> .format = MIPI_DSI_FMT_RGB888,
>>> .init_sequence = xbd599_init_sequence,
>>> };
>>>
>>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
>>> tcon-data-clock rate is
>>> crtc_clock * 1000 * (24 / 4) / 4
>>>
>>> tcon-data-clock therefore requests a parent rate of
>>> 4 * (crtc_clock * 1000 * (24 / 4) / 4)
>>>
>>> The initial 4 is the fixed divisor between tcon0 and
Re: [PATCH v5 7/8] iio: buffer-dmaengine: Support new DMABUF based userspace API
On Thu, 2023-12-21 at 18:30 +0100, Paul Cercueil wrote:
> Hi Jonathan,
>
> Le jeudi 21 décembre 2023 à 16:12 +, Jonathan Cameron a écrit :
> > On Tue, 19 Dec 2023 18:50:08 +0100
> > Paul Cercueil wrote:
> >
> > > Use the functions provided by the buffer-dma core to implement the
> > > DMABUF userspace API in the buffer-dmaengine IIO buffer
> > > implementation.
> > >
> > > Since we want to be able to transfer an arbitrary number of bytes
> > > and
> > > not necesarily the full DMABUF, the associated scatterlist is
> > > converted
> > > to an array of DMA addresses + lengths, which is then passed to
> > > dmaengine_prep_slave_dma_array().
> > >
> > > Signed-off-by: Paul Cercueil
> > One question inline. Otherwise looks fine to me.
> >
> > J
> > >
> > > ---
> > > v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the
> > > code to
> > > work with the new functions introduced in industrialio-buffer-
> > > dma.c.
> > >
> > > v5: - Use the new dmaengine_prep_slave_dma_vec().
> > > - Restrict to input buffers, since output buffers are not yet
> > > supported by IIO buffers.
> > > ---
> > > .../buffer/industrialio-buffer-dmaengine.c | 52
> > > ---
> > > 1 file changed, 46 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > index 5f85ba38e6f6..825d76a24a67 100644
> > > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > @@ -64,15 +64,51 @@ static int
> > > iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue
> > > *queue,
> > > struct dmaengine_buffer *dmaengine_buffer =
> > > iio_buffer_to_dmaengine_buffer(>buffer);
> > > struct dma_async_tx_descriptor *desc;
> > > + unsigned int i, nents;
> > > + struct scatterlist *sgl;
> > > + struct dma_vec *vecs;
> > > + size_t max_size;
> > > dma_cookie_t cookie;
> > > + size_t len_total;
> > >
> > > - block->bytes_used = min(block->size, dmaengine_buffer-
> > > > max_size);
> > > - block->bytes_used = round_down(block->bytes_used,
> > > - dmaengine_buffer->align);
> > > + if (queue->buffer.direction != IIO_BUFFER_DIRECTION_IN) {
> > > + /* We do not yet support output buffers. */
> > > + return -EINVAL;
> > > + }
> > >
> > > - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > > - block->phys_addr, block->bytes_used,
> > > DMA_DEV_TO_MEM,
> > > - DMA_PREP_INTERRUPT);
> > > + if (block->sg_table) {
> > > + sgl = block->sg_table->sgl;
> > > + nents = sg_nents_for_len(sgl, block->bytes_used);
> >
> > Are we guaranteed the length in the sglist is enough? If not this
> > can return an error code.
>
> The length of the sglist will always be enough, the
> iio_buffer_enqueue_dmabuf() function already checks that block-
> > bytes_used is equal or smaller than the size of the DMABUF.
>
> It is quite a few functions above in the call stack though, so I can
> handle the errors of sg_nents_for_len() here if you think makes sense.
Maybe putting something like the above in a comment?
- Nuno Sá
Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs
On Thu, 2023-12-21 at 16:04 +, Jonathan Cameron wrote:
> On Tue, 19 Dec 2023 18:50:07 +0100
> Paul Cercueil wrote:
>
> > Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> > and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> > DMA buffer implementations.
> >
> > Signed-off-by: Paul Cercueil
> >
> Hi Paul,
>
> A few comments in here. Mostly places where the cleanup.h guard() stuff
> can simplify error paths.
>
> Overall this looks reasonable to me.
>
> Jonathan
>
> > ---
> > v3: Update code to provide the functions that will be used as callbacks
> > for the new IOCTLs.
> > ---
> > drivers/iio/buffer/industrialio-buffer-dma.c | 157 +--
> > include/linux/iio/buffer-dma.h | 26 +++
> > 2 files changed, 170 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c
> > b/drivers/iio/buffer/industrialio-buffer-dma.c
> > index 5610ba67925e..adb64f975064 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -94,14 +95,24 @@ static void iio_buffer_block_release(struct kref *kref)
> > {
> > struct iio_dma_buffer_block *block = container_of(kref,
> > struct iio_dma_buffer_block, kref);
> > + struct iio_dma_buffer_queue *queue = block->queue;
> >
> > - WARN_ON(block->state != IIO_BLOCK_STATE_DEAD);
> > + WARN_ON(block->fileio && block->state != IIO_BLOCK_STATE_DEAD);
> >
> > - dma_free_coherent(block->queue->dev, PAGE_ALIGN(block->size),
> > - block->vaddr, block->phys_addr);
> > + mutex_lock(>lock);
> >
> > - iio_buffer_put(>queue->buffer);
> > + if (block->fileio) {
> > + dma_free_coherent(queue->dev, PAGE_ALIGN(block->size),
> > + block->vaddr, block->phys_addr);
> > + queue->num_fileio_blocks--;
> > + }
> > +
> > + queue->num_blocks--;
> > kfree(block);
> > +
> > + mutex_unlock(>lock);
> > +
> > + iio_buffer_put(>buffer);
> > }
> >
> > static void iio_buffer_block_get(struct iio_dma_buffer_block *block)
> > @@ -163,7 +174,7 @@ static struct iio_dma_buffer_queue
> > *iio_buffer_to_queue(struct iio_buffer *buf)
> > }
> >
> > static struct iio_dma_buffer_block *iio_dma_buffer_alloc_block(
> > - struct iio_dma_buffer_queue *queue, size_t size)
> > + struct iio_dma_buffer_queue *queue, size_t size, bool fileio)
> > {
> > struct iio_dma_buffer_block *block;
> >
> > @@ -171,13 +182,16 @@ static struct iio_dma_buffer_block
> > *iio_dma_buffer_alloc_block(
> > if (!block)
> > return NULL;
> >
> > - block->vaddr = dma_alloc_coherent(queue->dev, PAGE_ALIGN(size),
> > - >phys_addr, GFP_KERNEL);
> > - if (!block->vaddr) {
> > - kfree(block);
> > - return NULL;
> > + if (fileio) {
> > + block->vaddr = dma_alloc_coherent(queue->dev,
> > PAGE_ALIGN(size),
> > + >phys_addr,
> > GFP_KERNEL);
> > + if (!block->vaddr) {
> > + kfree(block);
> > + return NULL;
> > + }
> > }
> >
> > + block->fileio = fileio;
> > block->size = size;
> > block->state = IIO_BLOCK_STATE_DONE;
> > block->queue = queue;
> > @@ -186,6 +200,9 @@ static struct iio_dma_buffer_block
> > *iio_dma_buffer_alloc_block(
> >
> > iio_buffer_get(>buffer);
> >
> > + queue->num_blocks++;
> > + queue->num_fileio_blocks += fileio;
> Adding a boolean is non intuitive.
>
> if (fileio)
> queue->num_fileio_blocks++;
>
> probably easier to read and compiler should be able to figure out how to
> optimise the condition away.
>
> > +
> > return block;
> > }
> >
> > @@ -211,6 +228,9 @@ void iio_dma_buffer_block_done(struct
> > iio_dma_buffer_block
> > *block)
> > _iio_dma_buffer_block_done(block);
> > spin_unlock_irqrestore(>list_lock, flags);
> >
> > + if (!block->fileio)
> > + iio_buffer_signal_dmabuf_done(block->attach, 0);
> > +
> > iio_buffer_block_put_atomic(block);
> > wake_up_interruptible_poll(>buffer.pollq, EPOLLIN |
> > EPOLLRDNORM);
> > }
> > @@ -237,10 +257,14 @@ void iio_dma_buffer_block_list_abort(struct
> > iio_dma_buffer_queue *queue,
> > list_del(>head);
> > block->bytes_used = 0;
> > _iio_dma_buffer_block_done(block);
> > +
> > + if (!block->fileio)
> > + iio_buffer_signal_dmabuf_done(block->attach,
> > -EINTR);
> >
Re: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
On 12/21/23 21:36, Krzysztof Kozlowski wrote: > On 21/12/2023 13:43, Raphael Gallais-Pou wrote: >> Add dt-binding file for "st,stm32-lvds" compatible. >> >> Signed-off-by: Raphael Gallais-Pou >> --- > I don't know why this was resend, nothing explains it, but I already > commented on other version. > > Please respond to comments there. > > In the future, unless it is obvious resend over 2 weeks, say why you are > doing it and what changed. My proxy tends to block every patch after a batch of 4 or 5 patches. Since it splitted the serie in half I resent it so that the serie could be entirely read without problems. This explains the resend. I was not sure about putting a short explanation in the cover letter since it was not related any change in the serie, but next time I will do so. Best Regards, Raphaël > > Best regards, > Krzysztof >
Re: [PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
Hi Krzysztof,
Thanks for your review. I wall send another serie later with those
modifications.
Best regards,
Raphaël
On 12/21/23 18:27, Krzysztof Kozlowski wrote:
> On 21/12/2023 13:28, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
> A nit, subject: drop second/last, redundant "dt-bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
>
>> Signed-off-by: Raphael Gallais-Pou
>> ---
>> .../bindings/display/st,stm32-lvds.yaml | 114 ++
>> 1 file changed, 114 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
>>
> ...
>
>> +properties:
>> + "#clock-cells":
>> +const: 0
>> +
>> + compatible:
>> +const: st,stm32-lvds
> Please put compatible as first.
>
>> +
>> + reg:
>> +maxItems: 1
>> +
>> + clocks:
>> +items:
>> + - description: APB peripheral clock
>> + - description: Reference clock for the internal PLL
>> +
>> + clock-names:
>> +items:
>> + - const: pclk
>> + - const: ref
>> +
>> + resets:
>> +maxItems: 1
>> +
>> + ports:
>> +$ref: /schemas/graph.yaml#/properties/ports
>> +
>> +properties:
>> + port@0:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: |
>> + LVDS input port node, connected to the LTDC RGB output port.
>> +
>> + port@1:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: |
>> + LVDS output port node, connected to a panel or bridge input port.
> Ports are not required? I would assume it won't work without input and
> output.
>
>> +
>> +required:
>> + - "#clock-cells"
>> + - compatible
>> + - reg
>> + - clocks
>> + - clock-names
>> + - resets
>> + - ports
>> +
>> +unevaluatedProperties: false
> additionalProperties instead... or did I miss some $ref anywhere?
>
>> +
>> +examples:
>> + - |
>> +#include
>> +#include
>> +#include
>> +
>> +lvds: lvds@4806 {
>> +#clock-cells = <0>;
>> +compatible = "st,stm32-lvds";
> compatible is always the first property.
>
>> +reg = <0x4806 0x2000>;
> put clock-cells here
>
>> +clocks = < CK_BUS_LVDS>, < CK_KER_LVDSPHY>;
>> +clock-names = "pclk", "ref";
>> +resets = < LVDS_R>;
> Best regards,
> Krzysztof
>
Re: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
Hi Rob On 12/21/23 15:45, Rob Herring wrote: > On Thu, 21 Dec 2023 13:43:33 +0100, Raphael Gallais-Pou wrote: >> Add dt-binding file for "st,stm32-lvds" compatible. >> >> Signed-off-by: Raphael Gallais-Pou >> --- >> .../bindings/display/st,stm32-lvds.yaml | 114 ++ >> 1 file changed, 114 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/st,stm32-lvds.yaml >> > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > Documentation/devicetree/bindings/display/st,stm32-lvds.example.dts:18:18: > fatal error: dt-bindings/bus/stm32mp25_sys_bus.h: No such file or directory >18 | #include > | ^ > compilation terminated. > make[2]: *** [scripts/Makefile.lib:419: > Documentation/devicetree/bindings/display/st,stm32-lvds.example.dtb] Error 1 > make[2]: *** Waiting for unfinished jobs > make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: > dt_binding_check] Error 2 > make: *** [Makefile:234: __sub-make] Error 2 This is because I forgot to remove this line from the example. I'll remove it in V2. Thanks, Raphaël > doc reference errors (make refcheckdocs): > > See > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231221124339.420119-3-raphael.gallais-...@foss.st.com > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. >
[PATCH] drm: panel-orientation-quirks: Add quirk for GPD Win Mini
Signed-off-by: Samuel Dionne-Riel
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c3..f730886ae10df 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -279,6 +279,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1618-03")
},
.driver_data = (void *)_rightside_up,
+ }, {/* GPD Win Mini */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1617-01")
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* I.T.Works TW891 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
--
2.42.0
Re: [PATCH] drm: panel-orientation-quirks: Add quirk for GPD Win Mini
Hi,
Sorry, I was preparing for sending to the mailing list, and sent
before I should have.
I believe I have the orientation on the wrong side, though, so please
wait for a follow-up here or the v2.
Sorry again,
On 12/21/23, Samuel Dionne-Riel wrote:
> Signed-off-by: Samuel Dionne-Riel
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 3d92f66e550c3..f730886ae10df 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -279,6 +279,12 @@ static const struct dmi_system_id orientation_data[] =
> {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1618-03")
> },
> .driver_data = (void *)_rightside_up,
> + }, {/* GPD Win Mini */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1617-01")
> + },
> + .driver_data = (void *)_leftside_up,
> }, {/* I.T.Works TW891 */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
> --
> 2.42.0
>
>
--
— Samuel Dionne-Riel
[PATCH v2] drm: panel-orientation-quirks: Add quirk for GPD Win Mini
Signed-off-by: Samuel Dionne-Riel
---
Changes since v1:
- Add 1080p right-side up panel data
- Use the correct panel orientation
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c3..aa93129c3397e 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -117,6 +117,12 @@ static const struct drm_dmi_panel_orientation_data
lcd1080x1920_leftside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1080x1920_rightside_up =
{
+ .width = 1080,
+ .height = 1920,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data lcd1200x1920_rightside_up =
{
.width = 1200,
.height = 1920,
@@ -279,6 +285,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1618-03")
},
.driver_data = (void *)_rightside_up,
+ }, {/* GPD Win Mini */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1617-01")
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* I.T.Works TW891 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
--
2.42.0
Re: (subset) [PATCH RESEND v1 0/8] Introduce STM32 LVDS driver
Hi, On Thu, 21 Dec 2023 13:43:31 +0100, Raphael Gallais-Pou wrote: > This serie introduces a new DRM bridge driver for STM32MP257 platforms > based on Arm Cortex-35. It also adds an instance in the device-tree and > handle the inclusion of the driver within the DRM framework. First patch > adds a new panel compatible in the panel-lvds driver, which is used by > default on the STM32MP257. > > Raphael Gallais-Pou (7): > dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds > dt-bindings: display: add dt-bindings for STM32 LVDS device > drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver > drm/stm: ltdc: add lvds pixel clock > arm64: dts: st: add ltdc support on stm32mp251 > arm64: dts: st: add lvds support on stm32mp253 > arm64: dts: st: add display support on stm32mp257f-ev > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/8] dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds https://cgit.freedesktop.org/drm/drm-misc/commit/?id=021a81e7ac8f579b049e5bc76efabd9e67bd627c -- Neil
Re: [PATCH 0/2] drm/bridge: start moving towards struct drm_edid
On 19/12/2023 13:15, Jani Nikula wrote: On Tue, 14 Nov 2023, Jani Nikula wrote: On Thu, 26 Oct 2023, Jani Nikula wrote: This is just the first two patches of a lengthy series that I'm not really sure how to proceed with. Basically the series converts all of drm/bridge to the new struct drm_edid infrastructure. It's safer than struct edid, because it contains meta information about the allocated size of the EDID, instead of relying on the size (number of extensions) originating from outside of the kernel. The rest is at [1]. The commit messages are lacking, and I don't really have the toolchain to even build test most of it. But I think this is where drm/bridge should go. Among all of drm, I think bridge has the most uses of struct edid that do not originate from the drm_get_edid() family of functions, which means the validity checks are somewhat inconsistent, and having the meta information is more crucial. Bridge maintainers, please instruct how to best proceed with this. Ping. Ping. Sorry for the delay, I would have preferred changing the get_edid to return a drm_edid, but I understand the task is too high, could you instead use @get_drm_edid instead of @edid_read ? And perhaps convert one very common bridge to this so we can validate the change in CI. Neil The two patches posted here could be merged, to add something to build the later commits on gradually. BR, Jani. Thanks, Jani. [1] https://gitlab.freedesktop.org/jani/linux/-/commits/drm-edid-bridge Jani Nikula (2): drm/bridge: add ->edid_read hook and drm_bridge_edid_read() drm/bridge: switch to drm_bridge_read_edid() drivers/gpu/drm/drm_bridge.c | 46 +- drivers/gpu/drm/drm_bridge_connector.c | 16 - include/drm/drm_bridge.h | 33 ++ 3 files changed, 86 insertions(+), 9 deletions(-)
Re: [PATCH linux-next] drm/panel: Simplify with dev_err_probe()
On 20/12/2023 03:48, yang.gua...@zte.com.cn wrote:
From: Yang Guang
dev_err_probe() can check if the error code is -EPROBE_DEFER
and can return the error code, replacing dev_err() with it
simplifies the code.
Signed-off-by: Chen Haonan
Got the following checkpatch error:
ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Yang
Guang '
Thanks,
Neil
---
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
index 11b64acbe8a9..e225840b0d67 100644
--- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -854,26 +854,20 @@ static int panel_add(struct panel_info *pinfo)
pinfo->pp18_gpio = devm_gpiod_get(dev, "pp18", GPIOD_OUT_HIGH);
if (IS_ERR(pinfo->pp18_gpio)) {
- ret = PTR_ERR(pinfo->pp18_gpio);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "failed to get pp18 gpio: %d\n", ret);
- return ret;
+ return dev_err_probe(dev, PTR_ERR(pinfo->pp18_gpio),
+"failed to get pp18
gpio\n");
}
pinfo->pp33_gpio = devm_gpiod_get(dev, "pp33", GPIOD_OUT_HIGH);
if (IS_ERR(pinfo->pp33_gpio)) {
- ret = PTR_ERR(pinfo->pp33_gpio);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "failed to get pp33 gpio: %d\n", ret);
- return ret;
+ return dev_err_probe(dev, PTR_ERR(pinfo->pp33_gpio),
+"failed to get pp33
gpio\n");
}
pinfo->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
if (IS_ERR(pinfo->enable_gpio)) {
- ret = PTR_ERR(pinfo->enable_gpio);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "failed to get enable gpio: %d\n", ret);
- return ret;
+ return dev_err_probe(dev, PTR_ERR(pinfo->enable_gpio),
+"failed to get enable gpio\n");
}
drm_panel_init(>base, dev, _funcs,
