[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce7bc15f-5742-8d1b-4b47-2e8b66d3e5c3@linux.intel.com>
Date: Tue, 7 Aug 2018 17:10:11 +0300
From: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>,
Wolfram Sang <wsa@...-dreams.de>,
James Hogan <jhogan@...nel.org>
Cc: Paul Burton <paul.burton@...s.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Allan Nielsen <allan.nielsen@...rosemi.com>
Subject: Re: [PATCH v3 0/6] Add support for MSCC Ocelot i2c
On 08/06/2018 09:54 PM, Alexandre Belloni wrote:
> Hello,
>
> Because the designware IP was not able to handle the SDA hold time before
> version 1.11a, MSCC has its own implementation. Add support for it and then add
> i2c on ocelot boards.
>
> I would expect patches 1 to 4 to go through the i2c tree and 5-6 through
> the mips tree once patch 4 has been reviewed by the DT maintainers.
>
For the patches 1-4/6 that touch i2c-designware:
Tested-by: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
I tested acpi_match_device() conversion to device_get_match_data()
didn't affect MODEL_CHERRYTRAIL case and quick test that i2c
communication continue working.
Powered by blists - more mailing lists