-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable vchiq on ARCH_BCM2835 #973
Conversation
Prepare to turn the vchiq module into a driver. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Turn vchiq into a driver and stop hardcoding resources. Use devm_* functions in probe path to simplify cleanup. A global variable is used to hold the register address. This is done to keep this patch as small as possible. Also make available on ARCH_BCM2835. Based on work by Lubomir Rintel. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Add vchiq to Device Tree. There are no kernel users yet, but it's available to userspace (vcgencmd). Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Fine by me. @pelwell - this is your code - feel free to merge if happy. |
I'm fine with the substance of the change - thanks! - but I'm not keen on the division into multiple commits. I would argue that the first two patches should be combined into one, since the first patch is useless without the second, and causing the kernel to attempt to load what is effectively a non-existent module (because of the lack of a "compatible" string), though harmless, seems like bad form when it could so easily be avoided. |
It is common practice in mainline to split driver commits from device commits. Actually the first commit would probably have been 3 commits in mainline. Following your logic all three should be squashed. One problem with having large commits is that it makes it more difficult to browse the git log for changes. This is quite a big project so many people are reading the git log. But I'll squash the first two if you want it that way. |
Any thoughts, @popcornmix? |
I guess it depends on whether we can see these commits being upstreamed. If they are not being upstreamed, then I generally prefer the minimal number of commits. It generally makes cherry-picking, rebasing and bisecting simpler if you don't have a long list of dependent commits. |
I wouldn't have thought anything of it if the two device commits weren't on opposite sides of the driver commit, but if this is as you would like it to be then I'm not going to be awkward about it. |
Tested on Pi1 and Pi2 regular kernel with and without DT + ARCH_BCM2835.
Tested from userspace: