Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

[Arnd Bergmann]

On Monday 14 March 2011, Waldemar.Rymarkiewicz@xxxxxxxxx wrote:
> >Oh, I see you simply do
> >
> >       ret = i2c_master_send(client, info->buf, len);
> >       usleep_range(1000, 10000);
> >
> >and assume that the buffer can always be written within a 
> >milisecond, so you just slow down output enough to never have 
> >to worry about it, right?
> >
> >A nicer solution would be to have an interrupt driven output 
> >so you know when the i2c buffers have been flushed.
> 
> Well, I get the idea of interrupt driven output, but as I have
> little linux kernel experience I'm not sure how to implement this. 
> Can you extend you thoughts or if you know piont me a driver which
> uses that concept?

Most serial drivers do this, see drivers/tty/serial for a number
of examples, or drivers/serial on older kernels.

> I'm not sure who should rise an interrupt when data has
> been flushed. I2c core or the chip itself?

That would depend on your hardware. The only important
part is that you make sure you can send out data at any
time. If i2c_master_send() causes accesses to your
buffer after returning, there has to be an i2c method
of making sure that it has completed.

If the usleep_range is trying to synchronize between the
NFC and the I2C chip, you must wait for a notication from
the NFC hardware that it's done.

> What's more, I guess the i2c_master_send  is a synchronous
> call and when it returnes we know it flushed data. Right? 

If i2c_master_send is synchronous, you might not
need the usleep_range() at all. Removing that call
would be entirely reasonable.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/