Re: [PATCH] media: m88ds3103: serialize reset messages in m88ds3103_set_frontend

From: Antti Palosaari <crope@iki.fi>
To: James Hutchinson <jahutchinson99@googlemail.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] media: m88ds3103: serialize reset messages in m88ds3103_set_frontend
Date: Sun, 20 Jan 2019 16:43:08 +0200	[thread overview]
Message-ID: <7b9b8291-4768-80bd-b3b1-c6556801d060@iki.fi> (raw)
In-Reply-To: <1547414027-31928-1-git-send-email-jahutchinson99@googlemail.com>

On 1/13/19 11:13 PM, James Hutchinson wrote:
> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=199323
> 
> Users are experiencing problems with the DVBSky S960/S960C USB devices
> since the following commit:
> 
> 9d659ae: ("locking/mutex: Add lock handoff to avoid starvation")
> 
> The device malfunctions after running for an indeterminable period of
> time, and the problem can only be cleared by rebooting the machine.
> 
> It is possible to encourage the problem to surface by blocking the
> signal to the LNB.
> 
> Further debugging revealed the cause of the problem.
> 
> In the following capture:
> - thread #1325 is running m88ds3103_set_frontend
> - thread #42 is running ts2020_stat_work
> 
> a> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 80
>     [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 08
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 3d
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
> b> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 00
>     [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 21
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
>     [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 66
>     [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
>     [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
>     [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
>     [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 60 02 10 0b
>     [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
> 
> Two i2c messages are sent to perform a reset in m88ds3103_set_frontend:
> 
>    a. 0x07, 0x80
>    b. 0x07, 0x00
> 
> However, as shown in the capture, the regmap mutex is being handed over
> to another thread (ts2020_stat_work) in between these two messages.
> 
>>From here, the device responds to every i2c message with an 07 message,
> and will only return to normal operation following a power cycle.
> 
> Use regmap_multi_reg_write to group the two reset messages, ensuring
> both are processed before the regmap mutex is unlocked.

I tried to reproduce that issue with pctv 461e, which has em28xx 
usb-interface, but without success. Even when I added some sleep between 
reset commands and increased tuner statistic polling interval such that 
it polls all the time, it works correctly. Device has tuner is connected 
to demod i2c bus, which I think is same for your device (it calls demod 
i2c mux select for every tuner i2c access).

Taking into account tests I made it is probably issue with usb-interface 
i2c adapter instead - for some reason it stops working and starts 
returning 07 error all the time. Did any other I2C command succeed after 
failure? I mean is there any other i2c client on that bus you could test 
if it fails too on error situation?

All in all, fix should be done to usb-interface i2c adapter if possible 
unless it has proven issue is somewhere else. You could try to add some 
sleep or repeat to i2c adapter in order to see if it helps.

regards
Antti

-- 
http://palosaari.fi/