From: Andreas Kemnade <andreas@kemnade.info>
To: Tony Lindgren <tony@atomide.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>,
Evgeniy Polyakov <zbr@ioremap.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
Adam Ford <aford173@gmail.com>, "Andrew F . Davis" <afd@ti.com>,
Vignesh R <vigneshr@ti.com>
Subject: Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend
Date: Tue, 21 Apr 2020 20:24:59 +0200 [thread overview]
Message-ID: <20200421202459.659ed1bf@aktux> (raw)
In-Reply-To: <20200421182017.GC37466@atomide.com>
On Tue, 21 Apr 2020 11:20:17 -0700
Tony Lindgren <tony@atomide.com> wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [200421 18:14]:
> > > Am 21.04.2020 um 20:02 schrieb Tony Lindgren <tony@atomide.com>:
> > > This is 37xx though, maybe you have 35xx and there's some errata
> > > that we're not handling?
> >
> > No, it is dm3730 on three different units I have tried.
> >
> > > I'm only seeing "2.7. HDQTM/1-Wire® Communication Constraints"
> > > for external pull-up resitor in 34xx errata at [0].
> > >
> > > I wonder if wrong external pull could cause flakyeness after
> > > enabling the hdq module?
> >
> > I have checked and we have 10 kOhm pullup to 1.8 V and a 470 Ohm
> > series resistor.
>
> OK
>
> > > If nothing else helps, you could try to block idle for hdq
> > > module, but I have a feeling that's a workaround for something
> > > else.
> >
> > Well, what helps is reverting the patch and using the old driver
> > (which did work for several years). So I would not assume that
> > there is a hardware influence. It seems to be something the new
> > driver is doing differently.
>
> Well earlier hdq1w.c did not idle, now it does. If you just want
> to keep it enabled like earlier, you can just add something like:
>
> &hdqw1w {
> ti,no-idle;
> };
>
> > I need more time to understand and trace this issue on what it
> > depends... It may depend on the sequence some other modules are
> > loaded and what the user-space (udevd) is doing in the meantime.
>
> Yes would be good to understand what goes wrong here before we
> apply the ti,no-idle as that will block SoC deeper idle states.
>
hmm, he is testing without idling uarts, so I am a bit confused here,
the problem only seems to occur when more things are *active*.
Is something not handled in time.
Regards,
Andreas
next prev parent reply other threads:[~2020-04-21 18:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 0:40 [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend Tony Lindgren
2020-04-16 15:02 ` H. Nikolaus Schaller
2020-04-16 18:46 ` Tony Lindgren
2020-04-16 20:04 ` Andreas Kemnade
2020-04-16 20:33 ` Tony Lindgren
2020-04-17 14:21 ` H. Nikolaus Schaller
2020-04-17 14:22 ` H. Nikolaus Schaller
2020-04-17 14:43 ` Andreas Kemnade
2020-04-17 14:52 ` H. Nikolaus Schaller
2020-04-17 15:07 ` Tony Lindgren
2020-04-17 15:14 ` Tony Lindgren
2020-04-17 15:36 ` Andreas Kemnade
2020-04-17 21:03 ` H. Nikolaus Schaller
2020-04-20 15:08 ` Tony Lindgren
2020-04-20 21:11 ` H. Nikolaus Schaller
2020-04-21 6:53 ` Andreas Kemnade
2020-04-21 18:02 ` Tony Lindgren
2020-04-21 18:13 ` H. Nikolaus Schaller
2020-04-21 18:20 ` Tony Lindgren
2020-04-21 18:24 ` Andreas Kemnade [this message]
2020-04-21 20:40 ` H. Nikolaus Schaller
2020-04-22 10:04 ` Andreas Kemnade
2020-04-22 16:06 ` H. Nikolaus Schaller
[not found] ` <A2AC3E81-49B2-4CF2-A7CF-6075AEB1B72D@goldelico.com>
2020-04-25 10:29 ` H. Nikolaus Schaller
2020-04-25 10:37 ` H. Nikolaus Schaller
2020-04-29 21:34 ` H. Nikolaus Schaller
2020-04-29 21:38 ` Tony Lindgren
2020-05-09 11:47 ` H. Nikolaus Schaller
2020-05-09 13:59 ` Tony Lindgren
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=20200421202459.659ed1bf@aktux \
--to=andreas@kemnade.info \
--cc=afd@ti.com \
--cc=aford173@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hns@goldelico.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
--cc=vigneshr@ti.com \
--cc=zbr@ioremap.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).