All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: linux-i2c@vger.kernel.org
Cc: linux-doc@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Wolfram Sang <wsa@the-dreams.de>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH 0/8] i2c: refactor core and break out blocks
Date: Fri, 26 May 2017 14:57:48 +0300	[thread overview]
Message-ID: <8737brn83n.fsf@intel.com> (raw)
In-Reply-To: <20170526082101.4746-1-wsa@the-dreams.de>

On Fri, 26 May 2017, Wolfram Sang <wsa@the-dreams.de> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Wolfram Sang <wsa@the-dreams.de>, linux-i2c@vger.kernel.org
Cc: Jean Delvare <jdelvare@suse.de>,
	linux-acpi@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/8] i2c: refactor core and break out blocks
Date: Fri, 26 May 2017 14:57:48 +0300	[thread overview]
Message-ID: <8737brn83n.fsf@intel.com> (raw)
In-Reply-To: <20170526082101.4746-1-wsa@the-dreams.de>

On Fri, 26 May 2017, Wolfram Sang <wsa@the-dreams.de> 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

  parent reply	other threads:[~2017-05-26 11:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  8:20 [PATCH 0/8] i2c: refactor core and break out blocks Wolfram Sang
2017-05-26  8:20 ` [PATCH 1/8] i2c: rename core source file to allow refactorization Wolfram Sang
2017-05-26 16:12   ` Mika Westerberg
2017-05-29  9:44   ` Jarkko Nikula
2017-05-26  8:20 ` [PATCH 2/8] i2c: break out slave support into seperate file Wolfram Sang
2017-05-26  8:20 ` [PATCH 3/8] i2c: break out smbus " Wolfram Sang
2017-05-26  8:20 ` [PATCH 4/8] i2c: break out OF " Wolfram Sang
2017-05-26  8:20 ` [PATCH 5/8] i2c: break out ACPI " Wolfram Sang
2017-05-26 16:15   ` Mika Westerberg
2017-05-26 18:30   ` Uwe Kleine-König
2017-05-26  8:20 ` [PATCH 6/8] docs: i2c: dev-interface: adapt to new filenames of the i2c core Wolfram Sang
2017-05-26  8:20 ` [PATCH 7/8] i2c: remove unneeded includes from core Wolfram Sang
2017-05-26  8:20 ` [PATCH 8/8] i2c: reformat core-base file header Wolfram Sang
2017-05-27 11:17   ` Andy Shevchenko
2017-05-31 19:05     ` Wolfram Sang
2017-05-26 11:57 ` Jani Nikula [this message]
2017-05-26 11:57   ` [PATCH 0/8] i2c: refactor core and break out blocks Jani Nikula
2017-05-27 16:32   ` Wolfram Sang
2017-05-31 19:07 ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737brn83n.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jdelvare@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.