Hi Chris, On 12/08/2016 09:01 AM, Chris Wilson wrote: > On Thu, Dec 08, 2016 at 08:50:17AM -0700, Shuah Khan wrote: >> On 12/07/2016 07:09 AM, Chris Wilson wrote: >>> On Wed, Dec 07, 2016 at 01:58:19PM +0000, Chris Wilson wrote: >>>> Although being a GPU driver most functionality of i915.ko depends upon >>>> real hardware, many of its internal interfaces can be "mocked" and so >>>> tested independently of any hardware. Expanding the test coverage is not >>>> only useful for i915.ko, but should provide some integration tests for >>>> core infrastructure as well. >>>> >>>> Loading i915.ko with mock_selftests=-1 will cause it to execute its mock >>>> tests then fail with -ENOTTY. If the driver is already loaded and bound >>>> to hardware, it requires a few more steps to unbind, and so the simple >>>> preliminary modprobe -r will fail. >>> >>> I changed the exit condition to return 0 after successfully completing >>> the mock tests (when passed mock_selftests=-1) so modprobe reports >>> success/fail clearly. >>> -Chris >>> >> >> Hi Chris, >> >> Is this patch slated to go in through drm tree with the other patches >> in the series. Just make sure you create .gitignore for any generated >> files that should be ignored by git > > If you agree to having it turn up via the drm tree, then yes :) When there is a dependency, it makes sense for it to go through drm. Looks like there are no dependencies in this script. It is now applied to linux-kselftest next for 4.10-rc1 > > Is there any guideline on test behaviour I can read? Is there a > particular directory structure you like? I have a few selftests planned > for i915.ko and core drm.ko, and maybe a few other gpus will join in > over time (certainly should write a few for drivers/gpu/drm/vgem/vgem.ko as > well), is selftests/drivers/gpu/(drm.sh, i915.sh, vgem.sh, etc) > suitable? This test isn't hooked into kselftest run and install as is. I applied it anyway since it doesn't impact anything. If you want these tests run during kselftest run, then add a Makefile for run and install. Good examples for your case are: tools/testing/selftests/firmware tools/testing/selftests/net grep modprobe */* will show you other tests that depend on module being loaded. General guide is if a test can't be run because of module not being there then SKIP without impacting the run with a clear message that test is skipped because module isn't there is good. Kselftest lacks driver test support at the moment and any efforts to add tests is greatly appreciated. So please send patches. thanks, -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html