Skip to content
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

I2c1_baudrate being overridden by i2c.conf in 25-Feb-2016 distribution #1333

Closed
JohnNavratil opened this issue Mar 9, 2016 · 11 comments
Closed

Comments

@JohnNavratil
Copy link

After a recent distribution upgrade to...

Linux rpi0 4.1.18+ #846 Thu Feb 25 14:11:56 GMT 2016 armv6l GNU/Linux

...my i2c bus failed and I could not detect any devices. After putting a scope on the bus I determined it was running at 800MHz when I had the i2c1_baudrate in /boot/config.txt set to 100KHz. Changing the baudrate in config.txt has no effect. /etc/modprobe.d/i2c.conf had set the rate to 800MHz. I uncommented that line in /etc/modprobe.d/i2c.conf to restore the i2c bus (my devices are not that fast.)

To recreate the issue, set a baudrate in /etc/modprobe.c/i2c.conf and attempt to set it to lower value (slower bus) in /boot/config.txt.

@pelwell
Copy link
Contributor

pelwell commented Mar 9, 2016

That is the intended behaviour. It allows the baudrate to be modified without rebooting by overriding the DT-specified value with the module parameter. If you don't want to override the baud rate from a .conf file, don't do it.

See #1241 for more details.

@JohnNavratil
Copy link
Author

I'm quite happy with that, but I don't understand how my distribution update caused it to be done. I often cannot remember what I ate yesterday, but I certainly don't recall editing i2c.conf. It documents that standard i2c is 100KHz, but then sets 800KHz. My previous distributions did not actually have an i2c.conf. Does the distro upgrade do something it shouldn't - that is set a non-standard i2c baudrate? Apologies if I sound stupid, I'm a programmer, not an admin.

@JohnNavratil
Copy link
Author

Thanks for that reference to #1241. May I add that from this user's perspective, "device tree" is documented as the way forward and modprobe .conf files are last years news. Tribal knowledge may well be valuable here, but the documentation is not. All references are to /boot/config.txt and none are to i2c.conf.

Taking your admonition not to override the baudrate from a .conf file, may I suggest the .conf file as delivered not provide any override, at all?

@pelwell
Copy link
Contributor

pelwell commented Mar 9, 2016

Where do you think that file came from? I would be very surprised if it was part of any Raspbian distribution.

@JohnNavratil
Copy link
Author

I think it DID come from a apt-get dist-upgrade. My evidence is that I upgraded one SD card and observed the failure. Then I tested a clone of that card to observe a functioning i2c bus, did an apt-get dist-upgrade and observed a failure of that bus. That is what started my investigation.

@pelwell
Copy link
Contributor

pelwell commented Mar 9, 2016

Well it isn't present on my Pi. @XECDesign Does /etc/modprobe.d/i2c.conf ring any bells with you?

@XECDesign
Copy link
Contributor

I certainly didn't add it and would be surprised if it the file itself came from the upgrade.

@JohnNavratil
Copy link
Author

Perhaps I've left enough of a bread crumb trail for the next person. Thanks for you help.

@JohnNavratil
Copy link
Author

Greetings, and I hate to beat a dead horse, but further analysis of this shows that the i2c.conf file to which I referred was indeed a legacy from prior distribution levels. Prior to my recent distribution upgrade, the baudrate settings from /boot/config.txt were used. With the upgrade. the setting from /etc/modprobe.d/i2c.conf was used. 'pelwell' comments that is the way it is designed to work.

I'm sympathetic with the doctor telling to stop doing something that hurts, and I'm happy to have removed the offending i2c.conf.

The question is, should it work this way? If we are migrating away from config files toward dtparams, shouldn't the latter be preferred? I foresee problems in distribution upgrades if this isn't the case.

@pelwell
Copy link
Contributor

pelwell commented Mar 11, 2016

The presence of an i2c.conf installed by Raspbian is still the subject of surprise here. It's not present on my system, but if you say that is where you got it, and not as the result of following some online tutorial, then I'll take your word for it.

I agree completely about Device Tree being the way forward - I've been the DT advocate and instigator here, and I've tried to make it as user friendly as I can. But I also had some sympathy for the user who had lost flexibility and was suggesting a compromise.

I'm hoping to roll out a Dynamic Device Tree patch once the Pi3 dust has settled. This will allow overlays to be loaded and unloaded at run time. I'm sure this will have limitations and will expose shortcomings in the rest of the system - not all modules will unload so easily - but I'd rather make it available with caveats and let users find out what works and what doesn't.

@Ruffio
Copy link

Ruffio commented Aug 17, 2016

@JohnNavratil has your issue been resolved? If so, please close this issue. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants