On 12/22/2014 11:26 AM, Oded Gabbay wrote:
On 12/22/2014 10:57 AM, Christian König wrote:Am 22.12.2014 um 08:43 schrieb Oded Gabbay:On 12/22/2014 09:40 AM, Dave Airlie wrote:There should be, but when the modules are compiled in, they are loaded based on link order only, if they are in the same group, and the groups are loaded by a pre-defined order.Is that really still up to date? I've seen effort to change that something like 10+ years ago when Rusty reworked the module system. And it is comming up on the lists again from time to time.From what I can see in the Makefile rules, code and google, yes, that's still the situation. If someone will prove me wrong I will be more than happy to correct my code.I don't want to move iommu before gpu, so I don't have a solution for the order between amdkfd and amd_iommu_v2.Why not? That's still better than creating a kernel workqueue, scheduling one work item on it, rescheduling the task until everything is completed and you can continue.Because I don't know the consequences of moving an entire subsystem in front of another one. In addition, even if everyone agrees, I'm pretty sure that Linus won't be happy to do that in -rc stages. So maybe this is something to consider for 3.20 merge window, but I would still like to provide a solution for 3.19.Yeah, true indeed. How about depending on everything being compiled as module for 3.19 then? Still better than having such a hack in the driver for as a temporary workaround for one release.I thought about it, but because this problem was originally reported by a user that told us he couldn't use modules because of his setup, I decided not to. I assume there are other users out there who needs this option (compiled everything in the kernel - embedded ?), so I don't want to make their life harder. In addition, saying it is a workaround for one release is true in case moving iommu subsystem in front of gpu subsystem is acceptable and doesn't cause other problems, unknown at this point. Bottom line, my personal preference is to help the users _now_ and if a better fix is found in the future, change the code accordingly.My guess is moving the iommu subsystem in front of the GPU would be rational. It does seem like it would generally have a depend in that order. Dave.Dave, I agree, but don't you think it is too risky for -rc stages ? If not, I can try it and if it works on KV, I can submit a patch. But if you do think it is risky, what do you recommend for 3.19 ? Do the fix I suggested or disable build-in compilation option ?I would say create the patch of changing the order (should be trivial), describe in detail in the commit message what this is supposed to fix and why such an severe change was done in -rc1 and submit it upstream. We can still revert it in -rc2 if it breaks anything. Christian.OdedOK, I'll try it on my machine and if it works, I will send the patch to the list. Oded _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
So I checked it and all my HSA tests are passing on KV machine.
I will send the patches today. Please discard the current patch-set.
Oded
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
