G'day Rob,
On 28/06/2016 05:10, Karl-Heinz Schneider wrote:
Am Sonntag, den 26.06.2016, 09:05 -0500 schrieb Rob Herring:
On Sun, Jun 26, 2016 at 12:21 AM, Phil Reid <preid@xxxxxxxxxxxxxxxxx> wrote:
*Snip*
+- reg: integer, i2c address of the device. Should be <0xa>.
+
+Optional properties:
+- sbsm,i2c-retry-count: integer, number of retries for trying to read or
write
+ to registers. Default: 1
Seems like a driver setting. Is having a retry in the driver a problem
if the h/w works and never actually needs it?
Similarly the sbs-battery driver specifies the same same retry behaviour.
And is a model for this implementation.
I've found the ltc1760 and sbs batteries to be problematic when
communicating to them.
A lot of drivers (and the associated hardware) don't handle multiple bus
masters well.
The bus arbitation doesn't seem to work correctly.
Retries where the only thing I could do to to get things to work reliably.
Mostly means the driver needs fixing, but in one case the designware core
hardware seemed to be the problem for me.
I'm not questioning the need for a retry. I'm questioning the need to
limit the retries and tune per platform. What would be the issue if
the driver hardcodes the number of retries to 10? This will work for
any h/w that needs 0, 1, 2, ..., or 10 retries. The only issue would
be how long until it errors out.
And yes, I can confirm DW i2c h/w is a POS at least for some versions.
So your suggesting we hardcode the retry value in the driver and not provide a
configuration option in the binding?
My only thought with allowing a dt setitng to customise the value is it allows the
integrator to select how many retires they want to try before failing, which kind of
limits the elapse time until a failure is reported.
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au
3 The Avenue, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid@xxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
