SPLIT_KEYBOARD migration for the Iris broke I2C

[NimMM90]

• PROBLEM:
  Flashing both sides of the Iris with a new hex made after the migration to the split-common code leaves the Slave side inoperable when using i2c.

• TESTING:
  Changing the SCL_CLOCK in quantum/split_common/i2c.h from #define SCL_CLOCK 400000L to #define SCL_CLOCK 100000L seems to fix the problem

• ADDITIONAL
  It might be worth making note of this, as this could mean still needing separate i2c configs for each board

[drashna]

@That-Canadian @nooges

I know that the Lets Split (OG) uses 400000L, but the keebio boards use 100000L here.
(the orthodox uses 100000UL though)

I'm not familiar enough with the code or i2c to know why, but is there a reason that this causes issues?

Worst case, could replace the line here:
https://github.com/qmk/qmk_firmware/blob/master/quantum/split_common/i2c.h#L28
With:

#ifndef SCL_CLOCK
#define SCL_CLOCK 400000L
#endif

As that should allow it to be configured per keyboard?

Also, if any of the other values are stuff that can (or needs to) be redefined, it should probably be handled in the same way.

[nooges]

From what I recall, since the boards use 4.7kΩ resistors, it should still be good for operating at 400kHz, but I haven't tried it in a while: http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors

[drashna]

@nooges This is a completely blind shot in the dark, but ... my Iris has issues with the RGB stuff (over extra data). If there was some sort of extra resistance because of the PCB, TRRS jack or cable, couldn't that cause both the RGB light issue that I see, as well as the communication issue?

[nooges]

Addressed with #3474