Add support for pps-rp1 dtoverlay.

[josh-blake]

Add support for pps-rp1 dtoverlay. Enables advanced pinctrl features found on RP1 based RPis including Schmitt trigger. Allows multiple PPS devices. Enables the Echo function found on the PPS GPIO kernel module. See https://github.com/josh-blake/pps-rp1 for documentation on the dtoverlay.

[pelwell]

That's an innovative use of the lookup tables. I'll have to see if there is some other, less hacky way to get the RP1 pinctrl driver to use particular GPIOs - perhaps accepting the old brcm,pins format, or the GPIO numbers as strings without the "gpio" prefix - without breaking all the existing uses.

The big problem with this submission is that it does nothing: it has no entry in the Makefile, so it won't get compiled, and it has the wrong name - pps-rpi-overlay.dts is required for an overlay, which then gets compiled into pps-rpi.dtbo. If you change the name and update the PR with git push --force you will get proper feedback from the overlay checker.

[josh-blake]

That's an innovative use of the lookup tables. I'll have to see if there is some other, less hacky way to get the RP1 pinctrl driver to use particular GPIOs - perhaps accepting the old brcm,pins format, or the GPIO numbers as strings without the "gpio" prefix - without breaking all the existing uses.

The big problem with this submission is that it does nothing: it has no entry in the Makefile, so it won't get compiled, and it has the wrong name - pps-rpi-overlay.dts is required for an overlay, which then gets compiled into pps-rpi.dtbo. If you change the name and update the PR with git push --force you will get proper feedback from the overlay checker.

Thanks heaps. I wasn't sure with new overlay submissions what process was preferred (ie a dev manually updated the Makefile once the dto was accepted etc). With my own kernel builds, I have amended the filename and added the dtbo to the Makefile, and it compiles up just fine. I have updated my PR but have not forced a push per se.

Re: the RP1 pinctrl interface, it was exceedingly annoying and the only (inelegant) solution was to use a LUT. There is no way to coalesce or concatenate values in the DTC. I toyed with the idea of modifying byte-wise but came up against ascii offset vs actual number. I would imagine the LUT, were the pinctrl interface updated, would need to be included there instead. A quick glance at the source would suggest that the whole LUT is necessary because the pins created by label instead

[josh-blake]

Any ideas on what to do for this 'bad token' error that the dtoverlaycheck process is complaining about? I cannot have more than 100cols in the line without it complaining about length, but then errors out when I have a linebreak and tabs within the quote block?

[pelwell]

The line length checks are in checkpatch.pl, a standard kernel dev tool. We don't care about them so much, especially for Device Tree files. What you've done is split a string, which breaks the compilation and confuses the parser. It's better to live with the line length warnings.

[josh-blake]

In other news, I found a small tidbit on the v0.4 DT spec that should allow for string concatenation in the device tree although I think there may be a bug in how it's implemented. I have opened an issue here for clarity on how the spec was defined. I have tried every possible permutation here in label referencing but the DT Overlay crashes out.

[josh-blake]

I should also add that I wholeheartedly disagree with the dtoverlaycheck script re: 'vestigal' pin use. The overlay clearly defines the bcm2712 and should not (unless the hardware developers intend to redefine pin assignment) do anything untoward. Choosing a param name that is verbose to simply circumvent this check detracts from the descriptive nature of the param as it is, and leads to a counterintuitive experience.

[pelwell]

I should also add that I wholeheartedly disagree with the dtoverlaycheck script re: 'vestigal' pin use.

Relax - I suspect the checker has just been confused by the TABs, and therefore failed to notice the pin parameter.

[pelwell]

I'm happy for you to keep pushing updates here, but you may prefer to run overlaycheck yourself: https://github.com/raspberrypi/utils/tree/master/overlaycheck

[josh-blake]

I'm happy for you to keep pushing updates here, but you may prefer to run overlaycheck yourself: https://github.com/raspberrypi/utils/tree/master/overlaycheck

Thanks heaps for this. I ran it locally before my most recent commit. Is there anyway to flatten the PR so that the checkpatch test stops looking at prior commits? I’m new to git from a development standpoint and don’t know the magic incantations.

[pelwell]

To squash all your commits down to one, you've got two options:

1. Use git rebase -i HEAD~n (where n is the number of commits to look back - a few extra doesn't matter). You will be presented a list of those commits, prefixed with pick. To move a commit in the sequence, move the line. To delete a commit, delete the line. To squash a commit with the previous, change pick to squash (or just s) - you will end up with a suggested commit message which is the combination of the two to edit. If the follow-up commits are just fixups that don't warrant any additional comments, use fixup (f) - the first commit message will be used unaltered. In your case, you would probably just mark all the follow-up commits as fixups.
2. git reset HEAD~n will delete the top n commits but keep the changes staged, then git commit in the usual way. This has the disadvantage of losing all of the commit messages. But if n is the number of commits you want to squash away excluding the first one with the message you want to keep, you can then git commit --amend to combine the staged changes with the previous commit.

Once you've done that, use git push --force to your github branch to update the PR.

[josh-blake]

Thanks again for your help in navigating this. I have rebased (I think?) and forced another push. 🤞🏼🤞🏼

[pelwell]

I could live with those checkpatch warnings, but if it's OK with you I'll wait for this run of checks to complete, fix the trailing whitespace locally, and push it manually. It will save all of that needless kernel building.

[josh-blake]

Sorry - I'm just seeing your reply now - changed the README file as I don't show a trailing whitespace on my end; pushing a new commit just states that I'm up to date. So I changed the remark slightly and rebased off that. :/ ... Sorry for the faff around with this. Very green (but trying?).

[pelwell]

Leave this with me now

[pelwell]

One last question: You've got an unrecognised "License Identifier" of GPL-3.0-only. Do I have your permission as the author to change that to GPL-2.0-only?

[pelwell]

If not, I may have to drop this PR as AFAIK Linux is strictly GPL v2.

[josh-blake]

One last question: You've got an unrecognised "License Identifier" of GPL-3.0-only. Do I have your permission as the author to change that to GPL-2.0-only?

Yes - of course. Happy for GPL-2.0-only.

[pelwell]

Phew. Amended accordingly and merged offline.