More changes to GEM are on the cards, so before touching it again, let's try and nail down how the internals are meant to work. The advantage of mock testing is that we can write a universal test independent of the hw (e.g. testing physical object creation) and we can inspect internal state which should be able to spot subtle bugs easier than mashing the uabi. The downside to mock testing is that it doubles the upfront cost of every patch submission (if you change internal state, you're likely going to upset a test) and adds maintainance burden tracking change to external API (on the other hand it catches those silent changes that would lead to broken code). In addition to mock tests, I thought it would be useful to start writing a few run-once tests against real hardware. These are not as interesting as probing uabi (I don't envisage having kms_flip inside the kernel), but we might like to exercise runtime suspend once upon startup, for example. Again, we have access to internal state that may prove impossible to capture even in debugfs. Is this a totally insane and impractical proposal? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
