From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: linux-media@vger.kernel.org, Eddi De Pieri <eddi@depieri.net>
Subject: Re: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
Date: Mon, 05 Dec 2011 16:35:45 -0200 [thread overview]
Message-ID: <4EDD0F01.7040808@redhat.com> (raw)
In-Reply-To: <CAGoCfiwv1MWnJc+3HL+9-E=o+HG09jjdGYOfpoXSoPd+wW3oHg@mail.gmail.com>
On 05-12-2011 16:23, Devin Heitmueller wrote:
> On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> diff --git a/drivers/media/common/tuners/xc5000.c b/drivers/media/common/tuners/xc5000.c
>> index ecd1f95..048f489 100644
>> --- a/drivers/media/common/tuners/xc5000.c
>> +++ b/drivers/media/common/tuners/xc5000.c
>> @@ -1004,6 +1004,8 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe)
>> struct xc5000_priv *priv = fe->tuner_priv;
>> int ret = 0;
>>
>> + mutex_lock(&xc5000_list_mutex);
>> +
>> if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
>> ret = xc5000_fwupload(fe);
>> if (ret != XC_RESULT_SUCCESS)
>> @@ -1023,6 +1025,8 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe)
>> /* Default to "CABLE" mode */
>> ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
>>
>> + mutex_unlock(&xc5000_list_mutex);
>> +
>> return ret;
>> }
>
> What's up with this change? Is this a bugfix for some race condition?
> Why is it jammed into a patch for some particular product?
>
> It seems like a change such as this could significantly change the
> timing of tuner initialization if you have multiple xc5000 based
> products that might have a slow i2c bus. Was that intentional?
>
> This patch should be NACK'd and resubmitted as it's own bugfix where
> it's implications can be fully understood in the context of all the
> other products that use xc5000.
It is too late for nacking the patch, as there are several other patches
were already applied on the top of it, and we don't rebase the
linux-media.git tree.
Assuming that this is due to some bug that Eddi picked during xc5000
init, what it can be done now is to write a patch that would replace
this xc5000-global mutex lock into a some other per-device locking
schema.
Regards,
Mauro.
next prev parent reply other threads:[~2011-12-05 18:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-20 14:56 [PATCH 1/8] [media] dvb: Allow select between DVB-C Annex A and Annex C Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 2/8] [media] Properly implement ITU-T J.88 Annex C support Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 3/8] [media] em28xx: Fix some Terratec entries (H5 and XS) Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 4/8] [media] xc5000: Add support for get_if_frequency Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 6/8] [media] em28xx: Fix CodingStyle issues introduced by changeset 82e7dbb Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 7/8] [media] em28xx: Add IR support for em2884 Mauro Carvalho Chehab
2011-11-20 14:56 ` [PATCH 8/8] [media] em28xx: Add IR support for HVR-930C Mauro Carvalho Chehab
2011-12-05 18:23 ` [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again Devin Heitmueller
2011-12-05 18:35 ` Mauro Carvalho Chehab [this message]
2011-12-05 18:46 ` Devin Heitmueller
2011-12-05 20:01 ` Devin Heitmueller
2011-12-05 23:32 ` Eddi De Pieri
2011-12-05 23:47 ` Devin Heitmueller
2011-12-06 12:51 ` Mark Lord
2011-12-06 13:43 ` Mauro Carvalho Chehab
2011-12-06 13:56 ` Devin Heitmueller
2011-12-06 15:28 ` Mark Lord
2011-12-06 15:35 ` Devin Heitmueller
2011-12-06 15:44 ` Mauro Carvalho Chehab
2011-12-07 9:59 ` Mauro Carvalho Chehab
2011-11-20 20:27 ` [PATCH 1/8] [media] dvb: Allow select between DVB-C Annex A and Annex C Rémi Denis-Courmont
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=4EDD0F01.7040808@redhat.com \
--to=mchehab@redhat.com \
--cc=dheitmueller@kernellabs.com \
--cc=eddi@depieri.net \
--cc=linux-media@vger.kernel.org \
/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