Hi Wolfram,
On Fri, Mar 27, 2015 at 9:07 PM, Wolfram Sang <[email protected]> wrote:
> On Tue, Mar 17, 2015 at 09:48:15PM +0530, Nava kishore Manne wrote:
>> In slave monitor mode, the I2C interface is set up as a master and
>> continues to attempt a transfer to a particular slave until the
>> slave device responds with an ACK.
>>
>> Added this feature for zero length transfers enable the controller
>> for slave monitor interrupt and get the status. Disable the slave
>> monitor mode feature upon successful handling.
>>
>> Signed-off-by: Nava kishore Manne <[email protected]>
>> Acked-by: Harini Katakam <[email protected]>
>
> I am not sure this is going to work.
>
> How often is this access tried when there is no device? It should be
> tried only once.
Once slave monitor is enabled in the host controller, it retries till there's an
ACK or slave monitor is disabled. The SW wont be involved and need not
be interrupted in this gap. The way this feature works in the controller though,
I'm afraid there's no way to distinguish between no slave/ busy slave.
The out is the software timeout in that case.
Please suggest how to use this feature better.
>
> Those 0byte messages can be read or write, so transferring one bit, one
> could say. I assume this one can only read? (which is not a show-stopper
> but the cases should be handled)
>
Yes, only read is used.
Thanks for the review.
Regards,
Harini
> >> In slave monitor mode, the I2C interface is set up as a master and
> >> continues to attempt a transfer to a particular slave until the
> >> slave device responds with an ACK.
> >>
> >> Added this feature for zero length transfers enable the controller
> >> for slave monitor interrupt and get the status. Disable the slave
> >> monitor mode feature upon successful handling.
> >>
> >> Signed-off-by: Nava kishore Manne <[email protected]>
> >> Acked-by: Harini Katakam <[email protected]>
> >
> > I am not sure this is going to work.
> >
> > How often is this access tried when there is no device? It should be
> > tried only once.
>
> Once slave monitor is enabled in the host controller, it retries till there's an
> ACK or slave monitor is disabled. The SW wont be involved and need not
So, it is kind of flooding the bus until the timeout? That is not a
single zero byte message.
> be interrupted in this gap. The way this feature works in the controller though,
> I'm afraid there's no way to distinguish between no slave/ busy slave.
> The out is the software timeout in that case.
> Please suggest how to use this feature better.
I suggest to not use the feature and accept that this device cannot do
zero byte length messages.
Thanks,
Wolfram
Hi Wolfram,
> -----Original Message-----
> From: Wolfram Sang [mailto:[email protected]]
> Sent: Friday, April 03, 2015 1:59 AM
> To: Harini Katakam
> Cc: Nava kishore Manne; Michal Simek; Soren Brinkmann; linux-arm-
> [email protected]; [email protected]; linux-
> [email protected]; Anirudha Sarangi; Srikanth Vemula; Nava kishore
> Manne
> Subject: Re: [PATCH] i2c: cadence: Handling Slave monitor mode
>
>
> > >> In slave monitor mode, the I2C interface is set up as a master and
> > >> continues to attempt a transfer to a particular slave until the
> > >> slave device responds with an ACK.
> > >>
> > >> Added this feature for zero length transfers enable the controller
> > >> for slave monitor interrupt and get the status. Disable the slave
> > >> monitor mode feature upon successful handling.
> > >>
> > >> Signed-off-by: Nava kishore Manne <[email protected]>
> > >> Acked-by: Harini Katakam <[email protected]>
> > >
> > > I am not sure this is going to work.
> > >
> > > How often is this access tried when there is no device? It should be
> > > tried only once.
> >
> > Once slave monitor is enabled in the host controller, it retries till
> > there's an ACK or slave monitor is disabled. The SW wont be involved
> > and need not
>
> So, it is kind of flooding the bus until the timeout? That is not a single zero
> byte message.
>
It will not flooding the bus until the timeout. Once it fails to access the bus it will be ideal for 15 clock cycles. Master again retrying to access the
Slave immediately after the 15 clock cycles (There is a register in the controller to set the retry value min: 0 cycles, max: 16 cycles).This process will repeat until
The software timeout will happen (1000msec).
Regards,
Navakishore.
> > be interrupted in this gap. The way this feature works in the
> > controller though, I'm afraid there's no way to distinguish between no
> slave/ busy slave.
> > The out is the software timeout in that case.
> > Please suggest how to use this feature better.
>
> I suggest to not use the feature and accept that this device cannot do zero
> byte length messages.
>
> Thanks,
>
> Wolfram
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
> > So, it is kind of flooding the bus until the timeout? That is not a single zero
> > byte message.
> >
> It will not flooding the bus until the timeout. Once it fails to access the bus it will be ideal for 15 clock cycles. Master again retrying to access the
> Slave immediately after the 15 clock cycles (There is a register in the controller to set the retry value min: 0 cycles, max: 16 cycles).This process will repeat until
> The software timeout will happen (1000msec).
Compared to do one access only this is "kind of flooding", no?