[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200429213817.GU37466@atomide.com>
Date: Wed, 29 Apr 2020 14:38:17 -0700
From: Tony Lindgren <tony@...mide.com>
To: "H. Nikolaus Schaller" <hns@...delico.com>
Cc: Andreas Kemnade <andreas@...nade.info>,
Evgeniy Polyakov <zbr@...emap.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>,
Adam Ford <aford173@...il.com>,
"Andrew F . Davis" <afd@...com>, Vignesh R <vigneshr@...com>
Subject: Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime
autosuspend
* H. Nikolaus Schaller <hns@...delico.com> [200429 21:35]:
> I have reworked the way the spinlocks, setting and resetting
> of the hdq_irqstatus bits are done and now it works right from
> start of boot. Without any timeouts or delays.
>
> I am not exactly sure what went wrong, but it seems as if
> the read is already done when the write interrupt status
> bit is processed. Then, the old logic did wipe out both
> bits by hdq_reset_irqstatus() and the read code did timeout
> because it did not notice that the data had already been
> available. This may depend on other system activities so
> that it can explain why other tests didn't reveal it.
>
> omap_hdq_runtime_resume() and omap_hdq_runtime_suspend()
> also behave fine.
>
> Before I can post something I need to clean up my hacks
> and add similar fixes to omap_hdq_break() and omap_w1_triplet()
> where I hope that I don't break those...
OK good to hear you were able to figure out what is
going on here.
Regards,
Tony
Powered by blists - more mailing lists