Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Arm drivers: are device tree descriptions required for every device?



Julian Coleman <jdc%coris.org.uk@localhost> writes:

> Hi,
>
>> > Specifically for bmx280, we could fail earlier so that we only see one
>> > error line, by adding "goto out" in the error checks, e.g.:
>
>> Ya, that probably wouldn't be a bad thing.  I might be inclined to allow
>> the reset to fail, however, and only exit early if the getting of the
>> device ID fails, which is down just a bit at 436 or so (don't forget to
>> release the bus.... which is probably why I did it the way I did... the
>> attach will not get much further anyway.... and exit early when it tries
>> to read the chip specific parameters... looks like if sysctl set up
>> fails it doesn't release the bus either, which would not be a proper
>> thing to do).
>
> I missed that - reset failed when the sensor was present, so indeed that's
> not a good place to fail.  However, now I'm puzzled that we don't see the
> messages printed by the following reads.  There was only:

I have noticed that some of the data sheets for any and all sensor chips
may not accurately indicate how long a reset can take and/or the chip
temporarily ends up in a strange state for a bit while the reset is
happening that isn't documented (i.e. they lie about how long it takes
or do not indicate at all and/or do not mention that the chip loses its
ever loving mind for a while).  I have tried to account for this
settling time when a chip supports reset, but I very much suspect that
it isn't done perfectly.  This annoyance varies from chip maker to chip
maker and even varies between different chip types by the same maker.
This is mostly why giving up on a reset fail is probably a little too
pessimistic.  It probably should be printed that the reset didn't work,
but should not be a hard fail.  Early failing on reading the ID is
reasonable as that is always suppose to work for this chip.

>> [     1.000000] bmx280thp1 at iic2 addr 0x76
>> [     1.000000] bmx280thp1: autoconfiguration error: Failed to reset chip: 5
>> [     1.000000] bmx280thp1: autoconfiguration error: Unable to setup device
>
> and it looks like we're missing error printouts for "Failed to read ID" and
> "Failed to read the calibration registers for tp".  Does this mean that on
> the Raspberry Pi zero the write failed but the read succeeded for a device
> that wasn't present?  Or maybe this is specific to iic2 only?

Ya, that is odd.  I am a little too busy with other parts of life right
now, but I will set up a test for that and look to see what may be
happening.  It is entirely possible that the read didn't return any
error with no device present.  It certainly would be annoying, but
possible.  It may also be specific to the internal i2c interface (and
hopefully not specific to the model of RPI), and error as expected with
gpioiic, for example.

I have done stuff in the past where I stuff a known value into the
variable I am going to use for the read that isn't something that the
chip can ever return and then if that same value is present after the
read, even with no error, then it is pretty certain that the read did
nothing at all.  This was a problem with SPI on the RPI devices when the
device overlay indicates that the SPI interface is there, but did not
set up the pins.  Any read in that case will return nothing, but also
return no errors.

> Regards,
>
> Julian




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org


Home | Main Index | Thread Index | Old Index