> I'd like to get a few tested-by's on this before this is pushed. We've
> > had quite a bit of fixes this round :( Please test both multi_v7 and
> > mvebu defconfigs.
> >
> > Kevin, I know you're busy with a lot more than us, but if you could
> >
igs.
>
> Kevin, I know you're busy with a lot more than us, but if you could
> confirm that this fixes the bus hangs you reported, that would be great.
I applied this patch on top of next-20140207 and tested this on the
armada-xp openblocks ax3, which is where I was seeing the I2C ti
On 07/02/2014 16:09, Jason Cooper wrote:
> On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
>> Offload can be used only on regular transactions and for 1 to byte
>> transfers. In the other cases we switch back to usual work flow.
>>
>> In this case we need to call mv64xxx_i2c_prepar
On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
> Offload can be used only on regular transactions and for 1 to byte
> transfers. In the other cases we switch back to usual work flow.
>
> In this case we need to call mv64xxx_i2c_prepare_for_io() as this
> function is not used when
On 06/02/2014 11:03, Gregory CLEMENT wrote:
> Hi,
>
> I write this email mainly to let you know that there are some issues
> on i2c on the Armada XP (rev A0 and B0) based boards.
>
> What we observed was that if the i2c driver try to access an address
> where the device is absent, then the bus is
Offload can be used only on regular transactions and for 1 to byte
transfers. In the other cases we switch back to usual work flow.
In this case we need to call mv64xxx_i2c_prepare_for_io() as this
function is not used when we try to use offloading.
This commit adds this missing call when offload
On 07.02.2014 11:17, Wolfram Sang wrote:
On Thu, Feb 06, 2014 at 02:50:51PM +0100, Tomasz Figa wrote:
Also, please use correct addresses of DT ML and Wolfram's e-mail
(fixed in this message).
And please don't use In-Reply-To when sending new versions of patches.
The message threading became ha
On Thu, Feb 06, 2014 at 02:50:51PM +0100, Tomasz Figa wrote:
> Also, please use correct addresses of DT ML and Wolfram's e-mail
> (fixed in this message).
And please don't use In-Reply-To when sending new versions of patches.
The message threading became hard to read here...
signature.asc
Descr
From: Simon Glass
There is a rather odd feature of the exynos i2c controller that if it
is left enabled, it can lock itself up with the clk line held low.
This makes the bus unusable.
Unfortunately, the s3c24xx_i2c_set_master() function does not notice
this, and reports a timeout. From then on t
Hello Wolfram,
Sorry for a replying after really long time.
On 24 January 2013 17:50, Wolfram Sang wrote:
> On Thu, Nov 29, 2012 at 10:35:34AM +0530, Naveen Krishna Chatradhi wrote:
>> From: Simon Glass
>>
>> There is a rather odd feature of the exynos i2c controller that if it
>> is left enabl
From: Vincent Palatin
Avoid adding I2C_CLASS_HWMON and I2C_CLASS_SPD class flags to all
Samsung I2C adapters when the I2C mappings are defined in a device tree.
So the drivers doing an auto-detection by probing busses won't mess-up
sensitive I2C devices or trigger long timeouts on non-functional
11 matches
Mail list logo
