From nobody Thu May 20 23:15:33 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CCA26627D35 for ; Thu, 20 May 2021 23:15:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmQZp0Mq8z3td5 for ; Thu, 20 May 2021 23:15:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x736.google.com with SMTP id o27so17993920qkj.9 for ; Thu, 20 May 2021 16:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mXzyOhcuTWhVvZmkYO9dodFjQA2EQVKkwz0zGiTGtDQ=; b=u/MmqJ+6fosRHQl+BUg4jaC7+T6C99uYf8ixx7pVsLT7RFKiXzbezZH2UZL7owyeAV yPytzjHm8xs26tJA9jKXufy54ynamtt7HZp7DaY+JqOnG2RU/pxflu1ZiYMxUxdh9/t7 t8UmwiZhR/Rsm6y2sq1tyEKq11n4eQqS39d7LCAziRego3y5UKYpoetwmpTQURtfMlvU Xde1GaJWUva27tBGzdi9hiGCXx9Dj/we+zAJKjEt+ZaEtsMgzBUUZ03I6nrD3zibDmVZ URl5lRSK31s8pgmRlsPgg3tZvpBOYJ5OX8dezr3lHl6UJyYXPc1U/rApM2S01ppP/wDn 8vIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mXzyOhcuTWhVvZmkYO9dodFjQA2EQVKkwz0zGiTGtDQ=; b=qCPIkbMG9HUJS5MPt2bgMlczUVZpamEjBtBWKLN6aWSjVEdGxt4dkNFjyBzbAEsR8c Z6j+80ODJ6DGCJsUOJBLulZs5nEa3BL9SvPLHrwFWpXQl6CDNAxZ8L6iK40i6ZGOsefN IK8Zmkxxvm4HJMe+ycnNrvCG9ilTsfpbKH1GOFfZGGqHjev7tQwV7+P6n2+dqTXe+Xtr lXeh0h/7rDuk9FoauhUQ6Xt5H3Oc3aFlqm+BFOaWFdbNs99X+147Pe7ZETbwAeosmaJM geKyQdkteSeZvSd5LfpM1vUTja43UmIi3wYq5HT0pQIlGSbc8DWmCVLo2DBo7TwFJLLk 2SQQ== X-Gm-Message-State: AOAM533Y/JTxq7pV8E7I3nUZ/cg8x9qo+O/DWZ4CnslV/x/StmLuql/j w9+edK0YJ2J/eKCwr0z58Xv4EO+ZDsl1dGx8scoJEA== X-Google-Smtp-Source: ABdhPJxoGprtXJVPelQMoMt2a0ztO9hnq1WQgZh6JnxdH5FfbGdZAewrz4Uq1QBYDto698UrBi5IfdtcOth3Z3vQjcU= X-Received: by 2002:a05:620a:a:: with SMTP id j10mr8552692qki.195.1621552545328; Thu, 20 May 2021 16:15:45 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: http://lists.freebsd.org/arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 20 May 2021 17:15:33 -0600 Message-ID: Subject: Re: bcm2835 To: Kamal Prasad , Oleksandr Tymoshenko Cc: Kyle Evans , freebsd-arm Content-Type: multipart/alternative; boundary="00000000000073062d05c2cb1fc6" X-Rspamd-Queue-Id: 4FmQZp0Mq8z3td5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=u/MmqJ+6; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::736) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.80)[-0.799]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::736:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::736:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] --00000000000073062d05c2cb1fc6 Content-Type: text/plain; charset="UTF-8" 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 On Wed, May 19, 2021 at 8:41 AM Kamal R. Prasad wrote: > 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 > > On Wed, May 19, 2021 at 6:50 PM Kyle Evans wrote: > > > > On Wed, May 19, 2021 at 8:12 AM Kamal R. Prasad > wrote: > > > On Wed, May 19, 2021 at 6:08 PM Kyle Evans wrote: > > > > > > > > On Wed, May 19, 2021 at 12:27 AM Kamal R. Prasad > wrote: > > > > > > > > > > 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 > > > > > > 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 > > --00000000000073062d05c2cb1fc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.

<= div>A bit of digging shows this was moved recently by Kyle, but the origina= l 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

On Wed, May 19, 2021 at 8:41 AM Kamal R. Pras= ad <kamalpr@gmail.com> wrote= :
the comment in= dicates 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

On Wed, May 19, 2021 at 6:50 PM Kyle Evans <kevans@freebsd.org> wrote:
>
> On Wed, May 19, 2021 at 8:12 AM Kamal R. Prasad <kamalpr@gmail.com> wrote:
> > On Wed, May 19, 2021 at 6:08 PM Kyle Evans <kevans@freebsd.org> wrote:
> > >
> > > On Wed, May 19, 2021 at 12:27 AM Kamal R. Prasad <kamalpr@gmail.com> w= rote:
> > > >
> > > > 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 rea= lly 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
> >
> > 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<= br> > implementation:
> http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.h#60
> http://bxr.su/FreeBSD/sys/dev/sdhci/sdhci.c#181= 4
>
> My very vague recollection is that the advertised timeout is too low,<= br> > but it's probably an implementation issue.
>
> Thanks,
>
> Kyle Evans

--00000000000073062d05c2cb1fc6--