bcm2835

Post by Kamal R. Prasad
hello,
in file
sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
there is a constant
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
can someone tell me why this was introduced and does it correspond to
anything in the datasheet?

Hi,

This was added by gonzo@ back in r242321. It doesn't really correspond
to anything in the datasheet, but before I committed r354560 that
moved it around I did try to remove it and observed that it was still
a problem with either the RPi3 or RPi4.

Thanks,

Kyle Evans

Kamal R. Prasad

2021-05-19 13:12:08 UTC

Hi!

can you tell me more on why removing it was a problem for rpi3 or
rpi4? i am trying to understand the significance of this #define.

thanks
-kamal

Hi,
to anything in the datasheet, but before I committed r354560 that
moved it around I did try to remove it and observed that it was still
a problem with either the RPi3 or RPi4.
Thanks,
Kyle Evans

Kyle Evans

2021-05-19 13:20:16 UTC

Hi,
to anything in the datasheet, but before I committed r354560 that
moved it around I did try to remove it and observed that it was still
a problem with either the RPi3 or RPi4.
Thanks,
Kyle Evans

Hi!
can you tell me more on why removing it was a problem for rpi3 or
rpi4? i am trying to understand the significance of this #define.
thanks
-kamal

You'll find better insight from the comment at its definition and
implementation:
http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.h#60
http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.c#1814

My very vague recollection is that the advertised timeout is too low,
but it's probably an implementation issue.

Thanks,

Kyle Evans

Kamal R. Prasad

2021-05-19 14:40:38 UTC

the comment indicates that timeout value is too low. surely, there
must be some place where the timing constraint is indicated because of
which this quirk was put in. or is it that the datasheet doesn't
require this -but in practice, the timeout needs to be increased? if
someone else has added it -maybe they can tell me.

thanks
-kamal

Hi,
to anything in the datasheet, but before I committed r354560 that
moved it around I did try to remove it and observed that it was still
a problem with either the RPi3 or RPi4.
Thanks,
Kyle Evans

Hi!
can you tell me more on why removing it was a problem for rpi3 or
rpi4? i am trying to understand the significance of this #define.
thanks
-kamal

You'll find better insight from the comment at its definition and
http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.h#60
http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.c#1814
My very vague recollection is that the advertised timeout is too low,
but it's probably an implementation issue.
Thanks,
Kyle Evans

Warner Losh

2021-05-20 23:15:33 UTC

In general, for the RPi stuff, if it isn't in the commit messages, it will
be hard to
know why things were added. The datasheets' completeness and availability
in the past has been spotty, and it's entirely possible the code was written
with an old version that indicated a longer timeout.

A bit of digging shows this was moved recently by Kyle, but the original
dates back
to gonzo@'s original commit in 2012. I've cc'd Oleksandr to see if he can
recall
why that was added...

Warner

Post by Kamal R. Prasad
the comment indicates that timeout value is too low. surely, there
must be some place where the timing constraint is indicated because of
which this quirk was put in. or is it that the datasheet doesn't
require this -but in practice, the timeout needs to be increased? if
someone else has added it -maybe they can tell me.
thanks
-kamal

Post by Kamal R. Prasad
hello,
in file
sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
there is a constant
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
can someone tell me why this was introduced and does it correspond

Post by Kamal R. Prasad
anything in the datasheet?

Hi,

correspond