All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Morgan <macromorgan@hotmail.com>
To: Eugen.Hristev@microchip.com
Cc: macroalpha82@gmail.com, u-boot@lists.denx.de, sjg@chromium.org
Subject: Re: [PATCH] w1: w1-gpio: Loosen timings to improve cold boot reliability
Date: Thu, 5 May 2022 10:49:57 -0500	[thread overview]
Message-ID: <SN6PR06MB53429A7976E216D66E4A0487A5C29@SN6PR06MB5342.namprd06.prod.outlook.com> (raw)
In-Reply-To: <df89b694-d16d-a3f6-5266-4728a6552774@microchip.com>

On Tue, Apr 26, 2022 at 06:49:20AM +0000, Eugen.Hristev@microchip.com wrote:
> On 12/9/21 10:27 AM, Eugen Hristev - M18282 wrote:
> > On 11/30/21 5:46 PM, Chris Morgan wrote:
> >> On Mon, Nov 22, 2021 at 11:16:22AM +0000, Eugen.Hristev@microchip.com wrote:
> >>> On 11/8/21 5:07 PM, Chris Morgan wrote:
> >>>> From: Chris Morgan <macromorgan@hotmail.com>
> >>>>
> >>>> On my NTC CHIP whenever I do a cold boot any attached DIPs cannot be
> >>>> found. Rebooting on the other hand appears to fix the issue. I found
> >>>> that if I modified the timing slightly (but still within spec) the
> >>>> w1 identification on cold boot became far more reliable.
> >>>>
> >>>> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> >>>> ---
> >>>>     drivers/w1/w1-gpio.c | 4 ++--
> >>>>     1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/w1/w1-gpio.c b/drivers/w1/w1-gpio.c
> >>>> index 9346f810ce..5565de2a92 100644
> >>>> --- a/drivers/w1/w1-gpio.c
> >>>> +++ b/drivers/w1/w1-gpio.c
> >>>> @@ -22,8 +22,8 @@
> >>>>     #define W1_TIMING_E    9
> >>>>     #define W1_TIMING_F    55
> >>>>     #define W1_TIMING_G    0
> >>>> -#define W1_TIMING_H    480
> >>>> -#define W1_TIMING_I    70
> >>>> +#define W1_TIMING_H    600
> >>>> +#define W1_TIMING_I    100
> >>>>     #define W1_TIMING_J    410
> >>>>
> >>>>     struct w1_gpio_pdata {
> >>>> --
> >>>> 2.30.2
> >>>>
> >>>
> >>>
> >>> Hi Chris,
> >>>
> >>> I tested your patch on my board sama5d2_xplained, and it works.
> >>> Thus, you can add my
> >>> Tested-by: Eugen Hristev <eugen.hristev@microchip.com>
> >>>
> >>> However, I disagree with the changes you did in timings. What I found
> >>> was that timing 'H' could go up to 640 , but timing 'I' to a maximum of
> >>> 75 or so. [1]
> >>>
> >>> I am thinking maybe you could also check your udelays with a scope on
> >>> the 1wire line ? Because your problem might be in fact in some other
> >>> part , like udelays not properly aligned/synchronized/accurate at cold
> >>> boot time, depending on the source of clock you are using.
> >>
> >> I lack a scope, but will extensively test 640 and 75 as the new timings.
> >> Would that be acceptable?
> >>
> >> Thank you.
> > 
> > Hi Chris,
> > 
> > The timings should be in spec, however, if your particular SoC has a
> > problem with delays, this should be investigated.
> > 
> > Does your board with with the maximum timings ? (but still in spec)
> 
> 
> Hi Chris,
> 
> I am moving this patch to 'Changes requested' and waiting on your reply 
> about 640 / 75 timings which you said you will test.

I tested. It works better, but still fails some of the time on cold boot
(warm boots always seem to succeed though). For some reason so far I am
only able to get the original timings I submitted to work consistently.

I have tested this on both an NTC CHIP and a prototype Source Parts
Popcorn, both with similar effect (warm boot fine, cold boot
intermittant). Both boards use the same SOC and are tested with the
same DIP (a PocketCHIP).

If this needs to be made board specific to overcome an issue with the
Allwinner R8 let me know and maybe we can figure out a board specific
override.

Thank you.

> 
> Eugen
> 
> > 
> > Eugen
> >>
> >>>
> >>> Eugen
> >>>
> >>>
> >>> [1]
> >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.maximintegrated.com%2Fcontent%2Fdam%2Ffiles%2Fdesign%2Ftools%2Ftech-docs%2F126%2FAN126-timing-calculation.zip&amp;data=05%7C01%7C%7Cb5e9eb5aec71479346f408da2750e636%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637865525660163935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=T6wdIVwoDUy5MDuTIe19giBACfUD5Xfwx5E7JjA0P6A%3D&amp;reserved=0
> > 
> 

      reply	other threads:[~2022-05-05 19:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 15:07 [PATCH] w1: w1-gpio: Loosen timings to improve cold boot reliability Chris Morgan
2021-11-08 16:14 ` Eugen.Hristev
2021-11-22 11:16 ` Eugen.Hristev
2021-11-30 15:46   ` Chris Morgan
2021-12-09  8:27     ` Eugen.Hristev
2022-04-26  6:49       ` Eugen.Hristev
2022-05-05 15:49         ` Chris Morgan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN6PR06MB53429A7976E216D66E4A0487A5C29@SN6PR06MB5342.namprd06.prod.outlook.com \
    --to=macromorgan@hotmail.com \
    --cc=Eugen.Hristev@microchip.com \
    --cc=macroalpha82@gmail.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.