Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

> Am 25.04.2020 um 12:37 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
> 
> 
>> Am 25.04.2020 um 12:29 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
>> 
>> H
>> The things start to get "fixed" when the hdq_isr
>> jumps to 6 indicating
>> 
>> OMAP_HDQ_INT_STATUS_RXCOMPLETE | OMAP_HDQ_INT_STATUS_TXCOMPLETE
>> 
>> So I am getting more inclined to believe that it is
>> not a power management issue but some piggybacked
>> change to how interrupts are handled.
>> Especially hdq_reset_irqstatus.
>> 
>> So I will add a printk to hdq_reset_irqstatus
>> to see what value it had before being reset.
> 
> I now did check the log during boot and there is the
> reverse situation. Initially it works but suddenly
> hdq_isr becomes 6 and then trouble starts.
> 
> So the key problem is that both, the RX and the TX
> interrupts may be set and then, the code resets
> everything to 0 and looses either one.
> 
> I wonder if that is an issue by two processes reading
> hdq in parallel.
> 
> Another question is how independent command-writes + result-reads
> are properly serialized and locked so that they don't overlap?

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...

BR and thanks,
Nikolaus




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux