Re: [PATCH v6] gpu: ipu-csi: Swap fields according to input/output field types
Hi Steve,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steve-Longerbeam/gpu-ipu-csi-Swap-fields-according-to-input-output-field-types/20181215-135741
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/gpu//ipu-v3/ipu-csi.c: In function 'ipu_csi_set_bt_interlaced_codes':
>> drivers/gpu//ipu-v3/ipu-csi.c:407:17: error: implicit declaration of
>> function 'V4L2_FIELD_IS_SEQUENTIAL'; did you mean 'V4L2_CID_RDS_RECEPTION'?
>> [-Werror=implicit-function-declaration]
swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
^~~~
V4L2_CID_RDS_RECEPTION
cc1: some warnings being treated as errors
vim +407 drivers/gpu//ipu-v3/ipu-csi.c
385
386 static int
387 ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
388 const struct v4l2_mbus_framefmt *infmt,
389 const struct v4l2_mbus_framefmt *outfmt,
390 v4l2_std_id std)
391 {
392 enum v4l2_field infield, outfield;
393 bool swap_fields;
394
395 /* get translated field type of input and output */
396 infield = ipu_csi_translate_field(infmt->field, std);
397 outfield = ipu_csi_translate_field(outfmt->field, std);
398
399 /*
400 * Write the H-V-F codes the CSI will match against the
401 * incoming data for start/end of active and blanking
402 * field intervals. If input and output field types are
403 * sequential but not the same (one is SEQ_BT and the other
404 * is SEQ_TB), swap the F-bit so that the CSI will capture
405 * field 1 lines before field 0 lines.
406 */
> 407 swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
408 V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
409 infield != outfield);
410
411 if (!swap_fields) {
412 /*
413 * Field0BlankEnd = 110, Field0BlankStart = 010
414 * Field0ActiveEnd = 100, Field0ActiveStart = 000
415 * Field1BlankEnd = 111, Field1BlankStart = 011
416 * Field1ActiveEnd = 101, Field1ActiveStart = 001
417 */
418 ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
419CSI_CCIR_CODE_1);
420 ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
421 } else {
422 dev_dbg(csi->ipu->dev, "capture field swap\n");
423
424 /* same as above but with F-bit inverted */
425 ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
426CSI_CCIR_CODE_1);
427 ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
428 }
429
430 ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
431
432 return 0;
433 }
434
---
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 v6] gpu: ipu-csi: Swap fields according to input/output field types
Hi Steve,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steve-Longerbeam/gpu-ipu-csi-Swap-fields-according-to-input-output-field-types/20181215-135741
config: nds32-allmodconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32
All errors (new ones prefixed by >>):
drivers/gpu/ipu-v3/ipu-csi.c: In function 'ipu_csi_set_bt_interlaced_codes':
>> drivers/gpu/ipu-v3/ipu-csi.c:407:17: error: implicit declaration of function
>> 'V4L2_FIELD_IS_SEQUENTIAL' [-Werror=implicit-function-declaration]
swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
^~~~
cc1: some warnings being treated as errors
vim +/V4L2_FIELD_IS_SEQUENTIAL +407 drivers/gpu/ipu-v3/ipu-csi.c
385
386 static int
387 ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
388 const struct v4l2_mbus_framefmt *infmt,
389 const struct v4l2_mbus_framefmt *outfmt,
390 v4l2_std_id std)
391 {
392 enum v4l2_field infield, outfield;
393 bool swap_fields;
394
395 /* get translated field type of input and output */
396 infield = ipu_csi_translate_field(infmt->field, std);
397 outfield = ipu_csi_translate_field(outfmt->field, std);
398
399 /*
400 * Write the H-V-F codes the CSI will match against the
401 * incoming data for start/end of active and blanking
402 * field intervals. If input and output field types are
403 * sequential but not the same (one is SEQ_BT and the other
404 * is SEQ_TB), swap the F-bit so that the CSI will capture
405 * field 1 lines before field 0 lines.
406 */
> 407 swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
408 V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
409 infield != outfield);
410
411 if (!swap_fields) {
412 /*
413 * Field0BlankEnd = 110, Field0BlankStart = 010
414 * Field0ActiveEnd = 100, Field0ActiveStart = 000
415 * Field1BlankEnd = 111, Field1BlankStart = 011
416 * Field1ActiveEnd = 101, Field1ActiveStart = 001
417 */
418 ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
419CSI_CCIR_CODE_1);
420 ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
421 } else {
422 dev_dbg(csi->ipu->dev, "capture field swap\n");
423
424 /* same as above but with F-bit inverted */
425 ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
426CSI_CCIR_CODE_1);
427 ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
428 }
429
430 ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
431
432 return 0;
433 }
434
---
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 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 --- Comment #11 from Brian Schott --- "bc537a9cc47eec7f4e32b8164c494ddc35dca8ac is the first bad commit" Well, that's kind of useless. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=bc537a9cc47eec7f4e32b8164c494ddc35dca8ac Any suggestions on how to get a better idea of where the break was? -- 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 109064] temp_comp_access::get_required_live_range: enclosing_scope_first_write is NULL
https://bugs.freedesktop.org/show_bug.cgi?id=109064 Alex Xu (Hello71) changed: What|Removed |Added OS|All |Linux (All) Hardware|Other |x86-64 (AMD64) Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|glsl-compiler QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org|ktop.org -- 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 109068] Raven Ridge: backlight is off after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=109068 Bug ID: 109068 Summary: Raven Ridge: backlight is off after suspend Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: samant...@posteo.net This is an issue on amd-staging-drm-next but not on 4.19.7. I have not tested other kernels. The issue is that if you put the system in suspend and wake it up again, the backlight is off. On 4.19 when you resume from suspend the backlight resumes the same level it was when you put it into suspend. -- 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 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 Samantha McVey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Samantha McVey --- Going to close this one as fixed. -- 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 v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
> > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas > wrote: > > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam > > > > > > wrote: > > > > > > > > Tomas and Daniel, > > > > > > > > We got an issue here. > > > > > > > > The relationship that we try to build between I915 and mei_hdcp is as > follows: > > > > > > > > We are using the components to establish the relationship. > > > > I915 is component master where as mei_hdcp is component. > > > > I915 adds the component master during the module load. mei_hdcp > > > > adds the > > > component when the driver->probe is called (on device driver binding). > > > > I915 forces itself such that until mei_hdcp component is added > > > > I915_load > > > wont be complete. > > > > Similarly on complete system, if mei_hdcp component is removed, > > > immediately I915 unregister itself and HW will be shutdown. > > > > > > > > This is completely fine when the modules are loaded and unloaded. > > > > > > > > But during suspend, mei device disappears and mei bus handles it > > > > by > > > unbinding device and driver by calling driver->remove. > > > > This in-turn removes the component and triggers the master unbind > > > > of I915 > > > where, I915 unregister itself. > > > > This cause the HW state mismatch during the suspend and resume. > > > > > > > > Please check the powerwell mismatch errors at CI report for v9 > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/ > > > > igt@ > > > > gem_exec_susp...@basic-s3.html > > > > > > > > More over unregistering I915 during the suspend is not expected. > > > > So how do > > > we handle this? > > > > > > Bit more context from our irc discussion with Ram: > > > > > > I found this very surprising, since I don't know of any other > > > subsystems where the devices get outright removed when going through a > suspend/resume cycle. > > > The device model was built to handle this stuff > > > correctly: First clients/devices/interfaces get suspend, then the > > > parent/bridge/bus. Same dance in reverse when resuming. This even > > > holds for lots of hotpluggable buses, where child devices could > > > indeed disappear on resume, but as long as they don't, everything > > > stays the same. It's really surprising for something that's soldered onto > > > the > board like ME. > > > > HDCP is an application in the ME it's not ME itself.. On the linux > > side HDCP2 is a virtual device on mei client virtual bus, the bus is > > teared > down on ME reset, which mostly happen on power transitions. > > Theoretically, we could keep it up during power transitions, but so > > fare it was not necessary and second it's not guarantie that the all ME > applications will reappear after reset. > > When does this happen that an ME application doesn't come back after e.g. > suspend/resume? No, this can happen in special flows such as fw updates and error conditions, but is has to be supported as well. > > Also, what's all the place where this reset can happen? Just > suspend/resume/hibernate and all these, or also at other times? Also on errors and fw update, the basic assumption is here that it can happen any time. > How does userspace deal with the reset over s/r? I'm assuming that at least > the > device node file will become invalid (or whatever you're using as userspace > api), so if userspace is accessing stuff on the me at the same time as we do a > suspend/resume, what happens? > > > > Aside: We'll probably need a device_link to make sure mei_hdcp is > > > fully resumed before i915 gets resumed, but that's kinda a detail for > > > later > on. > > > > Frankly I don’t believe there is currently exact abstraction that > > supports this model, neither components nor device_link . > > So fare we used class interface for other purposes, it worked well. > > I'm not clear on what class interface has to do with component or device link. > They all solve different problems, at least as far as I understand all this > stuff ... > -Daniel It comes instead of it, device_link is mostly used for power management and component as we see know is not what we need as HDCP Is a b it volitle. class_interface gives you two handlers: add and remove device, that's all what is needed for the current implementation. > > > > Tomas, can you pls explain why mei is designed like this? Or is > > > there something else we're missing (I didn't dig through the mei bus > > > in detail at all, so not clear on what exactly is going on there). > > Above. > > > > > > Also pulling in device model and suspend/resume experts. > > > > > > Thanks, Daniel > > > > > > > > > > > -Ram > > > > > > > > On 12/13/2018 9:31 AM, Ramalingam C wrote: > > > > > > > > Mei hdcp driver is designed as component slave for the I915 > > > > component master. > > > > > > > > v2: Rebased. > > > > v3: > > > > Notifier chain is adopted for cldev state update [Tomas] > > > > v4: > > > > Made static dummy functions as inline in mei_hdcp.h > > > > API
[Bug 109066] Launching Libretro Nestopia Core in Retroarch Triggers AMDGPU Kernel Bug
https://bugs.freedesktop.org/show_bug.cgi?id=109066 Bug ID: 109066 Summary: Launching Libretro Nestopia Core in Retroarch Triggers AMDGPU Kernel Bug Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: b...@xnode.org Created attachment 142818 --> https://bugs.freedesktop.org/attachment.cgi?id=142818=edit Full Kernel Bug Output Trying to launch RetroArch's Nestopia core with this machine (using an AMD Vega 56) throws the following error (full output attached): kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4970! This is repeatable 100% of the time (although the number at the end appears to differ). == Versions OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.27.0, 4.19.8-arch1-1-ARCH, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-7fe4e0ad5d) OpenGL core profile shading language version string: 4.50 -- 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 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040
https://bugs.freedesktop.org/show_bug.cgi?id=108940 --- Comment #10 from Leonid Moiseichuk --- Created attachment 142817 --> https://bugs.freedesktop.org/attachment.cgi?id=142817=edit xubuntu 18.10 kernel with high loglevel I see the number of problems reported on ASRock x470 + amd Ryzen 5 2400g during boot: $ grep WARNING 4.18.0-13-generic.log [3.938686] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1553 core_link_enable_stream+0x74c/0xc90 [amdgpu] [3.939285] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1582 core_link_enable_stream+0x78e/0xc90 [amdgpu] [3.939863] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1553 core_link_enable_stream+0x74c/0xc90 [amdgpu] [3.940450] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1572 core_link_enable_stream+0xacd/0xc90 [amdgpu] [3.941029] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1582 core_link_enable_stream+0x78e/0xc90 [amdgpu] [3.941610] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1553 core_link_enable_stream+0x74c/0xc90 [amdgpu] [3.942190] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1572 core_link_enable_stream+0xacd/0xc90 [amdgpu] [3.942766] WARNING: CPU: 0 PID: 323 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1582 core_link_enable_stream+0x78e/0xc90 [amdgpu] -- 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 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 fin4...@hotmail.com changed: What|Removed |Added CC||fin4...@hotmail.com --- Comment #11 from fin4...@hotmail.com --- There is very little happening for amdgpu and radeon drivers in mainline kernels. See the diff column at kernel.org and compare this: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip So, use a rolling release OS, the Amd wip kernel and Mesa git, like Oibap ppa. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201991] amdgpu: clock management is disabled for the 4K resolution with polaris 10
https://bugzilla.kernel.org/show_bug.cgi?id=201991 --- Comment #3 from fin4...@hotmail.com --- Adding amdgpu.ppfeaturemask=0x to the kernel command line makes the powerplay feature to work normally at 4K. uname -r 4.20.0-rc3+ -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3
https://bugs.freedesktop.org/show_bug.cgi?id=106490 --- Comment #7 from Kristoffer --- This affects not only Chromium but also Totem and Epiphany when using VA-API. MPV does not seem affected, so it seems to me as if anything using gstreamer is affected. https://imgur.com/a/2Fi989D -- 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 3/6] sparc: remove the sparc32_dma_ops indirection
On Fri, Dec 14, 2018 at 10:30:18PM -0800, Guenter Roeck wrote: > and so on, until qemu is terminated. This is seen with all sparc32 > qemu emulations. Reverting the patch fixes the problem. Hi Guenter, can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
