On Thu, Dec 04, 2014 at 03:10:25PM -0800, Srinivas Pandruvada wrote:
> This chip allows some limited number of sensors connected to it as
> slaves, which can be directly accessed by register interface of this
> driver.But the current upstream driver doesn't support such mode.
> To attach such slave
Hi,
On Fri, Dec 5, 2014 at 11:11 AM, rajeev kumar
wrote:
> On Wed, Dec 3, 2014 at 6:05 PM, Harini Katakam wrote:
>> The I2C controller sends a NACK to the slave when transfer size register
>> reaches zero, irrespective of the hold bit. So, in order to handle transfers
>> greater than 252 bytes,
On Wed, Dec 3, 2014 at 6:05 PM, Harini Katakam wrote:
> The I2C controller sends a NACK to the slave when transfer size register
> reaches zero, irrespective of the hold bit. So, in order to handle transfers
> greater than 252 bytes, the transfer size register has to be maintained at a
> value >=
Hi,
On Fri, Dec 5, 2014 at 12:02 AM, Wolfram Sang wrote:
>
>> + /*
>> + * If the device is sending data If there is further
>> + * data to be sent. Calculate the available space
>> + * in FIFO and fill the FIFO with that many bytes.
>> +
Hi,
On Fri, Dec 5, 2014 at 12:04 AM, Wolfram Sang wrote:
>
>> + /*
>> + * This controller does not give completion interrupt after a
>> + * master receive transfer if HOLD bit is set (repeated start),
>> + * resulting in SW timeout. Hence, if a r
v2
Addressed comments from Wolfram
- Added reference of discussion for adding this mode to commit message
to explain the purpose
- Removed static mux variable
- Removed exported interface to add i2c client on the i2c mux
comments by Hartmut
- Unregister iio device if there is a failure
Removed ak
This chip allows some limited number of sensors connected to it as
slaves, which can be directly accessed by register interface of this
driver.But the current upstream driver doesn't support such mode.
To attach such slaves to main processor i2c bus, chip has to be set
up in bypass mode. This chang
On Wed, Dec 03, 2014 at 06:10:46PM +0200, Mika Westerberg wrote:
> On Mon, Dec 01, 2014 at 04:09:33PM -0800, David E. Box wrote:
> > This patch implements an I2C bus sharing mechanism between the host and
> > platform
> > hardware on select Intel BayTrail SoC platforms using the X-Powers AXP288
>
> > New binding should have the "-ns" suffix, right? So, I'd vote to add the
> > suffix to the new bindings and deprecate the ones used in the designware
> > driver: "i2c-scl-rising-time-ns" and "i2c-scl-falling-time-ns"
> >
> > It might be a little more work now, but it will help us in the future
On Wed, Dec 03, 2014 at 06:01:25PM +0200, Mika Westerberg wrote:
> On Mon, Dec 01, 2014 at 04:09:32PM -0800, David E. Box wrote:
> > Adds support for acquiring and releasing a hardware bus lock in the i2c
> > designware core transfer function. This is needed for i2c bus controllers
> > that are sha
On Thu, Dec 04, 2014 at 09:59:11AM +0200, Jarkko Nikula wrote:
> Hi
>
> On 12/02/2014 02:09 AM, David E. Box wrote:
> >Adds support for acquiring and releasing a hardware bus lock in the i2c
> >designware core transfer function. This is needed for i2c bus controllers
> >that are shared with but no
Wolfram,
On Thu, Dec 4, 2014 at 10:40 AM, Wolfram Sang wrote:
>
>> If you don't read all the below, my belief is that we should simply
>> rename the strings in Addy's patch. We should change "rise-ns" to
>> "i2c-scl-rising-time" and "fall-ns" to "i2c-scl-falling-time".
>> Wolfram: can you confir
> If you don't read all the below, my belief is that we should simply
> rename the strings in Addy's patch. We should change "rise-ns" to
> "i2c-scl-rising-time" and "fall-ns" to "i2c-scl-falling-time".
> Wolfram: can you confirm this is OK? I'm voting to leave the "-ns"
> off the end of both to
> + /*
> + * This controller does not give completion interrupt after a
> + * master receive transfer if HOLD bit is set (repeated start),
> + * resulting in SW timeout. Hence, if a receive transfer is
> + * followed by any other tran
> + /*
> + * If the device is sending data If there is further
> + * data to be sent. Calculate the available space
> + * in FIFO and fill the FIFO with that many bytes.
> + */
This comment looks broken. In general, I think there sho
On Wed, Dec 03, 2014 at 06:05:25PM +0530, Harini Katakam wrote:
> From: Vishnu Motghare
>
> Cadence I2C controller has bug wherein it generates invalid read transactions
> after timeout in master receiver mode. This driver does not use the HW
> timeout and this interrupt is disabled but the featu
On Mon, Dec 01, 2014 at 05:34:05PM +0200, Grygorii Strashko wrote:
> This patch changes type of input parameter for .prepare/unprepare_recovery()
> callbacks from struct i2c_bus_recovery_info * to struct i2c_adapter *.
> This allows to simplify implementation of these callbacks and avoid
> type con
On Mon, Dec 01, 2014 at 05:34:03PM +0200, Grygorii Strashko wrote:
> Switch Davinci I2C driver to use platform_get_irq(), because
> it is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ, ..)
> for requesting IRQ resources any more, as they can be not ready yet
> in case of DT-boot.
On Mon, Dec 01, 2014 at 05:34:04PM +0200, Grygorii Strashko wrote:
> According to I2C specification the NACK should be handled as follows:
> "When SDA remains HIGH during this ninth clock pulse, this is defined as the
> Not
> Acknowledge signal. The master can then generate either a STOP condition
* Alexander Kochetkov [141203 06:36]:
> This pacth series intended for fixing problem reported
> by Tony Lindgren here[1]
>
> One of first four patched could fix the problem.
> Last patch provide event trace so I could resolve problem.
> It could be applied using 'git am' or 'patch -p1 ...'
>
>
> None of those methods found anything, so I'm quite confident that there are
> no users left.
Great, thanks!
signature.asc
Description: Digital signature
On 12/04/2014 07:11 PM, Wolfram Sang wrote:
On Sun, Nov 30, 2014 at 05:52:32PM +0100, Lars-Peter Clausen wrote:
There haven't been any I2C driver that use the legacy suspend/resume
callbacks for a while now and new drivers are supposed to use PM ops. So
remove support for legacy suspend/resume f
* Alexander Kochetkov [141202 03:19]:
>
> 01 дек. 2014 г., в 22:58, Tony Lindgren написал(а):
>
> > I think this is a different issue than what I'm seeing.
>
> Hello, Tony!
>
> Thank you for testing!
>
> Could check i2c-omap.c from commit ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4.
> As all my
On Sun, Nov 30, 2014 at 05:52:32PM +0100, Lars-Peter Clausen wrote:
> There haven't been any I2C driver that use the legacy suspend/resume
> callbacks for a while now and new drivers are supposed to use PM ops. So
> remove support for legacy suspend/resume for I2C drivers.
>
> Since there aren't a
On Sun, Nov 30, 2014 at 05:52:31PM +0100, Lars-Peter Clausen wrote:
> New drivers should use PM ops instead of the legacy suspend/resume
> callbacks. Update the I2C device driver guides to reflect this.
>
> Signed-off-by: Lars-Peter Clausen
Applied to for-next, thanks!
signature.asc
Descripti
On Thu, Dec 04, 2014 at 05:20:49PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang
>
> We can simply pass the pointer to the private structure to the irq
> routine instead of passing the platform device and looking up its
> driver_data.
>
> Signed-off-by: Wolfram Sang
Applied to for-next, than
On Thu, Dec 4, 2014 at 5:20 PM, Wolfram Sang wrote:
> We can simply pass the pointer to the private structure to the irq
> routine instead of passing the platform device and looking up its
> driver_data.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
From: Wolfram Sang
We can simply pass the pointer to the private structure to the irq
routine instead of passing the platform device and looking up its
driver_data.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-sh_mobile.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
Hi
On 12/02/2014 02:09 AM, David E. Box wrote:
Adds support for acquiring and releasing a hardware bus lock in the i2c
designware core transfer function. This is needed for i2c bus controllers
that are shared with but not controlled by the kernel.
Signed-off-by: David E. Box
---
drivers/i2c/
29 matches
Mail list logo
