Resending, since this didn't appear to make its way into in 2.6.36.2.
This patch fixes a regression that breaks analog video and audio on
boards supported by the ivtv, pvrusb2, cx231xx, and cx23885 drivers.
The regression also breaks IR on boards supported by the cx23885
driver.
Regards,
Andy
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: [email protected]
---
drivers/media/video/cx25840/cx25840-core.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c b/drivers/media/video/cx25840/cx25840-core.c
index f5a3e74..b9a2f18 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1991,8 +1991,23 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_new_std(&state->hdl, &cx25840_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
if (!is_cx2583x(state)) {
- default_volume = 228 - cx25840_read(client, 0x8d4);
- default_volume = ((default_volume / 2) + 23) << 9;
+ default_volume = cx25840_read(client, 0x8d4);
+ /*
+ * Enforce the legacy PVR-350/MSP3400 to PVR-150/CX25843 volume
+ * scale mapping limits to avoid -ERANGE errors when
+ * initializing the volume control
+ */
+ if (default_volume > 228) {
+ /* Bottom out at -96 dB, v4l2 vol range 0x2e00-0x2fff */
+ default_volume = 228;
+ cx25840_write(client, 0x8d4, 228);
+ }
+ else if (default_volume < 20) {
+ /* Top out at + 8 dB, v4l2 vol range 0xfe00-0xffff */
+ default_volume = 20;
+ cx25840_write(client, 0x8d4, 20);
+ }
+ default_volume = (((228 - default_volume) >> 1) + 23) << 9;
state->volume = v4l2_ctrl_new_std(&state->hdl,
&cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
On Fri, Dec 10, 2010 at 08:19:57AM -0500, Andy Walls wrote:
> Resending, since this didn't appear to make its way into in 2.6.36.2.
That's because it's not in Linus's tree, right? I have to wait for that
to happen before I can add it to a stable tree.
thanks,
greg k-h
On Fri, 2010-12-10 at 10:16 -0800, Greg KH wrote:
> On Fri, Dec 10, 2010 at 08:19:57AM -0500, Andy Walls wrote:
> > Resending, since this didn't appear to make its way into in 2.6.36.2.
>
> That's because it's not in Linus's tree, right? I have to wait for that
> to happen before I can add it to a stable tree.
Greg,
I wasn't aware of that constraint in the process, but it makes sense to
me.
Mauro,
My understanding is that the patch has to be in one of your trees first,
and then tested in linux-next for a reasonable length of time, before
Linus will pull it into his tree.
Could you please expedite handling of this patch for 2.6.37:
https://patchwork.kernel.org/patch/376612/
so that the regression can be fixed in 2.6.36?
Regards,
Andy
On Fri, Dec 10, 2010 at 02:41:03PM -0500, Andy Walls wrote:
> On Fri, 2010-12-10 at 10:16 -0800, Greg KH wrote:
> > On Fri, Dec 10, 2010 at 08:19:57AM -0500, Andy Walls wrote:
> > > Resending, since this didn't appear to make its way into in 2.6.36.2.
> >
> > That's because it's not in Linus's tree, right? I have to wait for that
> > to happen before I can add it to a stable tree.
>
> Greg,
>
> I wasn't aware of that constraint in the process, but it makes sense to
> me.
Please read Documentation/stable_kernel_rules.txt for what the process
is, and how to get patches into the stable kernel releases.
thanks,
greg k-h