On Fri, 26 May 2017, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > Yes, I wanted to do this for years now... The I2C core became a huge monolithic > blob getting harder and harder to maintain. This series breaks out some > functional parts into seperate files. This makes the code easier to handle > because of the smaller chunks. It reduces ifdeffery because we can now handle > compilation at the Makefile level. And it helps to spread responsibility, e.g. > the ACPI maintainers do now have a dedicated file listed in MAINTAINERS. > > This series was tested with a Renesas Lager board (R-Car H2 SoC). It booted > normally and all device drivers for I2C clients seem to work normally. I wired > two I2C busses together and used i2c-slave-eeprom to let one I2C IP core read > out data from the other. That all worked fine. Buildbot is also happy, it found > two issues of the first (non public) iteration. Thanks! > > I did not test ACPI and hope for some assistance here :) I'd also be happy if > people could check the includes of the newly created files, there might be > missing some. If you don't mind sending the whole series to the intel-gfx list (Cc'd), our CI will run a bunch of tests on it, exercising our use of the I2C adapter interfaces for display data channel and I2C over Display Port native aux. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
