Message-ID: <CANXPkT5EndLDXLqR070KtiPQX-dmkZcFtBUFHiEtFPRODXvY2g@mail.gmail.com>
Date: Mon, 27 May 2024 22:32:56 +0900
From: YongSu Yoo <yongsuyoo0215@...il.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: mchehab@...nel.org, v4bel@...ori.io, linux-media@...r.kernel.org, 
	linux-kernel@...r.kernel.org, yongsu.yoo@....com
Subject: Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

Dear Dan Carpenter

CA_RESET is a very long process.
CA_RESET usually takes around 1 ~ 2 seconds (It depends on the CICAM
brand, some CICAMs take a long time whereas other CICAMs take less
time.
No matter if it takes a long time or less time, if it occurs two
times, its time will become double.
Imagine how bad it is, if your TV's channel changes time and DC-on
time increases more than 2 ~ 4 seconds.
Most of all, it can cause video blinking or video momentarily garbage.
The Kernel controls CA_RESET operation and CA mw also control the CA_RESET.
If the two operations are overlapped (duplicated), this kind of
problem can occur.
I found these bugs while I developed a DVB TV using Linux Kernel.
By adding this solution, I fixed this bug.

2024년 5월 27일 (월) 오후 7:56, Dan Carpenter <dan.carpenter@...aro.org>님이 작성:
>
> On Fri, Mar 08, 2024 at 12:13:38PM +0000, yongsuyoo0215@...il.com wrote:
> > From: Yongsu yoo <yongsuyoo0215@...il.com>
> >
> > Signed-off-by:Yongsu Yoo <yongsuyoo0215@...il.com>
>
> You've sent several patches that have not recieved any feedback.  Resend
> them all as a patchset.
>
> The Signed-off should go at the bottom.  Run your patches through
> scripts/checkpatch.pl.
>
> >
> > In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> > is called, in a normal case, the state of the thread of the
> > dvb_ca_en50221_thread_state_machine will transit like below order.
> > DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> > DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> > DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> > DVB_CA_SLOTSTATE_RUNNING
> > But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> > Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> > the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> > whereas other states are "transiting" states.
> > The "already stablized" states mean no matter how long time we wait,
> > the state will not be changed.
> > The "transiting" states mean the states whose final state is not yet
> > determined. The state keeps to be changed. Only after some time passes,
> > we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> > or DVB_CA_SLOTSTATE_INVALID.
> > During the "transiting" states, we do not yet know whether the
> > CA_RESET operation, which triggered the "transiting" states, will
> > succeed or fail. For this reason, during the "transiting" states, if
> > another CA_RESET ioctl is called and if this new CA_RESET ioctl
> > operation begins again, it will be meaningless and waste time.
> > For preventing this problem from happening, we make CA_RESET ioctl do
> > nothing and only return EBUSY if the ioctl is called during the
> > "transiting" states.
>
> A lot of the commit messages are confusing.  It seems from looking at
> the patches that you have been testing CA_RESET and fixing the bugs.
> Please talk more about how you are finding these bugs?
>
> In this case the bug is that if you call CA_RESET twice before the
> first reset has completed then it is a waste of time?  How serious is
> this bug for normal users?  How much time are we talking about?
>
> regards,
> dan carpenter
>
>

Powered by blists - more mailing lists