cx25840: Prevent device probe failure due to volume control ERANGE error]

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.

---
 drivers/media/video/cx25840/cx25840-core.c |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

index f5a3e74..b9a2f18 100644
@@ -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,

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

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

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