Add i2x_mux_pca9545 overlay to configure mux

[camrex]

Added the overlay.dts file for the pca9545 mux and made appropriate
changes to the MAKEFILE and README

[camrex]

This has been tested. Combined 3 commits into 1 and fixed the overlay file name, which was a oversight on my part.

[6by9]

@pelwell Looks fine to me, but I just wondered if there is a case for merging all the i2cmux overlays into one in the same way as i2c-rtc-overlay. Doing that sooner rather than later would avoid breakages if the old overlays get dropped.

[pelwell]

Hmm - it should be possible to do something slightly better than gluing the two files together.

@camrex Does that sound OK to you?

[pelwell]

It turns out it isn't so nice, but it is possible. See https://gist.github.com/pelwell/a8b10579ebee2633390a747e16112fb3 for my attempt. I had hoped to break the subnodes for the different buses out into different fragments that I could then enable conditionally based on the device type, but a fragment can't target another fragment, and using target-path would stop it being used on systems where i2c-arm equates to i2c0.

This implementation gives us the desired parameter syntax, and even though the file is large it doesn't take up extra space in the DTB when applied, so I'm happy with it for now.

You can download a version to try here. Use like this:

dtoverlay=i2c-mux,pca9545
dtoverlay=i2c-mux,pca9548,addr=0x71

[6by9]

You're a braver man than me attempting that, but it sounds like a good solution.

(I have a spare tca9548 I can throw your way if you wanted hardware to test this with - I bought a pair to play with, but don't really have any application for them. Saves an order to Pimoroni)

[pelwell]

Thanks for the offer, but using the new dtmerge application and dtdiff I've satisfied myself that the old and new ways are equivalent.

[camrex]

I have no problem with the two being merged. My only suggestion is that it
be done for the whole family of pca954x, if possible.

I had originally planned to write a universal overlay, but went the simple
route. Here is a link to my proposed universal:
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=141517&p=959340#p959340

I realize that in its current form it would not work, but may spark ideas
for how to include support for all of the pca954x muxs.

I based the universal overlay off of the RTC overlay, with all devices
under a single fragment.

Nevertheless, if including the whole family of pca954x is problematic, I
have no problem with the merged (or separate) overlays.

Cameron Rex, MAI, GISP
RMI Midwest: Appraiser/GIS Analyst
www.rmimidwest.com | [email protected]
1200 Central Avenue, Ste 330, Wilmette, IL 60091
Office: (847) 920-9033
Cell: (847) 347-4567

On Wed, May 11, 2016 at 9:05 AM, Phil Elwell [email protected]
wrote:

Thanks for the offer, but using the new dtmerge application and dtdiff
I've satisfied myself that the old and new ways are equivalent.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1465 (comment)

[pelwell]

I'm going to add 9542. If there is demand for the others then I'll do the best I can with the tools available at the time.

@6by9 Shall I remove i2c-mux-pca6548a at the same time?

[6by9]

@6by9 Shall I remove i2c-mux-pca6548a at the same time?

Fine by me.
Perhaps a comment in the README saying it's been deprecated and replaced by the generic i2c-mux. Once merged I'll update the original post on https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=141517 too to reflect the change.

[pelwell]

I've pushed the commit adding i2c-mux and deleting i2c-mux-pca9548a. Note that the default address is 0x70 for all three variants - pca9542, pca9545 and pca9548.