Re: Notifications about ACPI events in userspace?
On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote: > On 13.05.2017 14:18, Lukas Wunner wrote: > > > > So to sum it up, the built-in panel on the iMac can be driven by a > > separate machine and we can switch between the two sources via the SMC. > > > > [...] > > > > I guess you could register a vga_switcheroo handler which controls > > switching via the SMC. You'd also have to register a vga_switcheroo > > client whenever you detect hotplug of an external source (and unregister > > on unplug). The client is normally a DRM driver but would in this case > > just be a pseudo device. > > > > Then you could switch back and forth via the vga_switcheroo interface. > > Hm... since there's no power switching of any kind involved, would that > still make sense? The handler's ->power_state hook would be a no-op. Obviously not pretty, but we just don't have a better abstraction yet. We represent an egress connector on a graphics card as a drm_connector in sysfs. What we might need is a representation of a sink (display) in sysfs with symlinks to the sources. Such a source could be a drm_connector or something else entirely (a GPU on another machine in your case). > > > Since I need to modify the applesmc.c driver anyway, it would probably > > > make sense to integrate the notify handler there? > > > > Sounds reasonable to me. > > AFAICT, the alternative (which maybe would be more sensible, the more I > think about it) would be to export applesmc_{read,write}_key as public > symbols and just access them from a standalone driver for the APP000C > ACPI device. Since that should only be present on a Mac that actually > supports TDM, there's also no risk of writing to arbitrary SMC keys on > unsupported devices. That might make sense if you feel the driver will grow large enough to make applesmc.c look messy, or if you feel it just doesn't fit there. I guess the only reason why Apple integrated the functionality into the SMC is because they wanted to support TDM when the machine is powered off. The SMC is powered even in S5 (if the iMac is connected to AC), it just needs to monitor HPD on the external port and turn on the backlight if something is plugged in. (I'm not sure if TDM is actually supported during poweroff but technically it would seem to be supported.) Otherwise I've got no opinion on that, adding Nicolas Boichat and Henrik Rydberg to cc in case they have one. > > Which iMac model are you developing this on exactly, a 2009/2010 model > > (without Thunderbolt) or a newer one? The newer ones can only be driven > > via DP-over-Thunderbolt tunnels, so the HPD pin is coming from the > > Thunderbolt controller, not the socket. We don't have support for > > setting up DP-over-Thunderbolt tunnels in thunderbolt.ko yet, only > > PCIe-over-Thunderbolt is supported. If the external source is already > > present on boot, the tunnel may be established by the Thunderbolt EFI > > driver but will be gone after unplug. > > I have a 2009/2010 model, so no Thunderbolt. Good! Makes everything a lot simpler. Thanks, Lukas > If someone is feeling adventurous > with a Thunderbolt iMac, feel free to poke the SMC. I've written a short blog > post that should be sufficient as background information for some initial > experiments: http://floe.butterbrot.org/matrix/hacking/tdm/ and > https://github.com/floe/smc_util (in particular, look at tdm_{on,off}.sh). > > Best, Florian > -- > SENT FROM MY DEC VT50 TERMINAL > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101037] nouveau: crash when starting chrome
https://bugs.freedesktop.org/show_bug.cgi?id=101037 Bug ID: 101037 Summary: nouveau: crash when starting chrome Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: hramr...@gmail.com 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98 [Quadro NVS 295] [10de:06fd] (rev a1) Linux 4.10.0-trunk-amd64 #1 SMP Debian 4.10.7-1~exp1 (2017-03-30) x86_64 libdrm-nouveau2 2.4.80-1 libgl1-mesa-dri 17.0.4-1 xserver-xorg-video-nouveau 1:1.0.15-1 May 14 09:34:36 iscsi kernel: [ 482.205629] BUG: unable to handle kernel NULL pointer dereference at 0021 May 14 09:34:36 iscsi kernel: [ 482.205629] BUG: unable to handle kernel NULL pointer dereference at 0021 May 14 09:34:36 iscsi kernel: [ 482.205654] IP: dma_fence_wait_timeout+0x30/0xf0 May 14 09:34:36 iscsi kernel: [ 482.205654] IP: dma_fence_wait_timeout+0x30/0xf0 May 14 09:34:36 iscsi kernel: [ 482.205659] PGD 0 May 14 09:34:36 iscsi kernel: [ 482.205659] PGD 0 May 14 09:34:36 iscsi kernel: [ 482.205766] CPU: 1 PID: 1696 Comm: InputThread Tainted: G OE 4.10.0-trunk-amd64 #1 Debian 4.10.7-1~exp1 May 14 09:34:36 iscsi kernel: [ 482.205772] Hardware name: /DQ45CB, BIOS CBQ4510H.86A.0133.2011.0810.1010 08/10/2011 May 14 09:34:36 iscsi kernel: [ 482.205777] task: 8a4d2c13afc0 task.stack: b8c2416e May 14 09:34:36 iscsi kernel: [ 482.205781] RIP: 0010:dma_fence_wait_timeout+0x30/0xf0 May 14 09:34:36 iscsi kernel: [ 482.205785] RSP: 0018:b8c2416e3aa0 EFLAGS: 00010206 May 14 09:34:36 iscsi kernel: [ 482.205789] RAX: 0001 RBX: 8a4c9a817480 RCX: c07cffa0 May 14 09:34:36 iscsi kernel: [ 482.205794] RDX: 7fff RSI: 0001 RDI: 8a4d2c27c600 May 14 09:34:36 iscsi kernel: [ 482.205798] RBP: 8a4d2c27c600 R08: 8a4d2c3e9000 R09: May 14 09:34:36 iscsi kernel: [ 482.205802] R10: 8a4d302763a8 R11: 8a4d314bb600 R12: 0001 May 14 09:34:36 iscsi kernel: [ 482.205807] R13: 7fff R14: 0001 R15: 0001 May 14 09:34:36 iscsi kernel: [ 482.205811] FS: 7f341c83e700() GS:8a4d3bc8() knlGS: May 14 09:34:36 iscsi kernel: [ 482.205819] CS: 0010 DS: ES: CR0: 80050033 May 14 09:34:36 iscsi kernel: [ 482.205823] CR2: 0021 CR3: 00022c2bc000 CR4: 000406e0 May 14 09:34:36 iscsi kernel: [ 482.205828] Call Trace: May 14 09:34:36 iscsi kernel: [ 482.205843] ? drm_atomic_helper_wait_for_fences+0x48/0x130 [drm_kms_helper] May 14 09:34:36 iscsi kernel: [ 482.205895] ? nv50_disp_atomic_commit+0x18e/0x290 [nouveau] May 14 09:34:36 iscsi kernel: [ 482.205902] ? drm_atomic_helper_update_plane+0xeb/0x150 [drm_kms_helper] May 14 09:34:36 iscsi kernel: [ 482.205928] ? __setplane_internal+0x1d9/0x2a0 [drm] May 14 09:34:36 iscsi kernel: [ 482.205939] ? drm_mode_cursor_universal+0x11c/0x200 [drm] May 14 09:34:36 iscsi kernel: [ 482.205950] ? drm_mode_cursor_common+0x80/0x170 [drm] May 14 09:34:36 iscsi kernel: [ 482.205961] ? drm_mode_cursor_ioctl+0x54/0x70 [drm] May 14 09:34:36 iscsi kernel: [ 482.205973] ? drm_ioctl+0x1ea/0x470 [drm] May 14 09:34:36 iscsi kernel: [ 482.205978] ? __schedule+0x23b/0x6f0 May 14 09:34:36 iscsi kernel: [ 482.205989] ? drm_mode_setplane+0x1a0/0x1a0 [drm] May 14 09:34:36 iscsi kernel: [ 482.205994] ? _copy_to_user+0x4d/0x60 May 14 09:34:36 iscsi kernel: [ 482.206022] ? nouveau_drm_ioctl+0x66/0xc0 [nouveau] May 14 09:34:36 iscsi kernel: [ 482.206027] ? do_vfs_ioctl+0x9f/0x600 May 14 09:34:36 iscsi kernel: [ 482.206032] ? __check_object_size+0xfb/0x1d9 May 14 09:34:36 iscsi kernel: [ 482.206035] ? SyS_ioctl+0x74/0x80 May 14 09:34:36 iscsi kernel: [ 482.206039] ? system_call_fast_compare_end+0xc/0x9b May 14 09:34:36 iscsi kernel: [ 482.206043] Code: 48 85 d2 41 55 41 54 55 53 0f 88 ab 00 00 00 48 89 fd 41 89 f4 49 89 d5 66 66 66 66 90 48 8b 45 08 41 0f b6 f4 4c 89 ea 48 89 ef 50 20 49 89 c4 66 66 66 66 90 5b 4c 89 e0 5d 41 5c 41 5d c3 May 14 09:34:36 iscsi kernel: [ 482.206069] RIP: dma_fence_wait_timeout+0x30/0xf0 RSP: b8c2416e3aa0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101037] nouveau: crash when starting chrome
https://bugs.freedesktop.org/show_bug.cgi?id=101037 --- Comment #1 from Michal Suchanek --- Created attachment 131345 --> https://bugs.freedesktop.org/attachment.cgi?id=131345&action=edit kernel log piieces showiing the error -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database
On Fri, May 12, 2017 at 9:57 AM, Jani Nikula wrote: > Personally I don't think enums should be used for defining bits, because > they are not enumerations. The bits are usually combined to come up with > values that are not part of the enum. > > If we added the quirks to struct intel_dp_desc (and moved to drm > helpers) we could use enums for defining the bit shifts and add a > function to query for a specific quirk, say, drm_dp_has_quirk(struct > drm_dp_desc *desc, enum drm_dpcd_quirk quirk). It's a bit a gnu-ism afaik, but enums-as-bitfields is very much standard. gdb even decodes it for you into the individual bits iirc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper
Hi Jose, On Friday 12 May 2017 17:06:14 Jose Abreu wrote: > On 12-05-2017 10:35, Laurent Pinchart wrote: > > On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote: > >> This changes the connector probe helper function to use the new > >> encoder->mode_valid() and crtc->mode_valid() helper callbacks to > >> validate the modes. > >> > >> The new callbacks are optional so the behaviour remains the same > >> if they are not implemented. If they are, then the code loops > >> through all the connector's encodersXcrtcs and calls the > >> callback. > >> > >> If at least a valid encoderXcrtc combination is found which > >> accepts the mode then the function returns MODE_OK. > >> > >> Signed-off-by: Jose Abreu > >> Cc: Carlos Palminha > >> Cc: Alexey Brodkin > >> Cc: Ville Syrjälä > >> Cc: Daniel Vetter > >> Cc: Dave Airlie > >> Cc: Andrzej Hajda > >> Cc: Archit Taneja > >> --- > >> > >> Changes v1->v2: > >>- Use new helpers suggested by Ville > >>- Change documentation (Daniel) > >> > >> drivers/gpu/drm/drm_probe_helper.c | 60 ++-- > >> 1 file changed, 57 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_probe_helper.c > >> b/drivers/gpu/drm/drm_probe_helper.c index 1b0c14a..de47413 100644 > >> --- a/drivers/gpu/drm/drm_probe_helper.c > >> +++ b/drivers/gpu/drm/drm_probe_helper.c [snip] > >> +static enum drm_mode_status > >> +drm_mode_validate_connector(struct drm_connector *connector, > >> + struct drm_display_mode *mode) > > > > This does more than validating the mode against the connector, it > > validates it against the whole pipeline. I would call the function > > drm_mode_validate_pipeline() (or any other similar name). > > Yeah, in previous version I had something similar but I changed > in order to address review comments. I can change again though... Sorry, I haven't seen v1. I think it makes more sense to reflect in its name the fact that the function validates the mode against the whole pipeline, but I'll let others disagree. > >> +{ > >> + struct drm_device *dev = connector->dev; > >> + uint32_t *ids = connector->encoder_ids; > >> + enum drm_mode_status ret = MODE_OK; > >> + unsigned int i; > >> + > >> + /* Step 1: Validate against connector */ > >> + ret = drm_connector_mode_valid(connector, mode); > >> + if (ret != MODE_OK) > >> + return ret; > >> + > >> + /* Step 2: Validate against encoders and crtcs */ > >> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > >> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]); > >> + struct drm_crtc *crtc; > >> + > >> + if (!encoder) > >> + continue; > >> + > >> + ret = drm_encoder_mode_valid(encoder, mode); > >> + if (ret != MODE_OK) { > >> + /* No point in continuing for crtc check as this > > > > encoder > > > >> + * will not accept the mode anyway. If all encoders > >> + * reject the mode then, at exit, ret will not be > >> + * MODE_OK. */ > >> + continue; > >> + } > >> + > >> + drm_for_each_crtc(crtc, dev) { > >> + if (!drm_encoder_crtc_ok(encoder, crtc)) > >> + continue; > >> + > >> + ret = drm_crtc_mode_valid(crtc, mode); > >> + if (ret == MODE_OK) { > >> + /* If we get to this point there is at least > >> + * one combination of encoder+crtc that works > >> + * for this mode. Lets return now. */ > >> + return ret; > >> + } > >> + } > >> + } > >> + > >> + return ret; > >> +} [snip] > >> @@ -428,8 +482,8 @@ int > >> drm_helper_probe_single_connector_modes(struct drm_connector *connector, > >> > >>if (mode->status == MODE_OK) > >> > >>mode->status = drm_mode_validate_flag(mode, > >> > >> mode_flags); > >> > >> - if (mode->status == MODE_OK && connector_funcs->mode_valid) > >> - mode->status = connector_funcs->mode_valid(connector, > >> + if (mode->status == MODE_OK) > >> + mode->status = drm_mode_validate_connector(connector, > >> > >> mode); > > > > I would reverse the arguments order to match the style of the other > > validation functions. > > Hmm, I think it makes more sense to pass connector first and then > mode ... I disagree, as this function validates a mode against a pipeline, the same way the other validation functions validate a mode against other parameters, but it's your patch :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix noderef.cocci warnings
drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof to pointer sizeof when applied to a pointer typed expression gives the size of the pointer Generated by: scripts/coccinelle/misc/noderef.cocci Signed-off-by: Fengguang Wu --- i915_syncmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/i915_syncmap.c +++ b/drivers/gpu/drm/i915/i915_syncmap.c @@ -282,7 +282,7 @@ static noinline int __sync_set(struct i9 unsigned int above; /* Insert a join above the current layer */ - next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(next), + next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(*next), GFP_KERNEL); if (unlikely(!next)) return -ENOMEM; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 4/7] drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof to pointer
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 49f08598bf7a52eadebda851a5e8e6fa1dc2e15e commit: 4797948071f607c5b43753cb8f1b7ddcf22e146d [4/7] drm/i915: Squash repeated awaits on the same fence coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof >> to pointer Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Notifications about ACPI events in userspace?
On Sun, May 14, 2017 at 11:25:48AM +0200, Florian Echtler wrote: > On 14.05.2017 10:11, Lukas Wunner wrote: > > On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote: > >> On 13.05.2017 14:18, Lukas Wunner wrote: > >>> Then you could switch back and forth via the vga_switcheroo interface. > >> > >> Hm... since there's no power switching of any kind involved, would that > >> still make sense? > > > > The handler's ->power_state hook would be a no-op. Obviously not pretty, > > but we just don't have a better abstraction yet. We represent an egress > > connector on a graphics card as a drm_connector in sysfs. What we might > > need is a representation of a sink (display) in sysfs with symlinks to the > > sources. Such a source could be a drm_connector or something else > > entirely (a GPU on another machine in your case). > > OK, I think it's the closest thing that's already in the kernel, and before > I add yet another custom sysfs node, vga_switcheroo is probably the easiest > route to get things up and running. Okay. I'm only just now starting to get a vague idea how all this may be represented properly. On pre-Thunderbolt MacBook Pros it's possible to switch the external DP port between GPUs independently from the panel. Right now we're switching both in unison, but if we had a proper "sink with multiple sources" abstraction, we would be able to support switching them separately. > >> AFAICT, the alternative (which maybe would be more sensible, the more I > >> think about it) would be to export applesmc_{read,write}_key as public > >> symbols and just access them from a standalone driver for the APP000C > >> ACPI device. Since that should only be present on a Mac that actually > >> supports TDM, there's also no risk of writing to arbitrary SMC keys on > >> unsupported devices. > > > > That might make sense if you feel the driver will grow large enough to > > make applesmc.c look messy, or if you feel it just doesn't fit there. > > Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge. > So for applesmc, I'd just need a tiny patch to export the main key access > functions, and everything else can (hopefully) be encapsulated in an > "apple-tdm" driver. Sounds reasonable. You can probably copy/paste a lot of boilerplate from apple-gmux.c and just bind to APP000C instead of APP000B. You may need to add APP000C to acpi_pnp_device_ids[] in drivers/acpi/acpi_pnp.c for the driver to bind to the device. The vga_switcheroo "switch" file will appear in sysfs as soon as a handler and 2 clients have registered. The handler only needs to implement the ->switchto and ->get_client_id hooks, all others are optional. The ->get_client_id hook should probably return VGA_SWITCHEROO_IGD for the Nvidia GPU built into the iMac and VGA_SWITCHEROO_DIS for the external port. The vga_switcheroo_client is normally a PCI device, I guess you could use the LPC bridge as a placeholder (the grandparent of the APP000C device). The ->set_gpu_state hook would be a no-op and ->can_switch could always return true. If you register that client whenever something is plugged in and unregister it on unplug, the "switch" file in sysfs appears only as long as something is plugged in. > > I guess the only reason why Apple integrated the functionality into the > > SMC is because they wanted to support TDM when the machine is powered off. > > The SMC is powered even in S5 (if the iMac is connected to AC), it just > > needs to monitor HPD on the external port and turn on the backlight if > > something is plugged in. (I'm not sure if TDM is actually supported > > during poweroff but technically it would seem to be supported.) > > Hm, interesting, I hadn't yet thought of that. This would of course be > excellent, because right now it looks like a waste of power to run the > whole machine just because of the display. > > Does the SMC have control over the backlight? Do you know which keys are > responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway... The panel is attached to power rails which are only active in S0 (PP12V_S0_LCD and PP3V3_S0_VIDEO). Conceivably, the SMC could sense HPD and bring up those power rails. However various other things are hanging off of the same rails, e.g. fan, memory, optical disk drive, and they would be powered up as well. Essentially the whole machine would boot, but perhaps the EFI firmware senses if powerup was only triggered by DP hotplug and not boot an OS. Have you tested what happens if you plug something in while the iMac is off? Thanks, Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3
Hi, Bisected this to: commit df8dc97cd17269474344d73cc02739532c468d04 Author: Ben Skeggs Date: Wed Mar 1 09:42:04 2017 +1000 drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm I'm not entirely sure NVKM needs to support this now, but I haven't removed it as of yet just in case it's needed from DEVINIT scripts where DRM isn't available. Signed-off-by: Ben Skeggs dmesg after boot with drm.debug enabled: v4.10-10409-g5c68d91 (still works): http://termbin.com/b0is v4.10-10410-gdf8dc97 (failure): http://termbin.com/j6lq Tommi 2017-05-10 11:24 GMT+03:00 Tommi Rantala : > Hi, > > The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work > correctly with v4.11-11413-g2868b25. > > When booting the laptop, the resolution seems to be limited to > 1024x768, and gnome-session segfaults. > > Up to 4.11 the display works just fine in 1920x1080 mode. > > I'm seeing this in the kernel logs: > > nouveau :01:00.0: eDP-1: EDID is invalid: > [00] BAD 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54 > [00] BAD 66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > [00] BAD ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff > nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1 > [drm] Cannot find any crtc or sizes - going 1024x768 > > > $ lspci | grep NVIDIA > 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro > M2000M] (rev a2) > > Any ideas, or should I bisect? > > 4.11 dmesg & xrandr output: > https://pastebin.com/raw/P9LGP7e1 > > 4.11-11413-g2868b25 dmesg: > https://pastebin.com/raw/QBT9mMua > > -Tommi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100891] failed to send pre message kernel output delays booting/suspending/resuming
https://bugs.freedesktop.org/show_bug.cgi?id=100891 --- Comment #4 from MichaelLong --- Created attachment 131352 --> https://bugs.freedesktop.org/attachment.cgi?id=131352&action=edit dmesg log 4.12-rc1 Still broken on 4.12-rc1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fix spelling mistake: "dimesions" -> "dimensions"
From: Colin Ian King Trivial fix to spelling mistake in DRM_ERROR message and split over two lines to clean up a "line over 80 characters" checkpatch warning. Signed-off-by: Colin Ian King --- drivers/gpu/drm/vc4/vc4_validate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_validate.c b/drivers/gpu/drm/vc4/vc4_validate.c index da6f1e138e8d..8a9418b28fbb 100644 --- a/drivers/gpu/drm/vc4/vc4_validate.c +++ b/drivers/gpu/drm/vc4/vc4_validate.c @@ -172,7 +172,8 @@ vc4_check_tex_size(struct vc4_exec_info *exec, struct drm_gem_cma_object *fbo, * our math. */ if (width > 4096 || height > 4096) { - DRM_ERROR("Surface dimesions (%d,%d) too large", width, height); + DRM_ERROR("Surface dimensions (%d,%d) too large", + width, height); return false; } -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP
Hi Magnus, On Wednesday 07 Sep 2016 17:01:06 Magnus Damm wrote: > Hi Laurent, > > Thanks for your help with this. Good to see that the DU driver is > getting closer to work with the IPMMU hardware! Please see below for > some feedback from me. > > On Fri, Aug 19, 2016 at 5:39 PM, Laurent Pinchart wrote: > > Hello, > > > > This patch series fixes the rcar-du-drm driver to support VSP plane > > sources with an IOMMU. It is available for convenience at > > > > git://linuxtv.org/pinchartl/media.git iommu/devel/du > > > > On R-Car Gen3 the DU has no direct memory access but sources planes > > through VSP instances. When an IOMMU is inserted between the VSP and > > memory, the DU framebuffers need to be DMA mapped using the VSP device, > > not the DU device as currently done. The same situation can also be > > reproduced on Gen2 hardware by linking the VSP to the DU in DT [1], > > effectively disabling direct memory access by the DU. > > > > The situation is made quite complex by the fact that different planes can > > be connected to different DU instances, and thus served by different > > IOMMUs (or, in practice on existing hardware, by the same IOMMU but > > through different micro-TLBs). We thus can't allocate and map buffers to > > the right device in a single dma_alloc_wc() operation as done in the DRM > > CMA GEM helpers. > > > > However, on such setups, the DU DT node doesn't reference IOMMUs as the DU > > does not perform any direct memory access. We can thus keep the GEM object > > allocation unchanged, and the DMA addresses that we receive in the DU > > driver will be physical addresses. Those buffers then need to be mapped > > to the VSP device when they are associated with planes. Fortunately the > > atomic framework provides two plane helper operations, .prepare_fb() and > > .cleanup_fb() that we can use for this purpose. > > > > The reality is slightly more complex than this on Gen3, as an FCP device > > instance sits between VSP instances and memory. It is the FCP devices that > > are connected to the IOMMUs, and buffer mapping thus need to be performed > > using the FCP devices. This isn't required on Gen2 as the platforms don't > > have any FCPs. > > > > Patches 1/6 and 2/6 unconstify the state argument to the .prepare_fb() and > > .cleanup_fb() operations, to allow storing the mapped buffer addresses in > > the state. Patches 3/6 and 4/6 then extend the rcar-fcp driver API to > > expose the FCP struct device. Patch 5/6 extends the vsp1 driver API to > > allow mapping a scatter-gather list to the VSP, with the implementation > > using the FCP devices instead when available. Patch 6/6 then use the vsp1 > > mapping API in the rcar-du-drm driver to map and unmap buffers when > > needed. > > > > The series has been tested on Gen2 (Lager) only as the Gen3 IOMMU is known > > to be broken. > > Slight clarification, the R-Car Gen3 family as a whole does not have > broken IPMMU hardware. Early R-Car H3 revisions do require some errata > handling though, but M3-W and later ES versions and MP of H3 will be > fine. Given the early R-Car H3 errata I agree it makes sense to > develop and test this series on R-Car Gen2 though. > > > A possible improvement is to modify the GEM object allocation mechanism to > > use non-contiguous memory when the DU driver detects that all the VSP > > instances it is connected to use an IOMMU (possibly through FCP devices). > > > > An issue has been noticed with synchronization between page flip and VSP > > operation. Buffers get unmapped (and possibly freed) before the VSP is > > done reading them. The problem isn't new, but is much more noticeable with > > IOMMU support enabled as any hardware access to unmapped memory generates > > an IOMMU page fault immediately. > > > > The series unfortunately contain a dependency between DRM and V4L2 > > patches, complicating upstream merge. As there's no urgency to merge patch > > 6/6 due to the IOMMU being broken on Gen3 at the moment, I propose merging > > patches 1/6-2/6 and 3/6-5/6 independently for the next kernel release. > > > > I would particularly appreciate feedback on the APIs introduced by patches > > 4/6 and 5/6. > > The code in general looks fine to me. The APIs introduced by patches > 4/6 and 5/6 seem quite straightforward. Is there something I can do to > help with those? > > > [1] > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.h > > tml > > Laurent Pinchart (6): > > drm: Don't implement empty prepare_fb()/cleanup_fb() > > drm: Unconstify state argument to prepare_fb()/cleanup_fb() > > v4l: rcar-fcp: Don't get/put module reference > > v4l: rcar-fcp: Add an API to retrieve the FCP device > > v4l: vsp1: Add API to map and unmap DRM buffers through the VSP > > drm: rcar-du: Map memory through the VSP device > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 - > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +- > > drivers/gpu/drm/fsl-dc
[PATCH v1] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI
Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Signed-off-by: Robert Foss --- drivers/gpu/drm/drm_rect.c | 1 + include/drm/drm_blend.h| 18 include/uapi/drm/drm.h | 73 ++ 3 files changed, 74 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c index bc5575960ebc..bdb27434bb10 100644 --- a/drivers/gpu/drm/drm_rect.c +++ b/drivers/gpu/drm/drm_rect.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h index 13221cf9b3eb..d149a63b893b 100644 --- a/include/drm/drm_blend.h +++ b/include/drm/drm_blend.h @@ -29,24 +29,6 @@ struct drm_device; struct drm_atomic_state; -/* - * Rotation property bits. DRM_ROTATE_ rotates the image by the - * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X and - * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation - * - * WARNING: These defines are UABI since they're exposed in the rotation - * property. - */ -#define DRM_ROTATE_0 BIT(0) -#define DRM_ROTATE_90 BIT(1) -#define DRM_ROTATE_180 BIT(2) -#define DRM_ROTATE_270 BIT(3) -#define DRM_ROTATE_MASK (DRM_ROTATE_0 | DRM_ROTATE_90 | \ -DRM_ROTATE_180 | DRM_ROTATE_270) -#define DRM_REFLECT_X BIT(4) -#define DRM_REFLECT_Y BIT(5) -#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y) - static inline bool drm_rotation_90_or_270(unsigned int rotation) { return rotation & (DRM_ROTATE_90 | DRM_ROTATE_270); diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 42d9f64ce416..d7140b0091bc 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -697,6 +697,79 @@ struct drm_prime_handle { __s32 fd; }; +/** DRM_ROTATE_0 + * + * Signals that a drm plane has been rotated 0 degrees. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_ROTATE_0 BIT(0) + +/** DRM_ROTATE_90 + * + * Signals that a drm plane has been rotated 90 degrees in counter clockwise + * direction. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_ROTATE_90 BIT(1) + +/** DRM_ROTATE_180 + * + * Signals that a drm plane has been rotated 180 degrees in counter clockwise + * direction. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_ROTATE_180 BIT(2) + +/** DRM_ROTATE_270 + * + * Signals that a drm plane has been rotated 270 degrees in counter clockwise + * direction. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_ROTATE_270 BIT(3) + + +/** DRM_ROTATE_MASK + * + * Bitmask used to look for drm plane rotations. + */ +#define DRM_ROTATE_MASK (DRM_ROTATE_0 | DRM_ROTATE_90 | \ +DRM_ROTATE_180 | DRM_ROTATE_270) + +/** DRM_REFLECT_X + * + * Signals that a drm plane has been reflected in the X axis. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_REFLECT_X BIT(4) + +/** DRM_REFLECT_Y + * + * Signals that a drm plane has been reflected in the Y axis. + * + * This define is provided as a convenience, looking up the property id + * using the name->prop id lookup is the preferred method. + */ +#define DRM_REFLECT_Y BIT(5) + + +/** DRM_REFLECT_MASK + * + * Bitmask used to look for drm plane reflections. + */ +#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y) + + #if defined(__cplusplus) } #endif -- 2.11.0.453.g787f75f05 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100984] QupZilla crashes at startup after mesa upgrade
https://bugs.freedesktop.org/show_bug.cgi?id=100984 --- Comment #7 from Alexander Tsoy --- Confirming this issue with i915g driver. $ DISPLAY=:0 glxinfo | egrep 'renderer string|OpenGL version string' OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945GM) OpenGL version string: 2.1 Mesa 17.1.0-rc4 "glxgears" and "mpv --vo=opengl" segfaults: [35772.915780] mpv/vo[8568]: segfault at 12c ip 7f456c76ae76 sp 7f456dbad880 error 4 in i915g_dri.so[7f456c261000+6a9000] [35779.817131] mpv/vo[8599]: segfault at 12c ip 7f14033bce76 sp 7f1408b6a880 error 4 in i915g_dri.so[7f1402eb3000+6a9000] [35792.307840] glxgears[8625]: segfault at 12c ip 7f07ee640e76 sp 7fff2adb5900 error 4 in i915g_dri.so[7f07ee137000+6a9000] [35874.392980] glxgears[8638]: segfault at 12c ip 7f54a2cfae76 sp 7ffeb5249370 error 4 in i915g_dri.so[7f54a27f1000+6a9000] -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100984] QupZilla crashes at startup after mesa upgrade
https://bugs.freedesktop.org/show_bug.cgi?id=100984 Alexander Tsoy changed: What|Removed |Added Component|Drivers/DRI/i915|Drivers/Gallium/i915g -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3
On 05/15/2017 01:10 AM, Tommi Rantala wrote: Hi, Hey Tommi, Thanks for bisecting this. It's rather unexpected that you should be seeing problems here, but, the commit makes sense for it at least. Are you able to get me new kernel logs of both before and after this patch with "log_buf_len=8M drm.debug=0x14 nouveau.debug=disp=trace,i2c=trace,bios=trace" please? Thanks, Ben. Bisected this to: commit df8dc97cd17269474344d73cc02739532c468d04 Author: Ben Skeggs Date: Wed Mar 1 09:42:04 2017 +1000 drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm I'm not entirely sure NVKM needs to support this now, but I haven't removed it as of yet just in case it's needed from DEVINIT scripts where DRM isn't available. Signed-off-by: Ben Skeggs dmesg after boot with drm.debug enabled: v4.10-10409-g5c68d91 (still works): http://termbin.com/b0is v4.10-10410-gdf8dc97 (failure): http://termbin.com/j6lq Tommi 2017-05-10 11:24 GMT+03:00 Tommi Rantala : Hi, The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work correctly with v4.11-11413-g2868b25. When booting the laptop, the resolution seems to be limited to 1024x768, and gnome-session segfaults. Up to 4.11 the display works just fine in 1920x1080 mode. I'm seeing this in the kernel logs: nouveau :01:00.0: eDP-1: EDID is invalid: [00] BAD 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54 [00] BAD 66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [00] BAD ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1 [drm] Cannot find any crtc or sizes - going 1024x768 $ lspci | grep NVIDIA 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M2000M] (rev a2) Any ideas, or should I bisect? 4.11 dmesg & xrandr output: https://pastebin.com/raw/P9LGP7e1 4.11-11413-g2868b25 dmesg: https://pastebin.com/raw/QBT9mMua -Tommi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/9] drm/i915: Drop AUX backlight enable check for backlight control
On Fri, 2017-05-12 at 11:10 -0700, Puthikorn Voravootivat wrote: > > > On Fri, May 12, 2017 at 6:14 AM, Jani Nikula > wrote: > On Fri, 12 May 2017, "Pandiyan, Dhinakaran" > wrote: > > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat > wrote: > >> There are some panel that > >> (1) does not support display backlight enable via AUX > >> (2) support display backlight adjustment via AUX > >> (3) support display backlight enable via eDP BL_ENABLE pin > >> > >> The current driver required that (1) must be support to > enable (2). > >> This patch drops that requirement. > >> > > > > You sent this version before I finished my follow-up > questions, copying > > the conversation here for context. > > Puthikorn, please don't send new versions before the review is > addressed. > Sorry I thought I was explained it clear enough. > > Pushed patches 1, 2, 5, and 7. Thanks for the patches and > review. > > BR, > Jani. > > > DK: Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The > code below, > > in > > intel_dp_aux_display_control_capable(), makes sure > > DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least > one of these > > has to be 1. > > > > Puthikorn: We will drop the > DP_EDP_BACKLIGHT_PIN_ENABLE_CAP != 0 check > > in next patch set. > > This patch adds check here to prepare for that. > > > > > > 1) So, this patch does not really fix what the commit > message claims > > because it is dependent on the following patch. Does it make > sense to > > remove this check in this patch? That way, this patch by > itself is the > > fix that the commit message says. > > > > - !((intel_dp->edp_dpcd[1] & > DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) > > > > Sure. I can remove this here and adds it in next patch instead. > > > > > > 2) If a panel supports backlight enable via AUX and > BL_ENABLE pin, this > > patch (along with the next) enables backlight twice, doesn't > it? > > _intel_edp_backlight_on(intel_dp) in intel_dp.c is called > > unconditionally after intel_dp_aux_enable_backlight(). I > don't know how > > likely this configuration is or if it's alright to enable > via both AUX > > and BL_ENABLE pin. > > > > The eDP spec did not mention this case explicitly. > But it should not hurt to enable backlight twice as we want the > backlight to be enabled anyway. > Hope so, at least a TODO would be a reasonable warning. > > > > > > > >> Signed-off-by: Puthikorn Voravootivat > >> --- > >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 - > >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > >> index 870c03fc0f3a..c22712762957 100644 > >> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > >> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > >> @@ -28,6 +28,10 @@ static void > set_aux_backlight_enable(struct intel_dp *intel_dp, bool > enable) > >> { > >> uint8_t reg_val = 0; > >> > >> + /* Early return when display use other mechanism to > enable backlight. */ > >> +if (!(intel_dp->edp_dpcd[1] & > DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)) > >> +return; > >> + > >> if (drm_dp_dpcd_readb(&intel_dp->aux, > DP_EDP_DISPLAY_CONTROL_REGISTER, > >>®_val) < 0) { > >> DRM_DEBUG_KMS("Failed to read DPCD register 0x > %x\n", > >> @@ -164,7 +168,6 @@ > intel_dp_aux_display_control_capable(struct intel_connector > *connector) > >> * the panel can support backlight control over the > aux channel > >> */ > >> if (intel_dp->edp_dpcd[1] & > DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP && > >> -(intel_dp->edp_dpcd[1] & > DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) && > >> (intel_dp->edp_dpcd[2] & > DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) && > >> !((intel_dp->edp_dpcd[1] & > DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) || > >>(intel_dp->edp_dpcd[2] & > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) { > > > > > -- > Jani Nikula, Intel Open Source Technology Center > > >
[PATCH v7 11/13] ARM: sun8i: v3s: add device nodes for DE2 display pipeline
Allwinner V3s SoC features a "Display Engine 2.0" with only one mixer and only one TCON connected to this mixer, which have RGB LCD output. Add device nodes for this display pipeline. Signed-off-by: Icenowy Zheng --- Changes in v7: - Change DE2 clock compatible to V3s one. - Mention only one TCON in commit message. - Changed commit brief. arch/arm/boot/dts/sun8i-v3s.dtsi | 87 1 file changed, 87 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi index 71075969e5e6..b71b35734515 100644 --- a/arch/arm/boot/dts/sun8i-v3s.dtsi +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi @@ -41,6 +41,10 @@ */ #include +#include +#include +#include +#include / { #address-cells = <1>; @@ -59,6 +63,12 @@ }; }; + de: display-engine { + compatible = "allwinner,sun8i-v3s-display-engine"; + allwinner,pipelines = <&de2_mixer0>; + status = "disabled"; + }; + timer { compatible = "arm,armv7-timer"; interrupts = , @@ -93,6 +103,83 @@ #size-cells = <1>; ranges; + de2_clocks: clock@100 { + compatible = "allwinner,sun8i-v3s-de2-clk"; + reg = <0x0100 0x10>; + clocks = <&ccu CLK_DE>, +<&ccu CLK_BUS_DE>; + clock-names = "mod", + "bus"; + resets = <&ccu RST_BUS_DE>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + de2_mixer0: mixer@110 { + compatible = "allwinner,sun8i-v3s-de2-mixer"; + reg = <0x0110 0x10>; + clocks = <&de2_clocks CLK_MIXER0>, +<&de2_clocks CLK_BUS_MIXER0>; + clock-names = "mod", + "bus"; + resets = <&de2_clocks RST_MIXER0>; + assigned-clocks = <&de2_clocks CLK_MIXER0>; + assigned-clock-rates = <15000>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mixer0_out: port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + mixer0_out_tcon0: endpoint@0 { + reg = <0>; + remote-endpoint = <&tcon0_in_mixer0>; + }; + }; + }; + }; + + tcon0: lcd-controller@1c0c000 { + compatible = "allwinner,sun8i-v3s-tcon"; + reg = <0x01c0c000 0x1000>; + interrupts = ; + clocks = <&ccu CLK_BUS_TCON0>, +<&ccu CLK_TCON0>; + clock-names = "ahb", + "tcon-ch0"; + clock-output-names = "tcon-pixel-clock"; + resets = <&ccu RST_BUS_TCON0>; + reset-names = "lcd"; + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + tcon0_in: port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + tcon0_in_mixer0: endpoint@0 { + reg = <0>; + remote-endpoint = <&mixer0_out_tcon0>; + }; + }; + + tcon0_out: port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + }; + }; + }; + + mmc0: mmc@01c0f000 { compatible = "allwinner,sun7i-a20-mmc"; reg = <0x01c0f000 0x1000>; -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id
On 14.05.2017 16:02, Dmitry Osipenko wrote: > On 14.05.2017 14:53, Mikko Perttunen wrote: >> On 05/12/2017 10:00 PM, Dmitry Osipenko wrote: >>> The start = 0 is invalid and causes weird CDMA channel timeouts, presumably >>> some memory misuse/corruption is going on. >> >> What makes you think start = 0 is invalid? I can't see anything pointing to >> that >> in the idr code and there are many users in the kernel passing 0 as start. >> > > Well, I can't see either. You are right that there are quite many others with > 0 > as a start, the 1 probably just masks the bug. > Finally, I found the root of the issue. The job->client is set to the context ID in the tegra_drm_submit() and the host1x_cdma sets client ID to 0 to mark CDMA job timeout timer as already armed. I'll send V2 with a new commit description. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/tegra: Fix lockup on a use of staging API
Reviewed-by: Mikko Perttunen On 05/12/2017 10:00 PM, Dmitry Osipenko wrote: Commit bdd2f9cd ("Don't leak kernel pointer to userspace") added a mutex around staging IOCTL's, some of those mutexes are taken twice. Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace") Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index ab2dfd4e4bd9..768750226452 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -430,18 +430,6 @@ int tegra_drm_submit(struct tegra_drm_context *context, #ifdef CONFIG_DRM_TEGRA_STAGING -static struct tegra_drm_context * -tegra_drm_file_get_context(struct tegra_drm_file *file, u32 id) -{ - struct tegra_drm_context *context; - - mutex_lock(&file->lock); - context = idr_find(&file->contexts, id); - mutex_unlock(&file->lock); - - return context; -} - static int tegra_gem_create(struct drm_device *drm, void *data, struct drm_file *file) { @@ -585,7 +573,7 @@ static int tegra_close_channel(struct drm_device *drm, void *data, mutex_lock(&fpriv->lock); - context = tegra_drm_file_get_context(fpriv, args->context); + context = idr_find(&fpriv->contexts, args->context); if (!context) { err = -EINVAL; goto unlock; @@ -610,7 +598,7 @@ static int tegra_get_syncpt(struct drm_device *drm, void *data, mutex_lock(&fpriv->lock); - context = tegra_drm_file_get_context(fpriv, args->context); + context = idr_find(&fpriv->contexts, args->context); if (!context) { err = -ENODEV; goto unlock; @@ -639,7 +627,7 @@ static int tegra_submit(struct drm_device *drm, void *data, mutex_lock(&fpriv->lock); - context = tegra_drm_file_get_context(fpriv, args->context); + context = idr_find(&fpriv->contexts, args->context); if (!context) { err = -ENODEV; goto unlock; @@ -664,7 +652,7 @@ static int tegra_get_syncpt_base(struct drm_device *drm, void *data, mutex_lock(&fpriv->lock); - context = tegra_drm_file_get_context(fpriv, args->context); + context = idr_find(&fpriv->contexts, args->context); if (!context) { err = -ENODEV; goto unlock; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer
On 14.05.2017 15:56, Mikko Perttunen wrote: > > > On 05/14/2017 03:45 PM, Dmitry Osipenko wrote: >> On 14.05.2017 15:27, Mikko Perttunen wrote: >>> On 05/12/2017 10:29 PM, Dmitry Osipenko wrote: If command buffer claims a number of words that is higher than its BO can fit and a relocation lays past the BO, a kernel OOPS will be fired on that relocation address patching. This was triggered by an opentegra Xorg driver that erroneously pushed too many commands to the pushbuf. [ 46.829393] Unable to handle kernel paging request at virtual address f09b2000 ... [] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510) [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c) [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec) [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Dmitry Osipenko --- v2: Take into account the cmdbuf.offset drivers/gpu/drm/tegra/drm.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 732c8d98044f..9ad4ac7c08d1 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context, while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; -struct host1x_bo *bo; +struct drm_gem_object *gem; +struct tegra_bo *bo; if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) { err = -EFAULT; goto fail; } -bo = host1x_bo_lookup(file, cmdbuf.handle); -if (!bo) { +gem = drm_gem_object_lookup(file, cmdbuf.handle); +if (!gem) { err = -ENOENT; goto fail; } -host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset); +drm_gem_object_unreference_unlocked(gem); + +if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) { +err = -EINVAL; +goto fail; +} >>> >>> Nasty bug! Well found. Two points: the arithmetic here could overflow, so >>> userspace could supply some large values for offset/words and this check >>> would >>> not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking >>> at >>> the code closer, I can't see any bounds checking for relocs either.. That >>> code >>> (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so >>> we >>> could e.g. change host1x_bo_lookup to take offset and words parameters and >>> verify those at the same time. >>> >> Good point, unfortunately there are a lot of ways to abuse the staging API on >> the IOMMU-less Tegra20 right now. >> > > Indeed, though I think the relocation issue would be a problem on > IOMMU-enabled > systems as well. The Tegra20 and firewall have always been in a bit a bad > position, as I'm not sure if the firewall was ever used in production during > Tegra20's prime time, and of course it was quickly abandoned in downstream > when > we got IOMMUs on later chips. > In the IOMMU case some BO will be corrupted in the worst case and it's a userspace problem, while in the non-IOMMU it will be an arbitrary phys memory. Anyway it should be better to fail explicitly in any case. > Thanks for contributing :) My pleasure ;) -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt
On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote: > Read desired PWM frequency from panel vbt and calculate the > value for divider in DPCD address 0x724 and 0x728 to have > as many bits as possible for PWM duty cyle for granularity of > brightness adjustment while the frequency is still within 25% > of the desired frequency. I read a few eDP panel data sheets, the PWM frequencies all start from ~200Hz. If the VBT chooses this lowest value to allow for more brightness control, and then this patch lowers the value by another 25%, we'll end up below the panel allowed PWM frequency. In fact, one of the systems I checked had PWM frequency as 200Hz in VBT and the panel datasheet also had PWM frequency range starting from 200Hz. Have you considered this case? -DK > > Signed-off-by: Puthikorn Voravootivat > --- > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 > +++ > 1 file changed, 81 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > index 0b48851013cc..6f10a2f1ab76 100644 > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > @@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct > intel_dp *intel_dp, > } > } > > +/* > + * Set PWM Frequency divider to match desired frequency in vbt. > + * The PWM Frequency is calculated as 27Mhz / (F x P). > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h) > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h) > + */ > +static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector) > +{ > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > + struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base); > + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1; > + u8 pn, pn_min, pn_max; > + > + /* Find desired value of (F x P) > + * Note that, if F x P is out of supported range, the maximum value or > + * minimum value will applied automatically. So no need to check that. > + */ > + freq = dev_priv->vbt.backlight.pwm_freq_hz; > + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq); > + if (!freq) { > + DRM_DEBUG_KMS("Use panel default backlight frequency\n"); > + return; > + } > + > + fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq; > + > + /* Use highest possible value of Pn for more granularity of brightness > + * adjustment while satifying the conditions below. > + * - Pn is in the range of Pn_min and Pn_max > + * - F is in the range of 1 and 255 > + * - Effective frequency is within 25% of desired frequency. > + */ > + if (drm_dp_dpcd_readb(&intel_dp->aux, > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) { > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n"); > + return; > + } > + if (drm_dp_dpcd_readb(&intel_dp->aux, > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) { > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n"); > + return; > + } > + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK; > + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK; > + > + fxp_min = fxp * 3 / 4; > + fxp_max = fxp * 5 / 4; You are allowing fxp between +/- 25% of the actual. This isn't same as the "Effective frequency is within 25% of desired frequency." right? The frequency can vary between -20% and +33%. > + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) { > + DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n"); > + return; > + } > + > + for (pn = pn_max; pn > pn_min; pn--) { > + f = clamp(fxp >> pn, 1, 255); > + fxp_actual = f << pn; > + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max) > + break; > + } > + > + if (drm_dp_dpcd_writeb(&intel_dp->aux, > +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) { > + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n"); > + return; > + } > + if (drm_dp_dpcd_writeb(&intel_dp->aux, > +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) { > + DRM_DEBUG_KMS("Failed to write aux backlight freq\n"); > + return; > + } > +} > + > static void intel_dp_aux_enable_backlight(struct intel_connector *connector) > { > struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base); > uint8_t dpcd_buf = 0; > uint8_t new_dpcd_buf = 0; > uint8_t edp_backlight_mode = 0; > + bool freq_cap; > > if (drm_dp_dpcd_readb(&intel_d
[PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations
If commands buffer claims a number of words that is higher than its BO can fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was triggered by an opentegra Xorg driver that erroneously pushed too many commands to the pushbuf. The CMDA commands buffer address is 4 bytes aligned, so check the alignment as well. Add a sanity check for the relocations in a same way. [ 46.829393] Unable to handle kernel paging request at virtual address f09b2000 ... [] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510) [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c) [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec) [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Dmitry Osipenko Reviewed-by: Erik Faye-Lund --- drivers/gpu/drm/tegra/drm.c | 30 ++ drivers/gpu/drm/tegra/gem.c | 5 - drivers/gpu/drm/tegra/gem.h | 5 + 3 files changed, 35 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 768750226452..c5844a065681 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -362,6 +362,8 @@ int tegra_drm_submit(struct tegra_drm_context *context, while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; struct host1x_bo *bo; + struct tegra_bo *obj; + u64 offset; if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) { err = -EFAULT; @@ -374,6 +376,14 @@ int tegra_drm_submit(struct tegra_drm_context *context, goto fail; } + offset = (u64)cmdbuf.offset + (u64)cmdbuf.words * sizeof(u32); + obj = host1x_to_tegra_bo(bo); + + if (offset & 3 || offset > obj->gem.size) { + err = -EINVAL; + goto fail; + } + host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset); num_cmdbufs--; cmdbufs++; @@ -381,11 +391,31 @@ int tegra_drm_submit(struct tegra_drm_context *context, /* copy and resolve relocations from submit */ while (num_relocs--) { + struct host1x_reloc *reloc; + struct tegra_bo *obj; + err = host1x_reloc_copy_from_user(&job->relocarray[num_relocs], &relocs[num_relocs], drm, file); if (err < 0) goto fail; + + reloc = &job->relocarray[num_relocs]; + obj = host1x_to_tegra_bo(reloc->cmdbuf.bo); + + if (reloc->cmdbuf.offset & 3 || + reloc->cmdbuf.offset > obj->gem.size) { + err = -EINVAL; + goto fail; + } + + obj = host1x_to_tegra_bo(reloc->target.bo); + + if (reloc->target.offset & 3 || + reloc->target.offset > obj->gem.size) { + err = -EINVAL; + goto fail; + } } if (copy_from_user(job->waitchk, waitchks, diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c index b76d7ac75696..a0ff30c01ac1 100644 --- a/drivers/gpu/drm/tegra/gem.c +++ b/drivers/gpu/drm/tegra/gem.c @@ -20,11 +20,6 @@ #include "drm.h" #include "gem.h" -static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo) -{ - return container_of(bo, struct tegra_bo, base); -} - static void tegra_bo_put(struct host1x_bo *bo) { struct tegra_bo *obj = host1x_to_tegra_bo(bo); diff --git a/drivers/gpu/drm/tegra/gem.h b/drivers/gpu/drm/tegra/gem.h index 6c5f12ac0087..8b32a6fd586d 100644 --- a/drivers/gpu/drm/tegra/gem.h +++ b/drivers/gpu/drm/tegra/gem.h @@ -52,6 +52,11 @@ static inline struct tegra_bo *to_tegra_bo(struct drm_gem_object *gem) return container_of(gem, struct tegra_bo, gem); } +static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo) +{ + return container_of(bo, struct tegra_bo, base); +} + struct tegra_bo *tegra_bo_create(struct drm_device *drm, size_t size, unsigned long flags); struct tegra_bo *tegra_bo_create_with_handle(struct drm_file *file, -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()
This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed commands buffer CMA while patching relocations in do_relocs(). Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c index 424569b53e57..b76d7ac75696 100644 --- a/drivers/gpu/drm/tegra/gem.c +++ b/drivers/gpu/drm/tegra/gem.c @@ -74,6 +74,9 @@ static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page) { struct tegra_bo *obj = host1x_to_tegra_bo(bo); + if (page * PAGE_SIZE > obj->gem.size) + return NULL; + if (obj->vaddr) return obj->vaddr + page * PAGE_SIZE; else if (obj->gem.import_attach) -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/13] Get rid of DocBook
As just one book (lsm) was missing conversion, let's convert it and store as if it were a plain text file under Documentation/lsm.txt, adding a notice that it requires update. This way, as everything is now converted, we can get rid of the DocBook building system and update places that were mentioning it. PS.: We could also remove the parts of the kernel-doc script that produce DocBook outputs, but, as this might still be useful for someone, for now let's just keep the functionality there. - This patch series is based on my past 00/05 and 00/36 patch series that convert the other DocBooks to ReST, applied on the top of docs tree (next branch). The full patch series is on this tree is at: https://git.linuxtv.org//mchehab/experimental.git/log/?h=docbook2 And the HTML output at: http://www.infradead.org/~mchehab/kernel_docs/ https://mchehab.fedorapeople.org/kernel_docs/ Mauro Carvalho Chehab (13): docs-rst: convert lsm from DocBook to ReST docs: remove DocBook from the building system docs: update old references for DocBook from the documentation MAINTAINERS: update old references for DocBook directory ata: update references for libata documentation ia64, scsi: update references for the device-io book irq: update genericirq book location fs: update location of filesystems documentation lib: update location of kgdb documentation sound: fix the comments that refers to kernel-doc fs: fix the location of the kernel-api book usb: fix the comment with regards to DocBook docs-rst: get rid of Documentation/sphinx/tmplcvt script Documentation/00-INDEX | 6 +- Documentation/DocBook/.gitignore | 17 -- Documentation/DocBook/Makefile | 276 - Documentation/DocBook/lsm.tmpl | 265 --- Documentation/DocBook/stylesheet.xsl | 11 -- Documentation/Makefile | 125 + Documentation/Makefile.sphinx | 130 -- Documentation/PCI/MSI-HOWTO.txt| 2 +- Documentation/admin-guide/README.rst | 6 - Documentation/doc-guide/docbook.rst| 90 -- Documentation/doc-guide/index.rst | 1 - Documentation/doc-guide/sphinx.rst | 5 - Documentation/fb/api.txt | 4 +- Documentation/gpu/todo.rst | 2 +- Documentation/kernel-doc-nano-HOWTO.txt| 65 ++- Documentation/lsm.txt | 201 + Documentation/process/changes.rst | 26 +-- Documentation/process/howto.rst| 8 - Documentation/process/kernel-docs.rst | 34 +--- Documentation/sphinx/tmplcvt | 28 --- Documentation/translations/ja_JP/howto.rst | 7 - Documentation/translations/ko_KR/howto.rst | 7 - MAINTAINERS| 5 +- Makefile | 11 +- arch/ia64/include/asm/io.h | 2 +- arch/ia64/sn/kernel/iomv.c | 2 +- drivers/ata/acard-ahci.c | 2 +- drivers/ata/ahci.c | 2 +- drivers/ata/ahci.h | 2 +- drivers/ata/ata_piix.c | 2 +- drivers/ata/libahci.c | 2 +- drivers/ata/libata-core.c | 2 +- drivers/ata/libata-eh.c| 2 +- drivers/ata/libata-scsi.c | 2 +- drivers/ata/libata-sff.c | 2 +- drivers/ata/libata.h | 2 +- drivers/ata/pata_pdc2027x.c| 2 +- drivers/ata/pdc_adma.c | 2 +- drivers/ata/sata_nv.c | 2 +- drivers/ata/sata_promise.c | 2 +- drivers/ata/sata_promise.h | 2 +- drivers/ata/sata_qstor.c | 2 +- drivers/ata/sata_sil.c | 2 +- drivers/ata/sata_sis.c | 2 +- drivers/ata/sata_svw.c | 2 +- drivers/ata/sata_sx4.c | 2 +- drivers/ata/sata_uli.c | 2 +- drivers/ata/sata_via.c | 2 +- drivers/ata/sata_vsc.c | 2 +- drivers/scsi/qla1280.c | 2 +- drivers/usb/gadget/Kconfig | 2 +- fs/debugfs/file.c | 2 +- fs/debugfs/inode.c | 2 +- include/linux/ata.h| 2 +- include/linux/debugfs.h| 2 +- include/linux/libata.h | 2 +- include/sound/pcm.h| 2 +- kernel/irq/chip.c | 2 +- kernel/irq/handle.c| 2 +- kernel/irq/irqdesc.c | 2 +- lib/Kconfig.debug | 2 +- lib/Kconfig.kgdb | 2 +- scripts/Makefile
Re: Notifications about ACPI events in userspace?
On 14.05.2017 10:11, Lukas Wunner wrote: > On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote: >> On 13.05.2017 14:18, Lukas Wunner wrote: >>> >>> Then you could switch back and forth via the vga_switcheroo interface. >> >> Hm... since there's no power switching of any kind involved, would that >> still make sense? > > The handler's ->power_state hook would be a no-op. Obviously not pretty, > but we just don't have a better abstraction yet. We represent an egress > connector on a graphics card as a drm_connector in sysfs. What we might > need is a representation of a sink (display) in sysfs with symlinks to the > sources. Such a source could be a drm_connector or something else > entirely (a GPU on another machine in your case). OK, I think it's the closest thing that's already in the kernel, and before I add yet another custom sysfs node, vga_switcheroo is probably the easiest route to get things up and running. >> AFAICT, the alternative (which maybe would be more sensible, the more I >> think about it) would be to export applesmc_{read,write}_key as public >> symbols and just access them from a standalone driver for the APP000C >> ACPI device. Since that should only be present on a Mac that actually >> supports TDM, there's also no risk of writing to arbitrary SMC keys on >> unsupported devices. > > That might make sense if you feel the driver will grow large enough to > make applesmc.c look messy, or if you feel it just doesn't fit there. Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge. So for applesmc, I'd just need a tiny patch to export the main key access functions, and everything else can (hopefully) be encapsulated in an "apple-tdm" driver. > I guess the only reason why Apple integrated the functionality into the > SMC is because they wanted to support TDM when the machine is powered off. > The SMC is powered even in S5 (if the iMac is connected to AC), it just > needs to monitor HPD on the external port and turn on the backlight if > something is plugged in. (I'm not sure if TDM is actually supported > during poweroff but technically it would seem to be supported.) Hm, interesting, I hadn't yet thought of that. This would of course be excellent, because right now it looks like a waste of power to run the whole machine just because of the display. Does the SMC have control over the backlight? Do you know which keys are responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway... Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt
On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com> wrote: > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote: > > Read desired PWM frequency from panel vbt and calculate the > > value for divider in DPCD address 0x724 and 0x728 to have > > as many bits as possible for PWM duty cyle for granularity of > > brightness adjustment while the frequency is still within 25% > > of the desired frequency. > > I read a few eDP panel data sheets, the PWM frequencies all start from > ~200Hz. If the VBT chooses this lowest value to allow for more > brightness control, and then this patch lowers the value by another 25%, > we'll end up below the panel allowed PWM frequency. > > In fact, one of the systems I checked had PWM frequency as 200Hz in VBT > and the panel datasheet also had PWM frequency range starting from > 200Hz. Have you considered this case? > > The spec said "A given LCD panel typically has a limited range of backlight frequency capability. To limit the programmable frequency range, limitations are placed on the allowable total divider ratio with the Sink device" So I think it should be auto cap to 200Hz in this case. > -DK > > > > Signed-off-by: Puthikorn Voravootivat > > --- > > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 > +++ > > 1 file changed, 81 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > > index 0b48851013cc..6f10a2f1ab76 100644 > > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c > > @@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct > intel_dp *intel_dp, > > } > > } > > > > +/* > > + * Set PWM Frequency divider to match desired frequency in vbt. > > + * The PWM Frequency is calculated as 27Mhz / (F x P). > > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 > of the > > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h) > > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of > the > > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h) > > + */ > > +static void intel_dp_aux_set_pwm_freq(struct intel_connector > *connector) > > +{ > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > > + struct intel_dp *intel_dp = enc_to_intel_dp(&connector-> > encoder->base); > > + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1; > > + u8 pn, pn_min, pn_max; > > + > > + /* Find desired value of (F x P) > > + * Note that, if F x P is out of supported range, the maximum > value or > > + * minimum value will applied automatically. So no need to check > that. > > + */ > > + freq = dev_priv->vbt.backlight.pwm_freq_hz; > > + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq); > > + if (!freq) { > > + DRM_DEBUG_KMS("Use panel default backlight frequency\n"); > > + return; > > + } > > + > > + fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq; > > + > > + /* Use highest possible value of Pn for more granularity of > brightness > > + * adjustment while satifying the conditions below. > > + * - Pn is in the range of Pn_min and Pn_max > > + * - F is in the range of 1 and 255 > > + * - Effective frequency is within 25% of desired frequency. > > + */ > > + if (drm_dp_dpcd_readb(&intel_dp->aux, > > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) > != 1) { > > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n"); > > + return; > > + } > > + if (drm_dp_dpcd_readb(&intel_dp->aux, > > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) > != 1) { > > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n"); > > + return; > > + } > > + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK; > > + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK; > > + > > + fxp_min = fxp * 3 / 4; > > + fxp_max = fxp * 5 / 4; > > You are allowing fxp between +/- 25% of the actual. This isn't same as > the "Effective frequency is within 25% of desired frequency." right? The > frequency can vary between -20% and +33%. > > You are right. You want me to change commit message to reflect this or change the code to match the commit message? > > > + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) { > > + DRM_DEBUG_KMS("VBT defined backlight frequency out of > range\n"); > > + return; > > + } > > + > > + for (pn = pn_max; pn > pn_min; pn--) { > > + f = clamp(fxp >> pn, 1, 255); > > + fxp_actual = f << pn; > > + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max) > > + break; > > + } > > + > > + if (drm_dp_dpcd_writeb(&intel_dp->aux, > > +DP_EDP
Re: [PATCH 00/13] Get rid of DocBook
Em Sun, 14 May 2017 14:05:09 -0700 Kees Cook escreveu: > On Sun, May 14, 2017 at 8:38 AM, Mauro Carvalho Chehab > wrote: > > As just one book (lsm) was missing conversion, let's convert it > > and store as if it were a plain text file under Documentation/lsm.txt, > > adding a notice that it requires update. > > I could probably fold this change into my rst-ification of > Documentation/security/ > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/rst > > Specifically, the new Documentation/security/LSM.rst was rather short. > I think your lsm.txt and this one could be likely merged. Yeah, makes sense. I'm not sure what would be the best way to proceed, as, currently, after removing lsm.tmpl, my patch series remove DocBook, as everything else was already removed. I see a few ways for us to proceed: 1) You could submit the patches you have so far to docs -next, to be merged before my patch series; 2) I could send you a patch based on your tree. I'll need to rebase this series to be applied on the top of your tree + docs-next, with would require that your patch series would be merged before, at docs -next; 3) we can handle both series independently. When both gets merged at docs -next, a simple patch, either written by you or me, could merge both files. IMO, (3) is simpler, but if you prefer, we can do on some other way. Thanks, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 03/13] dt-bindings: add bindings for DE2 on V3s SoC
Allwinner V3s SoC have a display engine which have a different pipeline with older SoCs. Add document for it (new compatibles and the new "mixer" part). Signed-off-by: Icenowy Zheng Acked-by: Rob Herring --- Changes in v7: - Reduced some text. Changes in v4: - Removed the refactor at TCON chapter. Changes in v3: - Remove the description of having a BE directly as allwinner,pipeline. .../bindings/display/sunxi/sun4i-drm.txt | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 7acdbf14ae1c..66b85a195ef2 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -41,6 +41,7 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. Three are needed: @@ -62,7 +63,7 @@ Required properties: second the block connected to the TCON channel 1 (usually the TV encoder) -On SoCs other than the A33, there is one more clock required: +On SoCs other than the A33 and V3s, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 DRC @@ -148,6 +149,26 @@ Required properties: Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoints, the second one the outputs +Display Engine 2.0 Mixer + + +The DE2 mixer have many functionalities, currently only layer blending is +supported. + +Required properties: + - compatible: value must be one of: +* allwinner,sun8i-v3s-de2-mixer + - reg: base address and size of the memory-mapped region. + - clocks: phandles to the clocks feeding the mixer +* bus: the mixer interface clock +* mod: the mixer module clock + - clock-names: the clock names mentioned above + - resets: phandles to the reset controllers driving the mixer + +- ports: A ports node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + first port should be the input endpoints, the second one the output + Display Engine Pipeline --- @@ -162,9 +183,10 @@ Required properties: * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine * allwinner,sun8i-a33-display-engine +* allwinner,sun8i-v3s-display-engine - allwinner,pipelines: list of phandle to the display engine -frontends available. +frontends (DE 1.0) or mixers (DE 2.0) available. Example: -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id
On 14.05.2017 14:53, Mikko Perttunen wrote: > On 05/12/2017 10:00 PM, Dmitry Osipenko wrote: >> The start = 0 is invalid and causes weird CDMA channel timeouts, presumably >> some memory misuse/corruption is going on. > > What makes you think start = 0 is invalid? I can't see anything pointing to > that > in the idr code and there are many users in the kernel passing 0 as start. > Well, I can't see either. You are right that there are quite many others with 0 as a start, the 1 probably just masks the bug. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer
On 05/14/2017 03:45 PM, Dmitry Osipenko wrote: On 14.05.2017 15:27, Mikko Perttunen wrote: On 05/12/2017 10:29 PM, Dmitry Osipenko wrote: If command buffer claims a number of words that is higher than its BO can fit and a relocation lays past the BO, a kernel OOPS will be fired on that relocation address patching. This was triggered by an opentegra Xorg driver that erroneously pushed too many commands to the pushbuf. [ 46.829393] Unable to handle kernel paging request at virtual address f09b2000 ... [] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510) [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c) [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec) [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Dmitry Osipenko --- v2: Take into account the cmdbuf.offset drivers/gpu/drm/tegra/drm.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 732c8d98044f..9ad4ac7c08d1 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context, while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; -struct host1x_bo *bo; +struct drm_gem_object *gem; +struct tegra_bo *bo; if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) { err = -EFAULT; goto fail; } -bo = host1x_bo_lookup(file, cmdbuf.handle); -if (!bo) { +gem = drm_gem_object_lookup(file, cmdbuf.handle); +if (!gem) { err = -ENOENT; goto fail; } -host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset); +drm_gem_object_unreference_unlocked(gem); + +if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) { +err = -EINVAL; +goto fail; +} Nasty bug! Well found. Two points: the arithmetic here could overflow, so userspace could supply some large values for offset/words and this check would not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking at the code closer, I can't see any bounds checking for relocs either.. That code (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so we could e.g. change host1x_bo_lookup to take offset and words parameters and verify those at the same time. Good point, unfortunately there are a lot of ways to abuse the staging API on the IOMMU-less Tegra20 right now. Indeed, though I think the relocation issue would be a problem on IOMMU-enabled systems as well. The Tegra20 and firewall have always been in a bit a bad position, as I'm not sure if the firewall was ever used in production during Tegra20's prime time, and of course it was quickly abandoned in downstream when we got IOMMUs on later chips. Thanks for contributing :) Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: host1x: Initialize firewall class to the jobs one
The commands stream is prepended by the jobs class on the CDMA submission, so that explicitly setting a module class in the commands stream isn't necessary. The firewall initializes its class to 0 and the command stream that doesn't explicitly specify the class effectively bypasses the firewall. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index 5f5f8ee6143d..d9933828fe87 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -504,7 +504,7 @@ static inline int copy_gathers(struct host1x_job *job, struct device *dev) fw.dev = dev; fw.reloc = job->relocarray; fw.num_relocs = job->num_relocs; - fw.class = 0; + fw.class = job->class; for (i = 0; i < job->num_gathers; i++) { struct host1x_job_gather *g = &job->gathers[i]; -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 01/13] dt-bindings: add binding for the Allwinner DE2 CCU
Allwinner "Display Engine 2.0" contains some clock controls in it. In order to add them as clock drivers, we need a device tree binding. Add the binding here. Also add the device tree binding headers. Signed-off-by: Icenowy Zheng Acked-by: Rob Herring --- Changes in v7: - Added V3s compatible. Changes in v6: - Added Rob's ACK. - Droped A64's compatible as it's not appropriate now. Changes in v5: - Moved dt-binding headers here. - Changed dt-binding headers' license header to SPDX license. Changes in v4: - Dropped the leading 0 in clock at 100 . Changes in v3: - Fill the address space length of DE2 CCU to 0x10, just reach the start of mixer0. .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++ include/dt-bindings/clock/sun8i-de2.h | 18 + include/dt-bindings/reset/sun8i-de2.h | 14 ++ 3 files changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt create mode 100644 include/dt-bindings/clock/sun8i-de2.h create mode 100644 include/dt-bindings/reset/sun8i-de2.h diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt new file mode 100644 index ..631d27cd89d6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt @@ -0,0 +1,31 @@ +Allwinner Display Engine 2.0 Clock Control Binding +-- + +Required properties : +- compatible: must contain one of the following compatibles: + - "allwinner,sun8i-a83t-de2-clk" + - "allwinner,sun8i-v3s-de2-clk" + - "allwinner,sun50i-h5-de2-clk" + +- reg: Must contain the registers base address and length +- clocks: phandle to the clocks feeding the display engine subsystem. + Three are needed: + - "mod": the display engine module clock + - "bus": the bus clock for the whole display engine subsystem +- clock-names: Must contain the clock names described just above +- resets: phandle to the reset control for the display engine subsystem. +- #clock-cells : must contain 1 +- #reset-cells : must contain 1 + +Example: +de2_clocks: clock@100 { + compatible = "allwinner,sun8i-a83t-de2-clk"; + reg = <0x0100 0x10>; + clocks = <&ccu CLK_BUS_DE>, +<&ccu CLK_DE>; + clock-names = "bus", + "mod"; + resets = <&ccu RST_BUS_DE>; + #clock-cells = <1>; + #reset-cells = <1>; +}; diff --git a/include/dt-bindings/clock/sun8i-de2.h b/include/dt-bindings/clock/sun8i-de2.h new file mode 100644 index ..3bed63b524aa --- /dev/null +++ b/include/dt-bindings/clock/sun8i-de2.h @@ -0,0 +1,18 @@ +/* + * Copyright (C) 2016 Icenowy Zheng + * + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) + */ + +#ifndef _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ +#define _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ + +#define CLK_BUS_MIXER0 0 +#define CLK_BUS_MIXER1 1 +#define CLK_BUS_WB 2 + +#define CLK_MIXER0 6 +#define CLK_MIXER1 7 +#define CLK_WB 8 + +#endif /* _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ */ diff --git a/include/dt-bindings/reset/sun8i-de2.h b/include/dt-bindings/reset/sun8i-de2.h new file mode 100644 index ..9526017432f0 --- /dev/null +++ b/include/dt-bindings/reset/sun8i-de2.h @@ -0,0 +1,14 @@ +/* + * Copyright (C) 2016 Icenowy Zheng + * + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) + */ + +#ifndef _DT_BINDINGS_RESET_SUN8I_DE2_H_ +#define _DT_BINDINGS_RESET_SUN8I_DE2_H_ + +#define RST_MIXER0 0 +#define RST_MIXER1 1 +#define RST_WB 2 + +#endif /* _DT_BINDINGS_RESET_SUN8I_DE2_H_ */ -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer
On 12.05.2017 22:29, Dmitry Osipenko wrote: > If command buffer claims a number of words that is higher than its BO can > fit and a relocation lays past the BO, a kernel OOPS will be fired on that > relocation address patching. This was triggered by an opentegra Xorg driver > that erroneously pushed too many commands to the pushbuf. > For the record, this patch is superseded by the "drm/tegra: Check offsets of a submitted command buffer and of relocations." -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 04/13] drm/sun4i: return only planes for layers created
As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm driver, we will finally have two types of layers. Each layer is bound to a drm_plane that is CRTC-specific, so we create them when initializing CRTC (calling sun4i_layers_init, which will be generalized in next patch). The drm_plane's will be used when creating CRTC, but the CRTC initialization code do not care other properties of the layer, so we let the sun4i_layers_init function return drm_plane's only. As we have no need to trace the layers after the CRTC is properly created, we drop the layers pointer in sun4i_crtc struct. Doing this uncouples the CRTC code from the type of layer (the sun4i_layers_init function name is still hardcoded and will be changed in the next patch), so that we can finally gain support for the mixer in DE2, which has different layers. Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_crtc.c | 23 --- drivers/gpu/drm/sun4i/sun4i_crtc.h | 1 - drivers/gpu/drm/sun4i/sun4i_layer.c | 18 ++ drivers/gpu/drm/sun4i/sun4i_layer.h | 4 ++-- 4 files changed, 24 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c b/drivers/gpu/drm/sun4i/sun4i_crtc.c index 3c876c3a356a..708b3543d4e9 100644 --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c @@ -139,6 +139,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm, struct sun4i_tcon *tcon) { struct sun4i_crtc *scrtc; + struct drm_plane **planes; struct drm_plane *primary = NULL, *cursor = NULL; int ret, i; @@ -149,22 +150,22 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm, scrtc->tcon = tcon; /* Create our layers */ - scrtc->layers = sun4i_layers_init(drm, scrtc->backend); - if (IS_ERR(scrtc->layers)) { + planes = sun4i_layers_init(drm, scrtc); + if (IS_ERR(planes)) { dev_err(drm->dev, "Couldn't create the planes\n"); return NULL; } /* find primary and cursor planes for drm_crtc_init_with_planes */ - for (i = 0; scrtc->layers[i]; i++) { - struct sun4i_layer *layer = scrtc->layers[i]; + for (i = 0; planes[i]; i++) { + struct drm_plane *plane = planes[i]; - switch (layer->plane.type) { + switch (plane->type) { case DRM_PLANE_TYPE_PRIMARY: - primary = &layer->plane; + primary = plane; break; case DRM_PLANE_TYPE_CURSOR: - cursor = &layer->plane; + cursor = plane; break; default: break; @@ -188,12 +189,12 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm, 1); /* Set possible_crtcs to this crtc for overlay planes */ - for (i = 0; scrtc->layers[i]; i++) { + for (i = 0; planes[i]; i++) { uint32_t possible_crtcs = BIT(drm_crtc_index(&scrtc->crtc)); - struct sun4i_layer *layer = scrtc->layers[i]; + struct drm_plane *plane = planes[i]; - if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY) - layer->plane.possible_crtcs = possible_crtcs; + if (plane->type == DRM_PLANE_TYPE_OVERLAY) + plane->possible_crtcs = possible_crtcs; } return scrtc; diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h b/drivers/gpu/drm/sun4i/sun4i_crtc.h index 230cb8f0d601..4dae3508424a 100644 --- a/drivers/gpu/drm/sun4i/sun4i_crtc.h +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h @@ -19,7 +19,6 @@ struct sun4i_crtc { struct sun4i_backend*backend; struct sun4i_tcon *tcon; - struct sun4i_layer **layers; }; static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc) diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c index f26bde5b9117..e1f03e1cc0ac 100644 --- a/drivers/gpu/drm/sun4i/sun4i_layer.c +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c @@ -16,6 +16,7 @@ #include #include "sun4i_backend.h" +#include "sun4i_crtc.h" #include "sun4i_layer.h" struct sun4i_plane_desc { @@ -128,15 +129,16 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm, return layer; } -struct sun4i_layer **sun4i_layers_init(struct drm_device *drm, - struct sun4i_backend *backend) +struct drm_plane **sun4i_layers_init(struct drm_device *drm, +struct sun4i_crtc *crtc) { - struct sun4i_layer **layers; + struct drm_plane **planes; + struct sun4i_backend *backend = crtc->backend; int i; - layer
[PATCH v7 13/13] [DO NOT MERGE] ARM: sun8i: v3s: enable LCD panel of Lichee Pi Zero
A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi. This commit connects this panel to Lichee Pi Zero. Lichee Pi also provides a 800x480 panel without accurate model number, so do not merge this patch. It will finally come as device tree overlay. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 +++ 1 file changed, 36 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts index 387fc2aa546d..7ae72bf63cd0 100644 --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts @@ -75,6 +75,28 @@ gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */ }; }; + + panel: panel { + compatible = "qiaodian,qd43003c0-40", "simple-panel"; + enable-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* Should be backlight */ + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + panel_input: endpoint@0 { + reg = <0>; + remote-endpoint = <&tcon0_out_lcd>; + }; + }; + }; +}; + +&de { + status = "okay"; }; &mmc0 { @@ -86,6 +108,20 @@ status = "okay"; }; +&tcon0 { + pinctrl-names = "default"; + pinctrl-0 = <&lcd_rgb666_pins>; + status = "okay"; + +}; + +&tcon0_out { + tcon0_out_lcd: endpoint@0 { + reg = <0>; + remote-endpoint = <&panel_input>; + }; +}; + &uart0 { pinctrl-0 = <&uart0_pins_a>; pinctrl-names = "default"; -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 08/13] drm/sun4i: add support for Allwinner DE2 mixers
Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes with mixers to do graphic processing and feed data to TCON, like the old backends and frontends. Add support for the mixer on Allwinner V3s SoC; it's the simplest one. Currently a lot of functions are still missing -- more investigations are needed to gain enough information for them. Signed-off-by: Icenowy Zheng --- Changes in v7: - Small fixed advised by Maxime Ripard. - Added fixup on CRTC destination coordinate. Changes in v6: - Rebased on wens's multi-pipeline patchset. Changes in v5: - Changed some code alignment. - Request real 32-bit DMA (prepare for 64-bit SoCs). Changes in v4: - Killed some dead code according to Jernej. drivers/gpu/drm/sun4i/Kconfig | 10 + drivers/gpu/drm/sun4i/Makefile | 3 + drivers/gpu/drm/sun4i/sun8i_layer.c | 134 drivers/gpu/drm/sun4i/sun8i_layer.h | 36 drivers/gpu/drm/sun4i/sun8i_mixer.c | 412 drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 6 files changed, 732 insertions(+) create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index 5a8227f37cc4..15557484520d 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND original Allwinner Display Engine, which has a backend to do some alpha blending and feed graphics to TCON. If M is selected the module will be called sun4i-backend. + +config DRM_SUN8I_MIXER + tristate "Support for Allwinner Display Engine 2.0 Mixer" + depends on DRM_SUN4I + default MACH_SUN8I + help + Choose this option if you have an Allwinner SoC with the + Allwinner Display Engine 2.0, which has a mixer to do some + graphics mixture and feed graphics to TCON, If M is + selected the module will be called sun8i-mixer. diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile index da561d064ab8..d81c9319dadf 100644 --- a/drivers/gpu/drm/sun4i/Makefile +++ b/drivers/gpu/drm/sun4i/Makefile @@ -8,8 +8,11 @@ sun4i-tcon-y += sun4i_crtc.o sun4i-backend-y += sun4i_backend.o sun4i_layer.o +sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o + obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o +obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c b/drivers/gpu/drm/sun4i/sun8i_layer.c new file mode 100644 index ..e627eeece658 --- /dev/null +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c @@ -0,0 +1,134 @@ +/* + * Copyright (C) Icenowy Zheng + * + * Based on sun4i_layer.h, which is: + * Copyright (C) 2015 Free Electrons + * Copyright (C) 2015 NextThing Co + * + * Maxime Ripard + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + */ + +#include +#include +#include + +#include "sun8i_layer.h" +#include "sun8i_mixer.h" + +struct sun8i_plane_desc { + enum drm_plane_type type; + const uint32_t *formats; + uint32_tnformats; +}; + +static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + struct sun8i_layer *layer = plane_to_sun8i_layer(plane); + struct sun8i_mixer *mixer = layer->mixer; + + sun8i_mixer_layer_enable(mixer, layer->id, false); +} + +static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + struct sun8i_layer *layer = plane_to_sun8i_layer(plane); + struct sun8i_mixer *mixer = layer->mixer; + + sun8i_mixer_update_layer_coord(mixer, layer->id, plane); + sun8i_mixer_update_layer_formats(mixer, layer->id, plane); + sun8i_mixer_update_layer_buffer(mixer, layer->id, plane); + sun8i_mixer_layer_enable(mixer, layer->id, true); +} + +static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = { + .atomic_disable = sun8i_mixer_layer_atomic_disable, + .atomic_update = sun8i_mixer_layer_atomic_update, +}; + +static const struct drm_plane_funcs sun8i_mixer_layer_funcs = { + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_s
Re: [PATCH 00/13] Get rid of DocBook
On Sun, May 14, 2017 at 8:38 AM, Mauro Carvalho Chehab wrote: > As just one book (lsm) was missing conversion, let's convert it > and store as if it were a plain text file under Documentation/lsm.txt, > adding a notice that it requires update. I could probably fold this change into my rst-ification of Documentation/security/ https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/rst Specifically, the new Documentation/security/LSM.rst was rather short. I think your lsm.txt and this one could be likely merged. -Kees -- Kees Cook Pixel Security ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 06/13] drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer
Currently the direct call from CRTC code to layer code has disappeared, instead the layer's init function is called via the backend's ops. Add a dedicated module for sun4i-backend and sun4i-layer, and drop the EXPORT_SYMBOL from backend code to layer code. Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai --- Changes in v7: - Added Chen-Yu's Reviewed-by. drivers/gpu/drm/sun4i/Makefile| 5 +++-- drivers/gpu/drm/sun4i/sun4i_backend.c | 4 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile index 59b757350a1f..a251fb36c951 100644 --- a/drivers/gpu/drm/sun4i/Makefile +++ b/drivers/gpu/drm/sun4i/Makefile @@ -5,9 +5,10 @@ sun4i-tcon-y += sun4i_tcon.o sun4i-tcon-y += sun4i_rgb.o sun4i-tcon-y += sun4i_dotclock.o sun4i-tcon-y += sun4i_crtc.o -sun4i-tcon-y += sun4i_layer.o + +sun4i-backend-y += sun4i_backend.o sun4i_layer.o obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o -obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o +obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c index 611cdcb9c182..fac1a414ba49 100644 --- a/drivers/gpu/drm/sun4i/sun4i_backend.c +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c @@ -83,7 +83,6 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend, regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG, SUN4I_BACKEND_MODCTL_LAY_EN(layer), val); } -EXPORT_SYMBOL(sun4i_backend_layer_enable); static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane, u32 format, u32 *mode) @@ -170,7 +169,6 @@ int sun4i_backend_update_layer_coord(struct sun4i_backend *backend, return 0; } -EXPORT_SYMBOL(sun4i_backend_update_layer_coord); int sun4i_backend_update_layer_formats(struct sun4i_backend *backend, int layer, struct drm_plane *plane) @@ -205,7 +203,6 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend, return 0; } -EXPORT_SYMBOL(sun4i_backend_update_layer_formats); int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend, int layer, struct drm_plane *plane) @@ -246,7 +243,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend, return 0; } -EXPORT_SYMBOL(sun4i_backend_update_layer_buffer); static int sun4i_backend_init_sat(struct device *dev) { struct sun4i_backend *backend = dev_get_drvdata(dev); -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 07/13] drm/sun4i: add a Kconfig option for sun4i-backend
As sun4i-backend is now a dedicated module, add an Kconfig option for it to make it optional, since some build may only use other engines. Signed-off-by: Icenowy Zheng --- Changes in v7: - Adjusted the position of BACKEND makefile item. (It's now after common codes shared between sun4i-backend and sun8i-mixer.) drivers/gpu/drm/sun4i/Kconfig | 10 ++ drivers/gpu/drm/sun4i/Makefile | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index a4b357db8856..5a8227f37cc4 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -12,3 +12,13 @@ config DRM_SUN4I Choose this option if you have an Allwinner SoC with a Display Engine. If M is selected the module will be called sun4i-drm. + +config DRM_SUN4I_BACKEND + tristate "Support for Allwinner A10 Display Engine Backend" + depends on DRM_SUN4I + default DRM_SUN4I + help + Choose this option if you have an Allwinner SoC with the + original Allwinner Display Engine, which has a backend to + do some alpha blending and feed graphics to TCON. If M is + selected the module will be called sun4i-backend. diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile index a251fb36c951..da561d064ab8 100644 --- a/drivers/gpu/drm/sun4i/Makefile +++ b/drivers/gpu/drm/sun4i/Makefile @@ -9,6 +9,7 @@ sun4i-tcon-y += sun4i_crtc.o sun4i-backend-y += sun4i_backend.o sun4i_layer.o obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o -obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o + +obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id
On 05/12/2017 10:00 PM, Dmitry Osipenko wrote: The start = 0 is invalid and causes weird CDMA channel timeouts, presumably some memory misuse/corruption is going on. What makes you think start = 0 is invalid? I can't see anything pointing to that in the idr code and there are many users in the kernel passing 0 as start. Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace") Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 768750226452..732c8d98044f 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -518,7 +518,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv, if (err < 0) return err; - err = idr_alloc(&fpriv->contexts, context, 0, 0, GFP_KERNEL); + err = idr_alloc(&fpriv->contexts, context, 1, 0, GFP_KERNEL); if (err < 0) { client->ops->close_channel(context); return err; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: host1x: Do not leak BO's phys address to userspace
Do gathers coping before patching them, so the original gathers are left untouched. That's not as bad as leaking a kernel addresses, but still doesn't feel right. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 46 ++ 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index d9933828fe87..8f0d43b8f9a6 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct host1x_syncpt *sp, * avoid a wrap condition in the HW). */ static int do_waitchks(struct host1x_job *job, struct host1x *host, - struct host1x_bo *patch) + struct host1x_job_gather *g) { + struct host1x_bo *patch = g->bo; int i; /* compare syncpt vs wait threshold */ @@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct host1x *host, wait->syncpt_id, sp->name, wait->thresh, host1x_syncpt_read_min(sp)); - host1x_syncpt_patch_offset(sp, patch, wait->offset); + host1x_syncpt_patch_offset(sp, patch, + g->offset + wait->offset); } wait->bo = NULL; @@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job) return err; } -static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf) +static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g) { int i = 0; u32 last_page = ~0; void *cmdbuf_page_addr = NULL; + struct host1x_bo *cmdbuf = g->bo; /* pin & patch the relocs for one gather */ for (i = 0; i < job->num_relocs; i++) { @@ -286,7 +289,8 @@ static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf) if (cmdbuf != reloc->cmdbuf.bo) continue; - if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) { + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && + last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) { if (cmdbuf_page_addr) host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr); @@ -301,11 +305,20 @@ static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf) } } + if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) { + cmdbuf_page_addr = job->gather_copy_mapped; + cmdbuf_page_addr += g->offset; + } + target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK); + + if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) + target += (reloc->cmdbuf.offset & PAGE_MASK) >> 2; + *target = reloc_addr; } - if (cmdbuf_page_addr) + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && cmdbuf_page_addr) host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr); return 0; @@ -573,6 +586,14 @@ int host1x_job_pin(struct host1x_job *job, struct device *dev) if (err) goto out; + if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && !err) { + err = copy_gathers(job, dev); + if (err) { + host1x_job_unpin(job); + return err; + } + } + /* patch gathers */ for (i = 0; i < job->num_gathers; i++) { struct host1x_job_gather *g = &job->gathers[i]; @@ -581,7 +602,8 @@ int host1x_job_pin(struct host1x_job *job, struct device *dev) if (g->handled) continue; - g->base = job->gather_addr_phys[i]; + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) + g->base = job->gather_addr_phys[i]; for (j = i + 1; j < job->num_gathers; j++) { if (job->gathers[j].bo == g->bo) { @@ -590,23 +612,15 @@ int host1x_job_pin(struct host1x_job *job, struct device *dev) } } - err = do_relocs(job, g->bo); + err = do_relocs(job, g); if (err) break; - err = do_waitchks(job, host, g->bo); + err = do_waitchks(job, host, g); if (err) break; } - if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && !err) { - err = copy_gathers(job, dev); - if (err) { - host1x_job_unpin(job); - return err; - } - } - out: wmb(); -- 2.13.0 __
[PATCH v7 02/13] clk: sunxi-ng: add support for DE2 CCU
The "Display Engine 2.0" in Allwinner newer SoCs contains a clock management unit for its subunits, like the DE CCU in A80. Add a sunxi-ng style driver for it. Signed-off-by: Icenowy Zheng --- Changes in v7: - Fixed some parent clocks that are left open if the probe failed. - Added V3s compatible (only one mixer). Changes in v5: - Removed dt-bindings headers (they're now in patch 1). Changes in v4: - Fixed the inconsistence between mixer_div clocks' number and real clock. Changes in v2: - Rename sunxi-de2-ccu to sun8i-de2-ccu. drivers/clk/sunxi-ng/Kconfig | 5 + drivers/clk/sunxi-ng/Makefile| 1 + drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 260 +++ drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 4 files changed, 294 insertions(+) create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig index b0d551a8efe4..747662565545 100644 --- a/drivers/clk/sunxi-ng/Kconfig +++ b/drivers/clk/sunxi-ng/Kconfig @@ -140,6 +140,11 @@ config SUN8I_V3S_CCU default MACH_SUN8I depends on MACH_SUN8I || COMPILE_TEST +config SUN8I_DE2_CCU + bool "Support for the Allwinner SoCs DE2 CCU" + select SUNXI_CCU_DIV + select SUNXI_CCU_GATE + config SUN9I_A80_CCU bool "Support for the Allwinner A80 CCU" select SUNXI_CCU_DIV diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile index 0ec02fe14c50..be616279450e 100644 --- a/drivers/clk/sunxi-ng/Makefile +++ b/drivers/clk/sunxi-ng/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o +obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c new file mode 100644 index ..15aaa9c4a3af --- /dev/null +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c @@ -0,0 +1,260 @@ +/* + * Copyright (c) 2017 Icenowy Zheng + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include + +#include "ccu_common.h" +#include "ccu_div.h" +#include "ccu_gate.h" +#include "ccu_reset.h" + +#include "ccu-sun8i-de2.h" + +static SUNXI_CCU_GATE(bus_mixer0_clk, "bus-mixer0", "bus-de", + 0x04, BIT(0), 0); +static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1", "bus-de", + 0x04, BIT(1), 0); +static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de", + 0x04, BIT(2), 0); + +static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div", + 0x00, BIT(0), CLK_SET_RATE_PARENT); +static SUNXI_CCU_GATE(mixer1_clk, "mixer1", "mixer1-div", + 0x00, BIT(1), CLK_SET_RATE_PARENT); +static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div", + 0x00, BIT(2), CLK_SET_RATE_PARENT); + +static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4, + CLK_SET_RATE_PARENT); +static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4, + CLK_SET_RATE_PARENT); +static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4, + CLK_SET_RATE_PARENT); + +static struct ccu_common *sun8i_a83t_de2_clks[] = { + &mixer0_clk.common, + &mixer1_clk.common, + &wb_clk.common, + + &bus_mixer0_clk.common, + &bus_mixer1_clk.common, + &bus_wb_clk.common, + + &mixer0_div_clk.common, + &mixer1_div_clk.common, + &wb_div_clk.common, +}; + +static struct ccu_common *sun8i_v3s_de2_clks[] = { + &mixer0_clk.common, + &wb_clk.common, + + &bus_mixer0_clk.common, + &bus_wb_clk.common, + + &mixer0_div_clk.common, + &wb_div_clk.common, +}; + +static struct clk_hw_onecell_data sun8i_a83t_de2_hw_clks = { + .hws= { + [CLK_MIXER0]= &mixer0_clk.common.hw, + [CLK_MIXER1]= &mixer1_clk.common.hw, + [CLK_WB]= &wb_clk.common.hw, + + [CLK_BUS_MIXER0]= &bus_mixer0_clk.common.hw, + [CLK_BUS_MIXER1]= &bus_mixer1_clk.common.hw, +
[PATCH v7 05/13] drm/sun4i: abstract a engine type
As we are going to add support for the Allwinner DE2 engine in sun4i-drm driver, we will finally have two types of display engines -- the DE1 backend and the DE2 mixer. They both do some display blending and feed graphics data to TCON, and is part of the "Display Engine" called by Allwinner, so I choose to call them both "engine" here. Abstract the engine type to a new struct with an ops struct, which contains functions that should be called outside the engine-specified code (in TCON, CRTC or TV Encoder code). Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai --- Changes in v7: - Mention "Display Engine" for the name "engine". - Fixed some small issues found by Chen-Yu and added his ACK. Changes in v6: - Rebased on wens's multi-pipeline patchset. - Split out Makefile changes. Changes in v5: - Really made a sunxi_engine struct type, and moved ops pointer into it. - Added checked ops wrappers. - Changed the second parameter of layers_init from crtc to engine. Changes in v4: - Comments to tag the color correction functions as optional. - Check before calling the optional functions. - Change layers_init to satisfy new PATCH v4 04/11. drivers/gpu/drm/sun4i/sun4i_backend.c | 68 - drivers/gpu/drm/sun4i/sun4i_backend.h | 17 +++--- drivers/gpu/drm/sun4i/sun4i_crtc.c| 11 ++-- drivers/gpu/drm/sun4i/sun4i_crtc.h| 4 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- drivers/gpu/drm/sun4i/sun4i_drv.h | 2 +- drivers/gpu/drm/sun4i/sun4i_layer.c | 9 ++- drivers/gpu/drm/sun4i/sun4i_layer.h | 4 +- drivers/gpu/drm/sun4i/sun4i_tcon.c| 38 ++-- drivers/gpu/drm/sun4i/sun4i_tv.c | 9 ++- drivers/gpu/drm/sun4i/sunxi_engine.h | 111 ++ 11 files changed, 199 insertions(+), 76 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c index e53107418add..611cdcb9c182 100644 --- a/drivers/gpu/drm/sun4i/sun4i_backend.c +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c @@ -25,6 +25,8 @@ #include "sun4i_backend.h" #include "sun4i_drv.h" +#include "sun4i_layer.h" +#include "sunxi_engine.h" static const u32 sunxi_rgb2yuv_coef[12] = { 0x0107, 0x0204, 0x0064, 0x0108, @@ -32,41 +34,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = { 0x01c1, 0x3e88, 0x3fb8, 0x0808 }; -void sun4i_backend_apply_color_correction(struct sun4i_backend *backend) +static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine) { int i; DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n"); /* Set color correction */ - regmap_write(backend->regs, SUN4I_BACKEND_OCCTL_REG, + regmap_write(engine->regs, SUN4I_BACKEND_OCCTL_REG, SUN4I_BACKEND_OCCTL_ENABLE); for (i = 0; i < 12; i++) - regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i), + regmap_write(engine->regs, SUN4I_BACKEND_OCRCOEF_REG(i), sunxi_rgb2yuv_coef[i]); } -EXPORT_SYMBOL(sun4i_backend_apply_color_correction); -void sun4i_backend_disable_color_correction(struct sun4i_backend *backend) +static void sun4i_backend_disable_color_correction(struct sunxi_engine *engine) { DRM_DEBUG_DRIVER("Disabling color correction\n"); /* Disable color correction */ - regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG, + regmap_update_bits(engine->regs, SUN4I_BACKEND_OCCTL_REG, SUN4I_BACKEND_OCCTL_ENABLE, 0); } -EXPORT_SYMBOL(sun4i_backend_disable_color_correction); -void sun4i_backend_commit(struct sun4i_backend *backend) +static void sun4i_backend_commit(struct sunxi_engine *engine) { DRM_DEBUG_DRIVER("Committing changes\n"); - regmap_write(backend->regs, SUN4I_BACKEND_REGBUFFCTL_REG, + regmap_write(engine->regs, SUN4I_BACKEND_REGBUFFCTL_REG, SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS | SUN4I_BACKEND_REGBUFFCTL_LOADCTL); } -EXPORT_SYMBOL(sun4i_backend_commit); void sun4i_backend_layer_enable(struct sun4i_backend *backend, int layer, bool enable) @@ -81,7 +80,7 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend, else val = 0; - regmap_update_bits(backend->regs, SUN4I_BACKEND_MODCTL_REG, + regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG, SUN4I_BACKEND_MODCTL_LAY_EN(layer), val); } EXPORT_SYMBOL(sun4i_backend_layer_enable); @@ -144,27 +143,28 @@ int sun4i_backend_update_layer_coord(struct sun4i_backend *backend, if (plane->type == DRM_PLANE_TYPE_PRIMARY) { DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H: %u\n", state->crtc_w, state->crtc_h); - regmap_write(backend->re
[PATCH v7 00/13] Initial Allwinner Display Engine 2.0 Support
This patchset is the initial patchset for Allwinner DE2 support. It contains the support of clocks in DE2 and the mixers in DE2. The SoC used to develop this patchset is V3s, as V3s is the simplest one of the SoCs that have DE2. (Allwinner V3s features only one mixer, and its only video output is RGB LCD, which is already supported in our TCON driver) The last patch is only a testing patch, it shouldn't be merged; and for the patch to be really usable, the RFC fix of the TCON driver [1] is needed. No HDMI, TV encoder or other internal bridges' support is included in this patchset, which makes it currently not usable on H3. (For TVE I have some code that made it working; for HDMI there is a driver by Jernej Skrabec which is based on the dw-hdmi common code.) Thanks to Jean-Francois Moine and Jernej Skrabec for their efforts to discover the internal of DE2! [1] https://lists.freedesktop.org/archives/dri-devel/2016-December/126264.html Icenowy Zheng (13): dt-bindings: add binding for the Allwinner DE2 CCU clk: sunxi-ng: add support for DE2 CCU dt-bindings: add bindings for DE2 on V3s SoC drm/sun4i: return only planes for layers created drm/sun4i: abstract a engine type drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer drm/sun4i: add a Kconfig option for sun4i-backend drm/sun4i: add support for Allwinner DE2 mixers drm/sun4i: Add compatible string for V3s display engine drm/sun4i: tcon: add support for V3s TCON ARM: sun8i: v3s: add device nodes for DE2 display pipeline ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC [DO NOT MERGE] ARM: sun8i: v3s: enable LCD panel of Lichee Pi Zero .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++ .../bindings/display/sunxi/sun4i-drm.txt | 26 +- arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 ++ arch/arm/boot/dts/sun8i-v3s.dtsi | 96 + drivers/clk/sunxi-ng/Kconfig | 5 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 260 + drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 ++ drivers/gpu/drm/sun4i/Kconfig | 20 + drivers/gpu/drm/sun4i/Makefile | 9 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 72 ++-- drivers/gpu/drm/sun4i/sun4i_backend.h | 17 +- drivers/gpu/drm/sun4i/sun4i_crtc.c | 32 +- drivers/gpu/drm/sun4i/sun4i_crtc.h | 5 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 6 +- drivers/gpu/drm/sun4i/sun4i_drv.h | 2 +- drivers/gpu/drm/sun4i/sun4i_layer.c| 21 +- drivers/gpu/drm/sun4i/sun4i_layer.h| 6 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 43 ++- drivers/gpu/drm/sun4i/sun4i_tv.c | 9 +- drivers/gpu/drm/sun4i/sun8i_layer.c| 134 +++ drivers/gpu/drm/sun4i/sun8i_layer.h| 36 ++ drivers/gpu/drm/sun4i/sun8i_mixer.c| 412 + drivers/gpu/drm/sun4i/sun8i_mixer.h| 137 +++ drivers/gpu/drm/sun4i/sunxi_engine.h | 111 ++ include/dt-bindings/clock/sun8i-de2.h | 18 + include/dt-bindings/reset/sun8i-de2.h | 14 + 27 files changed, 1485 insertions(+), 102 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h create mode 100644 include/dt-bindings/clock/sun8i-de2.h create mode 100644 include/dt-bindings/reset/sun8i-de2.h -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/13] docs: update old references for DocBook from the documentation
DocBook is mentioned several times at the documentation. Update the obsolete references from it at the DocBook. Signed-off-by: Mauro Carvalho Chehab --- Documentation/PCI/MSI-HOWTO.txt| 2 +- Documentation/admin-guide/README.rst | 6 --- Documentation/doc-guide/index.rst | 1 - Documentation/doc-guide/sphinx.rst | 5 --- Documentation/fb/api.txt | 4 +- Documentation/gpu/todo.rst | 2 +- Documentation/kernel-doc-nano-HOWTO.txt| 65 +- Documentation/process/changes.rst | 26 +++- Documentation/process/howto.rst| 8 Documentation/process/kernel-docs.rst | 34 +--- Documentation/translations/ja_JP/howto.rst | 7 Documentation/translations/ko_KR/howto.rst | 7 12 files changed, 21 insertions(+), 146 deletions(-) diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 1e37138027a3..618e13d5e276 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -186,7 +186,7 @@ must disable interrupts while the lock is held. If the device sends a different interrupt, the driver will deadlock trying to recursively acquire the spinlock. Such deadlocks can be avoided by using spin_lock_irqsave() or spin_lock_irq() which disable local interrupts -and acquire the lock (see Documentation/DocBook/kernel-locking). +and acquire the lock (see Documentation/kernel-hacking/locking.rst). 4.5 How to tell whether MSI/MSI-X is enabled on a device diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index b96e80f79e85..b5343c5aa224 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -55,12 +55,6 @@ Documentation contains information about the problems, which may result by upgrading your kernel. - - The Documentation/DocBook/ subdirectory contains several guides for - kernel developers and users. These guides can be rendered in a - number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others. - After installation, ``make psdocs``, ``make pdfdocs``, ``make htmldocs``, - or ``make mandocs`` will render the documentation in the requested format. - Installing the kernel source diff --git a/Documentation/doc-guide/index.rst b/Documentation/doc-guide/index.rst index 6fff4024606e..a7f95d7d3a63 100644 --- a/Documentation/doc-guide/index.rst +++ b/Documentation/doc-guide/index.rst @@ -10,7 +10,6 @@ How to write kernel documentation sphinx.rst kernel-doc.rst parse-headers.rst - docbook.rst .. only:: subproject and html diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 731334de3efd..84e8e8a9cbdb 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -15,11 +15,6 @@ are used to describe the functions and types and design of the code. The kernel-doc comments have some special structure and formatting, but beyond that they are also treated as reStructuredText. -There is also the deprecated DocBook toolchain to generate documentation from -DocBook XML template files under ``Documentation/DocBook``. The DocBook files -are to be converted to reStructuredText, and the toolchain is slated to be -removed. - Finally, there are thousands of plain text documentation files scattered around ``Documentation``. Some of these will likely be converted to reStructuredText over time, but the bulk of them will remain in plain text. diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt index d4ff7de85700..d52cf1e3b975 100644 --- a/Documentation/fb/api.txt +++ b/Documentation/fb/api.txt @@ -289,12 +289,12 @@ the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. FOURCC definitions are located in the linux/videodev2.h header. However, and despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 and don't require usage of the V4L2 subsystem. FOURCC documentation is -available in Documentation/DocBook/v4l/pixfmt.xml. +available in Documentation/media/uapi/v4l/pixfmt.rst. To select a format, applications set the grayscale field to the desired FOURCC. For YUV formats, they should also select the appropriate colorspace by setting the colorspace field to one of the colorspaces listed in linux/videodev2.h and -documented in Documentation/DocBook/v4l/colorspaces.xml. +documented in Documentation/media/uapi/v4l/colorspaces.rst. The red, green, blue and transp fields are not used with the FOURCC-based API. For forward compatibility reasons applications must zero those fields, and diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1bdb7356a310..6162d0e9dc28 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -228,7 +228,7 @@ The DRM reference documentation is still lacking kerneldoc in a fe
Re: [PATCH] gpu: host1x: Initialize firewall class to the jobs one
Well spotted! Reviewed-by: Mikko Perttunen On 05/14/2017 12:01 AM, Dmitry Osipenko wrote: The commands stream is prepended by the jobs class on the CDMA submission, so that explicitly setting a module class in the commands stream isn't necessary. The firewall initializes its class to 0 and the command stream that doesn't explicitly specify the class effectively bypasses the firewall. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index 5f5f8ee6143d..d9933828fe87 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -504,7 +504,7 @@ static inline int copy_gathers(struct host1x_job *job, struct device *dev) fw.dev = dev; fw.reloc = job->relocarray; fw.num_relocs = job->num_relocs; - fw.class = 0; + fw.class = job->class; for (i = 0; i < job->num_gathers; i++) { struct host1x_job_gather *g = &job->gathers[i]; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer
On 05/12/2017 10:29 PM, Dmitry Osipenko wrote: If command buffer claims a number of words that is higher than its BO can fit and a relocation lays past the BO, a kernel OOPS will be fired on that relocation address patching. This was triggered by an opentegra Xorg driver that erroneously pushed too many commands to the pushbuf. [ 46.829393] Unable to handle kernel paging request at virtual address f09b2000 ... [] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510) [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c) [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec) [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Dmitry Osipenko --- v2: Take into account the cmdbuf.offset drivers/gpu/drm/tegra/drm.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 732c8d98044f..9ad4ac7c08d1 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context, while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; - struct host1x_bo *bo; + struct drm_gem_object *gem; + struct tegra_bo *bo; if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) { err = -EFAULT; goto fail; } - bo = host1x_bo_lookup(file, cmdbuf.handle); - if (!bo) { + gem = drm_gem_object_lookup(file, cmdbuf.handle); + if (!gem) { err = -ENOENT; goto fail; } - host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset); + drm_gem_object_unreference_unlocked(gem); + + if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) { + err = -EINVAL; + goto fail; + } Nasty bug! Well found. Two points: the arithmetic here could overflow, so userspace could supply some large values for offset/words and this check would not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking at the code closer, I can't see any bounds checking for relocs either.. That code (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so we could e.g. change host1x_bo_lookup to take offset and words parameters and verify those at the same time. Cheers, Mikko + + bo = to_tegra_bo(gem); + host1x_job_add_gather(job, &bo->base, + cmdbuf.words, cmdbuf.offset); num_cmdbufs--; cmdbufs++; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 12/13] ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC
Allwinner V3s SoC features a set of pins that have functionality of RGB LCD, the pins are at different pin ban than other SoCs. Add pinctrl node for them. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v7: - Dropped the trailing "@0" in rgb666 pinmux node name. - Added Chen-Yu's ACK. arch/arm/boot/dts/sun8i-v3s.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi index b71b35734515..a7026517ed99 100644 --- a/arch/arm/boot/dts/sun8i-v3s.dtsi +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi @@ -297,6 +297,15 @@ function = "i2c0"; }; + lcd_rgb666_pins: lcd_rgb666 { + pins = "PE0", "PE1", "PE2", "PE3", "PE4", + "PE5", "PE6", "PE7", "PE8", "PE9", + "PE10", "PE11", "PE12", "PE13", "PE14", + "PE15", "PE16", "PE17", "PE18", "PE19", + "PE23", "PE24"; + function = "lcd"; + }; + uart0_pins_a: uart0@0 { pins = "PB8", "PB9"; function = "uart0"; -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 10/13] drm/sun4i: tcon: add support for V3s TCON
Allwinner V3s SoC features a TCON without channel 1. Add support for it. Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai --- Changes in v7: - Added Chen-Yu's Reviewed-by. drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++- drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index 4a979d17ddaa..1dd1948025d2 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -178,7 +178,8 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node) return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") || of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") || of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") || - of_device_is_compatible(node, "allwinner,sun8i-a33-tcon"); + of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") || + of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon"); } static int compare_of(struct device *dev, void *data) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 288275802f92..add349f5e012 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -601,11 +601,16 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = { /* nothing is supported */ }; +static const struct sun4i_tcon_quirks sun8i_v3s_quirks = { + /* nothing is supported */ +}; + static const struct of_device_id sun4i_tcon_of_table[] = { { .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks }, { .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks }, { .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks }, { .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks }, + { .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks }, { } }; MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table); -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 09/13] drm/sun4i: Add compatible string for V3s display engine
Allwinner V3s features the new "Display Engine 2.0", which can now also be driven with our subdrivers in sun4i-drm. Add the compatible string for in sun4i_drv.c, in order to make the display engine and its components probed. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index 35cad9cb44c5..4a979d17ddaa 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -296,6 +296,7 @@ static const struct of_device_id sun4i_drv_of_table[] = { { .compatible = "allwinner,sun6i-a31-display-engine" }, { .compatible = "allwinner,sun6i-a31s-display-engine" }, { .compatible = "allwinner,sun8i-a33-display-engine" }, + { .compatible = "allwinner,sun8i-v3s-display-engine" }, { } }; MODULE_DEVICE_TABLE(of, sun4i_drv_of_table); -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer
On 14.05.2017 15:27, Mikko Perttunen wrote: > On 05/12/2017 10:29 PM, Dmitry Osipenko wrote: >> If command buffer claims a number of words that is higher than its BO can >> fit and a relocation lays past the BO, a kernel OOPS will be fired on that >> relocation address patching. This was triggered by an opentegra Xorg driver >> that erroneously pushed too many commands to the pushbuf. >> >> [ 46.829393] Unable to handle kernel paging request at virtual address >> f09b2000 >> ... >> [] (host1x_job_pin) from [] >> (tegra_drm_submit+0x474/0x510) >> [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c) >> [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec) >> [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4) >> [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) >> [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) >> >> Signed-off-by: Dmitry Osipenko >> --- >> >> v2: Take into account the cmdbuf.offset >> >> drivers/gpu/drm/tegra/drm.c | 18 ++ >> 1 file changed, 14 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c >> index 732c8d98044f..9ad4ac7c08d1 100644 >> --- a/drivers/gpu/drm/tegra/drm.c >> +++ b/drivers/gpu/drm/tegra/drm.c >> @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context, >> >> while (num_cmdbufs) { >> struct drm_tegra_cmdbuf cmdbuf; >> -struct host1x_bo *bo; >> +struct drm_gem_object *gem; >> +struct tegra_bo *bo; >> >> if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) { >> err = -EFAULT; >> goto fail; >> } >> >> -bo = host1x_bo_lookup(file, cmdbuf.handle); >> -if (!bo) { >> +gem = drm_gem_object_lookup(file, cmdbuf.handle); >> +if (!gem) { >> err = -ENOENT; >> goto fail; >> } >> >> -host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset); >> +drm_gem_object_unreference_unlocked(gem); >> + >> +if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) { >> +err = -EINVAL; >> +goto fail; >> +} > > Nasty bug! Well found. Two points: the arithmetic here could overflow, so > userspace could supply some large values for offset/words and this check would > not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking at > the code closer, I can't see any bounds checking for relocs either.. That code > (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so we > could e.g. change host1x_bo_lookup to take offset and words parameters and > verify those at the same time. > Good point, unfortunately there are a lot of ways to abuse the staging API on the IOMMU-less Tegra20 right now. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/tegra: Correct idr_alloc() minimum id
The client ID 0 is reserved by the host1x/cdma to mark the timeout timer work as already been scheduled and context ID is used as the clients one. This fixes spurious CDMA timeouts. Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace") Signed-off-by: Dmitry Osipenko --- v2: Changed the commit description, now explains the cause of CDMA timeouts. drivers/gpu/drm/tegra/drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index c5844a065681..489cb32453f7 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -548,7 +548,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv, if (err < 0) return err; - err = idr_alloc(&fpriv->contexts, context, 0, 0, GFP_KERNEL); + err = idr_alloc(&fpriv->contexts, context, 1, 0, GFP_KERNEL); if (err < 0) { client->ops->close_channel(context); return err; -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for v4.12-rc1
On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull requests after rc1. If Vega10 is in such bad shape that it will need this kind of stuff and isn't worth shipping without them in 4.12, I will take a *oneline* that just disables it. So no "thousands of lines of fixes for a new driver". Being new to 4.12 isn't an excuse for crazy stuff after the merge window. If it will need more of this kind of attention, all it means is that it shouldn't have been sent to me at all in the first place. The drm subsystem is still on my "no more of this shit" list, so I'm going to be very unforgiving of big pull requests when they aren't appropriate. Linus -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for v4.12-rc1
Hi Linus, Some fixes that it would be good to have in rc1. It contains the i915 quiet fix that you reported. It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 which is new in this kernel and is preliminary support so may have a fair bit of movement. Otherwise a few non-Vega10 AMD fixes, one EDID fix and some nouveau regression fixers. Dave. The following changes since commit 09d79d103371b1b7ea70ea7f9c05ac207ef22f5d: Merge tag 'docs-4.12-2' of git://git.lwn.net/linux (2017-05-11 11:29:52 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc1 for you to fetch changes up to 7b8cd3363e8a0e6b90a7067f75aaeaae61a7d612: drm/i915: Make vblank evade warnings optional (2017-05-12 14:28:02 +1000) amd, nouveau, one i915 and one EDID fix for v4.12-rc1 Alex Deucher (12): drm/amdgpu: fix spelling in header comment drm/amdgpu: bump version number to note race fix and new fence functionality Revert "drm/amd/amdgpu: Set VCE/UVD off during late init" drm/amdgpu: update revision id settings for BR/ST drm/amdgpu/gfx9: use actual gpu num se setting for ngg allocation drm/amdgpu/gfx9: fix typo in mpd init drm/amdgpu/gfx9: add additional MQD initialization drm/amdgpu/gfx: drop max_gs_waves_per_vgt drm/amdgpu/gfx9: derive tile pipes from golden settings drm/amdgpu/atomfirmware: add function to update engine hang status drm/amdgpu/soc15: use atomfirmware for setting bios scratch for reset drm/amdgpu: add some additional vega10 pci ids Alex Xie (8): drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Real return value can be over-written when clean up drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting Ben Skeggs (10): drm/nouveau/kms/nv50: remove pointless argument to window atomic_check_acquire() drm/nouveau/kms/nv50: fix source-rect-only plane updates drm/nouveau/kms/nv50: skip core channel cursor update on position-only changes drm/nouveau/fb/ram/gf100-: remove 0x10f200 read drm/nouveau/core: fix static checker warning drm/nouveau/tmr: ack interrupt before processing alarms drm/nouveau/tmr: handle races with hw when updating the next alarm time drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm drm/nouveau/tmr: avoid processing completed alarms when adding a new one drm/nouveau/therm: remove ineffective workarounds for alarm bugs Christian König (14): drm/amdgpu: add VMHUB to ring association drm/amdgpu: drop VMID per ring tracking drm/amdgpu: split VMID management by VMHUB drm/amdgpu: invalidate only the currently needed VMHUB v2 drm/amdgpu: assign VM invalidation engine manually v2 drm/amdgpu: allow concurrent VM flushes drm/amdgpu: trace the vmhub in grab_id as well drm/amdgpu: trace vm hub during flush as well v2 drm/radeon: force the UVD DPB into VRAM as well drm/amdgpu: fix coding style and printing in amdgpu_doorbell_init drm/amdgpu: fix amdgpu_vm_clear_freed v2 drm/amdgpu: fix amdgpu_ttm_bo_eviction_valuable drm/amdgpu: fix VM clearing in amdgpu_gem_object_close drm/amdgpu: remove unused and mostly unimplemented CGS functions v2 Chunming Zhou (8): drm/amdgpu: add gtt print like vram when dump mm table V2 drm/amdgpu: increase gtt size to 3GB by default v2 drm/amdgpu: fix no-vmid job drm/amdgpu: fix gpu reset crash drm/amdgpu: fix NULL pointer error drm/amdgpu: fix deadlock of reservation between cs and gpu reset v2 drm/amd: fix init order of sched job drm/amdgpu: fix dependency issue Daniel Wang (2): drm/amdgpu/psp: skip loading SDMA/RLCG under SRIOV VF drm/amdgpu/vce4: fix a PSP loading VCE issue Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2017-05-05' of git://anongit.freedesktop.org/git/drm-misc into drm-next Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next Evan Quan (1): drm/amdgpu: update smu9 driver interface Frank Min (7): drm/amdgpu/vce4: update VCE initialization sequence for SRIOV drm/amdgpu/vce4: enable ring & ib test for sriov drm/amdgpu/vce4: move mm table constructions functions into mmsch header file drm/amdgpu/uvd7: add sriov uvd initialization sequences drm/amdgpu/uvd7: add uvd doorbell initialization for sriov drm/amdgpu/uvd7: add U
[radeon-alex:amd-staging-4.11 954/1085] sound/soc//amd/raven/acp3x-pcm-dma.c:246:3: error: implicit declaration of function 'page_to_phys'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11 head: c285c73f2213f503a93aa142fff186e160b4a371 commit: abb115931046498039111820de7b6b578c4cce8d [954/1085] ASoC: AMD: enable ACP3x drivers build config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout abb115931046498039111820de7b6b578c4cce8d # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): In file included from sound/soc//amd/raven/acp3x-pcm-dma.c:26:0: sound/soc//amd/raven/acp3x.h: In function 'rv_readl': sound/soc//amd/raven/acp3x.h:28:2: error: implicit declaration of function 'readl' sound/soc//amd/raven/acp3x.h: In function 'rv_writel': sound/soc//amd/raven/acp3x.h:33:2: error: implicit declaration of function 'writel' sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'config_acp3x_dma': >> sound/soc//amd/raven/acp3x-pcm-dma.c:246:3: error: implicit declaration of >> function 'page_to_phys' sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe': sound/soc//amd/raven/acp3x-pcm-dma.c:638:2: error: implicit declaration of function 'devm_ioremap' sound/soc//amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors vim +/page_to_phys +246 sound/soc//amd/raven/acp3x-pcm-dma.c 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 230 /* 8 scratch registers used to map one 64 bit address. 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 231* For 2 pages (4096 * 2 bytes), it will be 16 registers. 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 232*/ 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 233 if (direction == SNDRV_PCM_STREAM_PLAYBACK) 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 234 val = 0; 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 235 else 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 236 val = 16; 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 237 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 238 /* Group Enable */ 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 239 rv_writel(ACP_SRAM_PTE_OFFSET | BIT(31), rtd->acp3x_base + 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 240 mmACPAXI2AXI_ATU_BASE_ADDR_GRP_1); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 241 rv_writel(PAGE_SIZE_4K_ENABLE, rtd->acp3x_base + 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 242 mmACPAXI2AXI_ATU_PAGE_SIZE_GRP_1); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 243 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 244 for (page_idx = 0; page_idx < rtd->num_pages; page_idx++) { 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 245 /* Load the low address of page int ACP SRAM through SRBM */ 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 @246 addr = page_to_phys(pg); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 247 low = lower_32_bits(addr); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 248 high = upper_32_bits(addr); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 249 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 250 rv_writel(low, rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 251 high |= BIT(31); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 252 rv_writel(high, rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 253 + 4); 947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 254 /* Move to next physically contiguos page */ :: The code at line 246 was first introduced by commit :: 947d2f9fc0cb6379ede8593e3ca0107f87fc4ce9 ASoC: AMD: add ACP3x PCM driver DMA ops :: TO: Maruthi Srinivas Bayyavarapu :: CC: Alex Deucher --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101044] I915 driver caused VGA got no ignal after plug-out then plug-in the VGA cable
https://bugs.freedesktop.org/show_bug.cgi?id=101044 Bug ID: 101044 Summary: I915 driver caused VGA got no ignal after plug-out then plug-in the VGA cable Product: Mesa Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: highest Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: amy.s...@advantech.com.tw QA Contact: dri-devel@lists.freedesktop.org Group: Mesa Security Hi Sir, We have a product which uses Intel Xeon Processor E3 v5 CPU, we found an issue of I915 graphic driver. The testing OS is CentOS7 with kernel 3.10.0-514.10.2 & the OS only has the text mode, after boot up we plug-out the VGA cable and then plug-in the VGA cable again, then the VGA screen shows no signal. On the same OS we remove the I915 module from initramfs & do the same plug-out & plug-in test again, the VGA screen can still got the signal back. We also do the same test on WIN10 PRO X64, it doesn’t have the VGA no signal issue. It seems the root cause is the I915 driver, could you assist to check it or do you have newest I915 driver source code for us to do the test? Thank you! Amy Shih amy.s...@advantech.com.tw -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()
On 05/12/2017 04:31 PM, Laurent Pinchart wrote: Hi Archit, On Friday 12 May 2017 16:20:07 Archit Taneja wrote: On 05/12/2017 03:08 PM, Laurent Pinchart wrote: On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote: On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote: On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote: Introduce a new helper function which calls mode_valid() callback for all bridges in an encoder chain. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Dave Airlie Cc: Andrzej Hajda Cc: Archit Taneja --- drivers/gpu/drm/drm_bridge.c | 33 + include/drm/drm_bridge.h | 2 ++ 2 files changed, 35 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 86a7637..dc8cdfe 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge, EXPORT_SYMBOL(drm_bridge_mode_fixup); /** + * drm_bridge_mode_valid - validate the mode against all bridges in the + *encoder chain. + * @bridge: bridge control structure + * @mode: desired mode to be validated + * + * Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder + * chain, starting from the first bridge to the last. If at least one bridge + * does not accept the mode the function returns the error code. + * + * Note: the bridge passed should be the one closest to the encoder. + * + * RETURNS: + * MODE_OK on success, drm_mode_status Enum error code on failure + */ +enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge, + const struct drm_display_mode *mode) +{ + enum drm_mode_status ret = MODE_OK; + + if (!bridge) + return ret; + + if (bridge->funcs->mode_valid) + ret = bridge->funcs->mode_valid(bridge, mode); + + if (ret != MODE_OK) + return ret; + + return drm_bridge_mode_valid(bridge->next, mode); Looks like it should be pretty trivial to avoid the recursion. Am I correct in interpreting this that bridges have some kind of a hand rolled linked list implementation? Reusing the standard linked lists would allow you to use list_for_each() etc. Yeah it's a hand-rolled list, but current hw also has a bridge nesting depth of 2, so it really doesn't matter. I guess once we have real long chains of bridges we can fix this (and just using list_head sounds like a great idea). Even if not really needed right now, it's a pretty easy cleanup, if Jose has time to handle it in v3 of this series let's not postpone it ;-) jfyi, some of the bridge functions call the ops from the last bridge in the chain to first, so we'd need to use list_for_each_entry_prev() (or something like that) for them. And now that I think about it, for some of the operations (especially enable/disable) I believe that the bridge should be able to decide whether to call the next/previous bridge first or to configure its hardware first. I can image bridges that need the previous bridge in the chain to provide a valid clock before they get started, as well as bridges that need to be started with the incoming video signal stopped. I guess converting into list would be a good start to achieve this. We'd probably need to extend/redo the drm_bridge_attach() API to tweak the order in the which the ops are called. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat
Mike Galbraith writes: > On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote: >> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote: >> >> > Thanks for reporting this. Can you confirm the following patch prevents >> > the issue? >> >> Nope, it still gripes. > > The reason for this gripe is that we find that we don't have memory > reserved.. a tad too late. > Thanks for the info. Sorry I wasn't able to get back to this last week. I'll try to get another patch for -rc2. > Xorg-2252 [000] 135.409756: qxl_release_map > <-qxl_cursor_atomic_update > Xorg-2252 [000] 135.409756: qxl_bo_kmap_atomic_page > <-qxl_release_map > Xorg-2252 [000] 135.409757: qxl_bo_kmap_atomic_page: ENTER > Xorg-2252 [000] 135.409757: ttm_mem_io_lock > <-qxl_bo_kmap_atomic_page > Xorg-2252 [000] 135.409757: ttm_mem_io_reserve > <-qxl_bo_kmap_atomic_page > Xorg-2252 [000] 135.409757: qxl_ttm_io_mem_reserve > <-ttm_mem_io_reserve > Xorg-2252 [000] 135.409757: ttm_mem_io_unlock > <-qxl_bo_kmap_atomic_page > Xorg-2252 [000] 135.409757: qxl_bo_kmap_atomic_page: > PREEMPTION DISABLED > Xorg-2252 [000] ...1 135.409758: qxl_bo_kmap > <-qxl_cursor_atomic_update > Xorg-2252 [000] ...1 135.409758: ttm_bo_kmap <-qxl_bo_kmap > <== too late > Xorg-2252 [000] ...1 135.409758: ttm_mem_io_reserve > <-ttm_bo_kmap > Xorg-2252 [000] ...1 135.409758: qxl_ttm_io_mem_reserve > <-ttm_mem_io_reserve > Xorg-2252 [000] ...1 135.409759: ioremap_nocache <-ttm_bo_kmap > <== game over > Xorg-2252 [000] ...1 135.409759: __ioremap_caller > <-ioremap_nocache > Xorg-2252 [000] ...1 135.409759: walk_system_ram_range > <-__ioremap_caller > Xorg-2252 [000] ...1 135.409759: find_next_iomem_res > <-walk_system_ram_range > Xorg-2252 [000] ...1 135.409759: _raw_read_lock > <-find_next_iomem_res > Xorg-2252 [000] ...1 135.409760: reserve_memtype > <-__ioremap_caller > Xorg-2252 [000] ...1 135.409760: pat_pagerange_is_ram > <-reserve_memtype > Xorg-2252 [000] ...1 135.409761: walk_system_ram_range > <-pat_pagerange_is_ram > Xorg-2252 [000] ...1 135.409761: find_next_iomem_res > <-walk_system_ram_range > Xorg-2252 [000] ...1 135.409761: _raw_read_lock > <-find_next_iomem_res > Xorg-2252 [000] ...1 135.409761: kmem_cache_alloc_trace > <-reserve_memtype > Xorg-2252 [000] ...1 135.409761: __might_sleep > <-kmem_cache_alloc_trace > Xorg-2252 [000] ...1 135.409762: ___might_sleep <-__might_sleep -- Gabriel Krisman Bertazi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3
2017-05-15 3:03 GMT+03:00 Ben Skeggs : > On 05/15/2017 01:10 AM, Tommi Rantala wrote: >> >> Hi, > > Hey Tommi, > > Thanks for bisecting this. It's rather unexpected that you should be seeing > problems here, but, the commit makes sense for it at least. > > Are you able to get me new kernel logs of both before and after this patch > with "log_buf_len=8M drm.debug=0x14 > nouveau.debug=disp=trace,i2c=trace,bios=trace" please? Hi Ben, Before: https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1 After: https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1 -Tommi > Thanks, > Ben. > > >> >> Bisected this to: >> >> commit df8dc97cd17269474344d73cc02739532c468d04 >> Author: Ben Skeggs >> Date: Wed Mar 1 09:42:04 2017 +1000 >> >> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm >> >> I'm not entirely sure NVKM needs to support this now, but I haven't >> removed it as of yet just in case it's needed from DEVINIT scripts >> where DRM isn't available. >> >> Signed-off-by: Ben Skeggs >> >> >> dmesg after boot with drm.debug enabled: >> >> v4.10-10409-g5c68d91 (still works): >> http://termbin.com/b0is >> >> v4.10-10410-gdf8dc97 (failure): >> http://termbin.com/j6lq >> >> >> Tommi >> >> >> 2017-05-10 11:24 GMT+03:00 Tommi Rantala : >>> >>> Hi, >>> >>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work >>> correctly with v4.11-11413-g2868b25. >>> >>> When booting the laptop, the resolution seems to be limited to >>> 1024x768, and gnome-session segfaults. >>> >>> Up to 4.11 the display works just fine in 1920x1080 mode. >>> >>> I'm seeing this in the kernel logs: >>> >>> nouveau :01:00.0: eDP-1: EDID is invalid: >>> [00] BAD 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54 >>> [00] BAD 66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>> [00] BAD ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff >>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1 >>> [drm] Cannot find any crtc or sizes - going 1024x768 >>> >>> >>> $ lspci | grep NVIDIA >>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro >>> M2000M] (rev a2) >>> >>> Any ideas, or should I bisect? >>> >>> 4.11 dmesg & xrandr output: >>> https://pastebin.com/raw/P9LGP7e1 >>> >>> 4.11-11413-g2868b25 dmesg: >>> https://pastebin.com/raw/QBT9mMua >>> >>> -Tommi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-4.11 1058/1085] cc1: error: unrecognized command line option '-mhard-float'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11 head: c285c73f2213f503a93aa142fff186e160b4a371 commit: a37dcf9989ad11333dbbfef57dc4b611ce4d85a9 [1058/1085] drm/amdgpu/display: Enable DCN in DC config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout a37dcf9989ad11333dbbfef57dc4b611ce4d85a9 # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): >> cc1: error: unrecognized command line option '-mhard-float' >> cc1: error: unrecognized command line option '-msse' >> cc1: error: unrecognized command line option '-mpreferred-stack-boundary=4' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures
On 13/05/17 14:12, Laurent Pinchart wrote: >> Is it? You already use the dss compat string and soc_device_match to >> figure out some versions. Isn't that a proper way to find out about the >> SoC? But I agree that a more fine grained version management in each >> individual driver would be better. > > For OMAP2, OMAP4 or OMAP5 it shouldn't be too much of a problem, but OMAP3 > would be more painful to handle. The following machine names are used. > > "AM3505" > "AM3517" > "AM437x" > "OMAP3430/3530" > "OMAP3525" > "OMAP3515" > "OMAP3503" > "OMAP3611" > "OMAP3615/AM3715" > "OMAP3621" > "OMAP3630/DM3730" > "AM3703" > "DM3725" Don't we need all those somewhere in any case? I mean, I presume all the current OMAPDSS_VER_* defines are used somewhere. Which means that somewhere, maybe in multiple different files, we need to handle some or all of those. For some features, perhaps we could move them to DT. If the feature is about how DSS is integrated into the SoC, it might make sense to have that in the DT, as a property for DSS, as it's not part of DSS itself. If the data is missing, we could inject it into the DT at boot time, based on the omap revision. Though I'm not sure if that would really help that much. I think the most annoying "feature" is the blank/porch register field size change, that they made between OMAP3430 ES1 and ES2. And didn't bother to change the DSS IP version... But back to the topic... Are you sure this version detection should not be centralized? If we have that many OMAP3 related devices already (btw, AM4 is not really OMAP3 related, even if the DSS there is)... And if we get one more. Does it mean we need to edit that same new device into many places? Then again, maybe it's better to handle that separately in each file that requires the information, as sometimes all you need to know is that it's DSS3 based, but sometimes you need to know that it's AM4's DSS vs OMAP3's DSS. > But I don't think that removing the extra platform devices is so urgent. I'd > rather do it when we're ready. > > The omapdss driver needs major cleanup and refactoring, and that will result > in a large number of patches that will cause conflicts and be sources of > potential errors. I don't think that's avoidable. However, lots of those > cleanups will be independent from each other, so we can start merging the > less > controversial ones as soon as they're ready. I'll take care of rebasing the > rest of the patches as needed. Yes, no disagreements there. My hope is just that a series is as small as possible. Or, that's not correct... A series does one change at a time, e.g. here my problem was that the platform change was being done at the same time as the feature change, interleaved. I most likely will need to backport all these to v4.9 kernel. And then manage new patches that will be applied on top of mainline and that v4.9 kernel. And I will gladly take any changes to patch serieses that possibly make that work easier =). Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] drm: Add crtc/encoder/bridge->mode_valid() callbacks
On Fri, May 12, 2017 at 11:24:12AM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 10 May 2017 10:03:37 Daniel Vetter wrote: > > On Tue, May 09, 2017 at 06:00:08PM +0100, Jose Abreu wrote: > > > This adds a new callback to crtc, encoder and bridge helper functions > > > called mode_valid(). This callback shall be implemented if the > > > corresponding component has some sort of restriction in the modes > > > that can be displayed. A NULL callback implicates that the component > > > can display all the modes. > > > > > > We also change the description of connector->mode_valid() callback > > > so that it matches the existing behaviour: It is never called in > > > atomic check phase. > > > > > > Only the callbacks were implemented to simplify review process, > > > following patches will make use of them. > > > > > > Signed-off-by: Jose Abreu > > > Cc: Carlos Palminha > > > Cc: Alexey Brodkin > > > Cc: Ville Syrjälä > > > Cc: Daniel Vetter > > > Cc: Dave Airlie > > > Cc: Andrzej Hajda > > > Cc: Archit Taneja > > > --- > > > > > > Changes v1->v2: > > > - Change description of connector->mode_valid() (Daniel) > > > > > > include/drm/drm_bridge.h | 20 ++ > > > include/drm/drm_modeset_helper_vtables.h | 45 +++ > > > 2 files changed, 65 insertions(+) > > > > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > > index fdd82fc..00c6c36 100644 > > > --- a/include/drm/drm_bridge.h > > > +++ b/include/drm/drm_bridge.h > > > @@ -59,6 +59,26 @@ struct drm_bridge_funcs { > > > void (*detach)(struct drm_bridge *bridge); > > > > > > /** > > > + * @mode_valid: > > > + * > > > + * This callback is used to check if a specific mode is valid in this > > > + * bridge. This should be implemented if the bridge has some sort of > > > + * restriction in the modes it can display. For example, a given > bridge > > > + * may be responsible to set a clock value. If the clock can not > > > + * produce all the values for the available modes then this callback > > > + * can be used to restrict the number of modes to only the ones that > > > + * can be displayed. > > > + * > > > + * This is called at mode probe and at atomic check phase. > > > + * > > > + * RETURNS: > > > + * > > > + * drm_mode_status Enum > > > + */ > > > + enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc, > > > +const struct drm_display_mode > *mode); > > > + > > > + /** > > >* @mode_fixup: > > >* > > >* This callback is used to validate and adjust a mode. The paramater > > > diff --git a/include/drm/drm_modeset_helper_vtables.h > > > b/include/drm/drm_modeset_helper_vtables.h index c01c328..eec2c70 100644 > > > --- a/include/drm/drm_modeset_helper_vtables.h > > > +++ b/include/drm/drm_modeset_helper_vtables.h > > > @@ -106,6 +106,26 @@ struct drm_crtc_helper_funcs { > > > void (*commit)(struct drm_crtc *crtc); > > > > > > /** > > > + * @mode_valid: > > > + * > > > + * This callback is used to check if a specific mode is valid in this > > > + * crtc. This should be implemented if the crtc has some sort of > > > + * restriction in the modes it can display. For example, a given crtc > > > + * may be responsible to set a clock value. If the clock can not > > > + * produce all the values for the available modes then this callback > > > + * can be used to restrict the number of modes to only the ones that > > > + * can be displayed. > > > + * > > > + * This is called at mode probe and at atomic check phase. > > > + * > > > + * RETURNS: > > > + * > > > + * drm_mode_status Enum > > > + */ > > > + enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc, > > > +const struct drm_display_mode > *mode); > > > + > > > + /** > > >* @mode_fixup: > > >* > > >* This callback is used to validate a mode. The parameter mode is the > > > @@ -457,6 +477,26 @@ struct drm_encoder_helper_funcs { > > > void (*dpms)(struct drm_encoder *encoder, int mode); > > > > > > /** > > > + * @mode_valid: > > > + * > > > + * This callback is used to check if a specific mode is valid in this > > > + * encoder. This should be implemented if the encoder has some sort > > > + * of restriction in the modes it can display. For example, a given > > > + * encoder may be responsible to set a clock value. If the clock can > > > + * not produce all the values for the available modes then this > callback > > > + * can be used to restrict the number of modes to only the ones that > > > + * can be displayed. > > > + * > > > + * This is called at mode probe and at atomic check phase. > > > + * > > > + * RETURNS: > > > + * > > > + * drm_mode_status Enum > > > + */ > > > + enum drm_mode_status (*mode_valid)(struct drm_encoder *crtc, > > > +const struct drm_display_mode > *mode); > > > + > > > + /** > > >*
Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper
On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote: > On Friday 12 May 2017 17:06:14 Jose Abreu wrote: > > On 12-05-2017 10:35, Laurent Pinchart wrote: > > > On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote: > > >> +if (mode->status == MODE_OK) > > >> +mode->status = > > >> drm_mode_validate_connector(connector, > > >> > > >> > > >> mode); > > > > > > I would reverse the arguments order to match the style of the other > > > validation functions. > > > > Hmm, I think it makes more sense to pass connector first and then > > mode ... > > I disagree, as this function validates a mode against a pipeline, the same > way > the other validation functions validate a mode against other parameters, but > it's your patch :-) Call it drm_connector_validate_mode, because the first argument is generally the object we operate on :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()
On Fri, May 12, 2017 at 02:01:49PM +0300, Laurent Pinchart wrote: > Hi Archit, > > On Friday 12 May 2017 16:20:07 Archit Taneja wrote: > > On 05/12/2017 03:08 PM, Laurent Pinchart wrote: > > > On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote: > > >> On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote: > > >>> On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote: > > Introduce a new helper function which calls mode_valid() callback > > for all bridges in an encoder chain. > > > > Signed-off-by: Jose Abreu > > Cc: Carlos Palminha > > Cc: Alexey Brodkin > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Cc: Dave Airlie > > Cc: Andrzej Hajda > > Cc: Archit Taneja > > --- > > > > drivers/gpu/drm/drm_bridge.c | 33 + > > include/drm/drm_bridge.h | 2 ++ > > 2 files changed, 35 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_bridge.c > > b/drivers/gpu/drm/drm_bridge.c > > index 86a7637..dc8cdfe 100644 > > --- a/drivers/gpu/drm/drm_bridge.c > > +++ b/drivers/gpu/drm/drm_bridge.c > > @@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge > > *bridge, > > > > EXPORT_SYMBOL(drm_bridge_mode_fixup); > > > > /** > > > > + * drm_bridge_mode_valid - validate the mode against all bridges in > > the > > + * encoder chain. > > + * @bridge: bridge control structure > > + * @mode: desired mode to be validated > > + * > > + * Calls &drm_bridge_funcs.mode_valid for all the bridges in the > > encoder > > + * chain, starting from the first bridge to the last. If at least one > > bridge + * does not accept the mode the function returns the error > > code. > > + * > > + * Note: the bridge passed should be the one closest to the encoder. > > + * > > + * RETURNS: > > + * MODE_OK on success, drm_mode_status Enum error code on failure > > + */ > > +enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge, > > + const struct > drm_display_mode > > > > > > *mode) > > > > > +{ > > + enum drm_mode_status ret = MODE_OK; > > + > > + if (!bridge) > > + return ret; > > + > > + if (bridge->funcs->mode_valid) > > + ret = bridge->funcs->mode_valid(bridge, mode); > > + > > + if (ret != MODE_OK) > > + return ret; > > + > > + return drm_bridge_mode_valid(bridge->next, mode); > > >>> > > >>> Looks like it should be pretty trivial to avoid the recursion. > > >>> > > >>> Am I correct in interpreting this that bridges have some kind of > > >>> a hand rolled linked list implementation? Reusing the standard > > >>> linked lists would allow you to use list_for_each() etc. > > >> > > >> Yeah it's a hand-rolled list, but current hw also has a bridge nesting > > >> depth of 2, so it really doesn't matter. I guess once we have real long > > >> chains of bridges we can fix this (and just using list_head sounds like a > > >> great idea). > > > > > > Even if not really needed right now, it's a pretty easy cleanup, if Jose > > > has time to handle it in v3 of this series let's not postpone it ;-) > > > > jfyi, some of the bridge functions call the ops from the last bridge in the > > chain to first, so we'd need to use list_for_each_entry_prev() (or something > > like that) for them. > > And now that I think about it, for some of the operations (especially > enable/disable) I believe that the bridge should be able to decide whether to > call the next/previous bridge first or to configure its hardware first. I can > image bridges that need the previous bridge in the chain to provide a valid > clock before they get started, as well as bridges that need to be started > with > the incoming video signal stopped. That's why we have pre_/post_ hooks ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add crtc/encoder/bridge->mode_valid() callbacks
On Fri, May 12, 2017 at 02:29:30PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Friday 12 May 2017 09:31:00 Daniel Vetter wrote: > > From: Jose Abreu > > > > This adds a new callback to crtc, encoder and bridge helper functions > > called mode_valid(). This callback shall be implemented if the > > corresponding component has some sort of restriction in the modes > > that can be displayed. A NULL callback implicates that the component > > can display all the modes. > > > > We also change the documentation so that the new and old callbacks > > are correctly documented. > > > > Only the callbacks were implemented to simplify review process, > > following patches will make use of them. > > > > Changes in v2 from Daniel: > > - Update the warning about how modes aren't filtered in atomic_check - > > the heleprs help out a lot more now. > > - Consistenly roll out that warning, crtc/encoder's atomic_check > > missed it. > > - Sprinkle more links all over the place, so it's easier to see where > > this stuff is used and how the differen hooks are related. > > - Note that ->mode_valid is optional everywhere. > > - Explain why the connector's mode_valid is special and does _not_ get > > called in atomic_check. > > As commented on v2 (but after you sent this patch), I think we need to > document clearly how mode_valid and mode_fixup should interact. It's very > confusing for driver authors at the moment. I tried to do that here, is it not enough? Note that mode_fixup is kinda deprecated, in favour of atomic_check. So the equivalence is not as clear-cut as you seem to think. -Daniel > > > Signed-off-by: Jose Abreu > > Cc: Jose Abreu > > Cc: Carlos Palminha > > Cc: Alexey Brodkin > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Cc: Dave Airlie > > Cc: Andrzej Hajda > > Cc: Archit Taneja > > Signed-off-by: Daniel Vetter (v2) > > --- > > include/drm/drm_bridge.h | 31 + > > include/drm/drm_modeset_helper_vtables.h | 116 > > ++- 2 files changed, 114 insertions(+), 33 > > deletions(-) > > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > index fdd82fcbf168..f694de756ecf 100644 > > --- a/include/drm/drm_bridge.h > > +++ b/include/drm/drm_bridge.h > > @@ -59,6 +59,31 @@ struct drm_bridge_funcs { > > void (*detach)(struct drm_bridge *bridge); > > > > /** > > +* @mode_valid: > > +* > > +* This callback is used to check if a specific mode is valid in this > > +* bridge. This should be implemented if the bridge has some sort of > > +* restriction in the modes it can display. For example, a given > bridge > > +* may be responsible to set a clock value. If the clock can not > > +* produce all the values for the available modes then this callback > > +* can be used to restrict the number of modes to only the ones that > > +* can be displayed. > > +* > > +* This hook is used by the probe helpers to filter the mode list in > > +* drm_helper_probe_single_connector_modes(), and it is used by the > > +* atomic helpers to validate modes supplied by userspace in > > +* drm_atomic_helper_check_modeset(). > > +* > > +* This function is optional. > > +* > > +* RETURNS: > > +* > > +* drm_mode_status Enum > > +*/ > > + enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc, > > + const struct drm_display_mode > *mode); > > + > > + /** > > * @mode_fixup: > > * > > * This callback is used to validate and adjust a mode. The paramater > > @@ -82,6 +107,12 @@ struct drm_bridge_funcs { > > * NOT touch any persistent state (hardware or software) or data > > * structures except the passed in @state parameter. > > * > > +* Also beware that userspace can request its own custom modes, > neither > > +* core nor helpers filter modes to the list of probe modes reported > by > > +* the GETCONNECTOR IOCTL and stored in &drm_connector.modes. To > ensure > > +* that modes are filtered consistently put any bridge constraints and > > +* limits checks into @mode_valid. > > +* > > * RETURNS: > > * > > * True if an acceptable configuration is possible, false if the > modeset > > diff --git a/include/drm/drm_modeset_helper_vtables.h > > b/include/drm/drm_modeset_helper_vtables.h index c01c328f6cc8..91d071ff1232 > > 100644 > > --- a/include/drm/drm_modeset_helper_vtables.h > > +++ b/include/drm/drm_modeset_helper_vtables.h > > @@ -106,6 +106,31 @@ struct drm_crtc_helper_funcs { > > void (*commit)(struct drm_crtc *crtc); > > > > /** > > +* @mode_valid: > > +* > > +* This callback is used to check if a specific mode is valid in this > > +* crtc. This should be implemented if the crtc has some sort of > > +* restriction in the modes it can display. For example, a given crtc > > +* may be responsible to set a clock value
Re: [PATCH v2 7/8] drm: Use mode_valid() in atomic modeset
On Fri, May 12, 2017 at 12:53:56PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 10 May 2017 19:55:56 Daniel Vetter wrote: > > On Wed, May 10, 2017 at 09:38:00PM +0530, Archit Taneja wrote: > > > On 5/9/2017 10:30 PM, Jose Abreu wrote: > > > > This patches makes use of the new mode_valid() callbacks introduced > > > > previously to validate the full video pipeline when modesetting. > > > > > > > > This calls the connector->mode_valid(), encoder->mode_valid(), > > > > bridge->mode_valid() and crtc->mode_valid() so that we can > > > > make sure that the mode will be accepted in every components. > > > > > > > > Signed-off-by: Jose Abreu > > > > Cc: Carlos Palminha > > > > Cc: Alexey Brodkin > > > > Cc: Ville Syrjälä > > > > Cc: Daniel Vetter > > > > Cc: Dave Airlie > > > > Cc: Andrzej Hajda > > > > Cc: Archit Taneja > > > > --- > > > > > > > > Changes v1->v2: > > > > - Removed call to connector->mode_valid (Ville, Daniel) > > > > - Change function name (Ville) > > > > - Use for_each_new_connector_in_state (Ville) > > > > - Do not validate if connector and mode didn't change (Ville) > > > > - Use new helpers to call mode_valid > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c | 75 +++-- > > > > 1 file changed, 72 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > > b/drivers/gpu/drm/drm_atomic_helper.c index 8be9719..19d0ea1 100644 > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > > @@ -452,6 +452,69 @@ static int handle_conflicting_encoders(struct > > > > drm_atomic_state *state, > > > > return 0; > > > > } > > > > > > > > +static enum drm_mode_status mode_valid_path(struct drm_connector > > > > *connector, > > > > + struct drm_encoder *encoder, > > > > + struct drm_crtc *crtc, > > > > + struct drm_display_mode > > > > *mode) > > > > +{ > > > > + enum drm_mode_status ret; > > > > + > > > > + ret = drm_encoder_mode_valid(encoder, mode); > > > > + if (ret != MODE_OK) { > > > > + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() > > > > failed\n", > > > > + encoder->base.id, encoder->name); > > > > + return ret; > > > > + } > > > > + > > > > + ret = drm_bridge_mode_valid(encoder->bridge, mode); > > > > + if (ret != MODE_OK) { > > > > + DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n"); > > > > + return ret; > > > > + } > > > > + > > > > + ret = drm_crtc_mode_valid(crtc, mode); > > > > + if (ret != MODE_OK) { > > > > + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n", > > > > + crtc->base.id, crtc->name); > > > > + return ret; > > > > + } > > > > + > > > > + return ret; > > > > +} > > > > + > > > > +static int > > > > +mode_valid(struct drm_atomic_state *state) > > > > +{ > > > > + struct drm_connector_state *conn_state; > > > > + struct drm_connector *connector; > > > > + int i; > > > > + > > > > + for_each_new_connector_in_state(state, connector, conn_state, > > > > i) { > > > > + struct drm_encoder *encoder = conn_state->best_encoder; > > > > + struct drm_crtc *crtc = conn_state->crtc; > > > > + struct drm_crtc_state *crtc_state; > > > > + enum drm_mode_status mode_status; > > > > + struct drm_display_mode *mode; > > > > + > > > > + if (!crtc || !encoder) > > > > + continue; > > > > + > > > > + crtc_state = drm_atomic_get_new_crtc_state(state, crtc); > > > > + if (!crtc_state) > > > > + continue; > > > > + if (!crtc_state->mode_changed && !crtc_state > > > > ->connectors_changed) > > > > + continue; > > > > + > > > > + mode = &crtc_state->mode; > > > > + > > > > + mode_status = mode_valid_path(connector, encoder, crtc, > > > > mode); > > > > + if (mode_status != MODE_OK) > > > > + return -EINVAL; > > > > + } > > > > + > > > > + return 0; > > > > +} > > > > + > > > > /** > > > >* drm_atomic_helper_check_modeset - validate state object for modeset > > > >changes * @dev: DRM device > > > > @@ -466,13 +529,15 @@ static int handle_conflicting_encoders(struct > > > > drm_atomic_state *state, > > > > * 2. &drm_connector_helper_funcs.atomic_check to validate the > > > > connector state. > > > > * 3. If it's determined a modeset is needed then all connectors on the > > > > affected crtc > > > > *crtc are added and &drm_connector_helper_funcs.atomic_che
Re: [PATCH] drm: Add crtc/encoder/bridge->mode_valid() callbacks
On Fri, May 12, 2017 at 02:37:17PM +0200, Andrzej Hajda wrote: > On 12.05.2017 09:31, Daniel Vetter wrote: > > From: Jose Abreu > > > > This adds a new callback to crtc, encoder and bridge helper functions > > called mode_valid(). This callback shall be implemented if the > > corresponding component has some sort of restriction in the modes > > that can be displayed. A NULL callback implicates that the component > > can display all the modes. > > > > We also change the documentation so that the new and old callbacks > > are correctly documented. > > > > Only the callbacks were implemented to simplify review process, > > following patches will make use of them. > > > > Changes in v2 from Daniel: > > - Update the warning about how modes aren't filtered in atomic_check - > > the heleprs help out a lot more now. > > - Consistenly roll out that warning, crtc/encoder's atomic_check > > missed it. > > - Sprinkle more links all over the place, so it's easier to see where > > this stuff is used and how the differen hooks are related. > > - Note that ->mode_valid is optional everywhere. > > - Explain why the connector's mode_valid is special and does _not_ get > > called in atomic_check. > > > > Signed-off-by: Jose Abreu > > Cc: Jose Abreu > > Cc: Carlos Palminha > > Cc: Alexey Brodkin > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Cc: Dave Airlie > > Cc: Andrzej Hajda > > Cc: Archit Taneja > > Signed-off-by: Daniel Vetter (v2) > > --- > > include/drm/drm_bridge.h | 31 + > > include/drm/drm_modeset_helper_vtables.h | 116 > > ++- > > 2 files changed, 114 insertions(+), 33 deletions(-) > > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > index fdd82fcbf168..f694de756ecf 100644 > > --- a/include/drm/drm_bridge.h > > +++ b/include/drm/drm_bridge.h > > @@ -59,6 +59,31 @@ struct drm_bridge_funcs { > > void (*detach)(struct drm_bridge *bridge); > > > > /** > > +* @mode_valid: > > +* > > +* This callback is used to check if a specific mode is valid in this > > +* bridge. This should be implemented if the bridge has some sort of > > +* restriction in the modes it can display. For example, a given bridge > > +* may be responsible to set a clock value. If the clock can not > > +* produce all the values for the available modes then this callback > > +* can be used to restrict the number of modes to only the ones that > > +* can be displayed. > > +* > > +* This hook is used by the probe helpers to filter the mode list in > > +* drm_helper_probe_single_connector_modes(), and it is used by the > > +* atomic helpers to validate modes supplied by userspace in > > +* drm_atomic_helper_check_modeset(). > > +* > > +* This function is optional. > > +* > > +* RETURNS: > > +* > > +* drm_mode_status Enum > > +*/ > > + enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc, > > + const struct drm_display_mode *mode); > > I have put my concerns here but it touches all mode_valid callbacks. > As the callback can be called in mode probe and atomic check it could > only inspect common set of properties for both contexts, for example > crtc cannot check to which encoder it is connected, am I right? > Maybe it would be good to emphasize it here, as it is emphasized in case > of mode_fixup callbacks. You can inspect nothing else but the mode here. Looking at anything else is not allowed since this is the generic check which should work for any config. Good question, so I'll augment the docs to address this. > > + > > + /** > > * @mode_fixup: > > * > > * This callback is used to validate and adjust a mode. The paramater > > @@ -82,6 +107,12 @@ struct drm_bridge_funcs { > > * NOT touch any persistent state (hardware or software) or data > > * structures except the passed in @state parameter. > > * > > +* Also beware that userspace can request its own custom modes, neither > > +* core nor helpers filter modes to the list of probe modes reported by > > +* the GETCONNECTOR IOCTL and stored in &drm_connector.modes. To ensure > > +* that modes are filtered consistently put any bridge constraints and > > +* limits checks into @mode_valid. > > +* > > * RETURNS: > > * > > * True if an acceptable configuration is possible, false if the modeset > > diff --git a/include/drm/drm_modeset_helper_vtables.h > > b/include/drm/drm_modeset_helper_vtables.h > > index c01c328f6cc8..91d071ff1232 100644 > > --- a/include/drm/drm_modeset_helper_vtables.h > > +++ b/include/drm/drm_modeset_helper_vtables.h > > @@ -106,6 +106,31 @@ struct drm_crtc_helper_funcs { > > void (*commit)(struct drm_crtc *crtc); > > > > /** > > +* @mode_valid: > > +* > > +* This callback is used to check if a specific mode is valid in this > > +* crtc. This should be