Hi Wolfram, On Mon, Mar 30, 2015 at 09:15:30AM +0900, Simon Horman wrote: > On Fri, Mar 27, 2015 at 02:10:45PM +0100, Wolfram Sang wrote: > > On Sat, Mar 07, 2015 at 11:33:49AM +0100, Wolfram Sang wrote: > > > On Fri, Mar 06, 2015 at 11:05:31PM +0100, Wolfram Sang wrote: > > > > > > > > > I asked Kataoka-san about this and his response was as follows: > > > > > > > > Thanks, Simon! > > > > > > > > > If system(CPU) is busy, the driver can't clear the status register soon > > > > > after kicking start. > > > > > > > > > > If sequence of first start is as follows, there is a problem. > > > > > Because H/W starts by 1. > > > > > But sequence of re-start is as follows, there is no problem. > > > > > Because H/W starts by 2. > > > > > > > > > > 1. Issue START condition by ESG bit of ICMCR register. > > > > > <--- If there is too much time, H/W finish transmitting > > > > > and set status in status register. > > > > > 2. Clear interrupt status (ICMSR). > > > > > 3. Open interrupt mask. > > > > > 4. Wait interrupt. > > > > > <--- If status is cleared, interrupt does not occur. > > > > > > > > I understand. I'll add this explanation to the patch and apply it soon. > > > > > > Sorry, another question came up while applying: > > > > > > How can this interruption happen? The function is called in a > > > spin_lock_irqsave protected area. Is this an RT_PREEMPT related issue? > > > Am I missing something? > > > > Hi, > > > > any news on this one? > > Sorry, I seem to have dropped the ball here. I've (finally) forwarded > your question on to the BSP team. Thanks for your patience, I have a response from the BSP team: rcar_i2c_start(), rcar_i2c_recv() and rcar_i2c_send() are called in a spin_lock_irqsave protected area. Therefore, interruption and preemption doesn't happen in these functions. But I think the driver should work fine even if the CPU is very slow. If above sequence 1 and 2 are slow, and if H/W is fast, there is a problem. Since H/W is kicked by sequence 1 then the driver waits the change of status, sequence 2 should be executed before sequence 1 even if the CPU is fast enough. I think it is a custom of software. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
