From patchwork Fri Apr 18 13:49:34 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Devin Heitmueller X-Patchwork-Id: 4016441 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id AF492BFF02 for ; Fri, 18 Apr 2014 13:49:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CE6D7203AF for ; Fri, 18 Apr 2014 13:49:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CFC6A203AE for ; Fri, 18 Apr 2014 13:49:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751314AbaDRNtg (ORCPT ); Fri, 18 Apr 2014 09:49:36 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:62968 "EHLO mail-qa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbaDRNtf (ORCPT ); Fri, 18 Apr 2014 09:49:35 -0400 Received: by mail-qa0-f44.google.com with SMTP id hw13so1588793qab.31 for ; Fri, 18 Apr 2014 06:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XbxK66pCt9OBWivrVt8Oy4z8+Kd50GV1xT26fprtf/s=; b=HkNJ5crkCIgOKOWF1t70KBVj+u0o9cDpCe/KrF82Xa8S26sLYSUltUJ8+FSViwoqgW N4fiG386YUCjfvRqtynwnFJ9Qc9of0nzJ4AQmrAxmMv3UlAfV7q8QMJaLQQ2wOor5RJO AJtK4576twry7LSnab9JAPXNPUuQnj1O5IpHwrUT6ATW3mQ5UrEZzp7LhX2ETltAsrjz IB34tCbo2DFaO3nPVmiVxMAmZNCxkIot53SbRxUbRQ0ZIx6bd0oheMOp+mL6dsQoQuI8 Jxq6624EaTHACECfhxvRASh0KrQgOe5aDv/+RlFfqaQ2Wb/DhUk6dH2P45wRIgWnrcqG xAjQ== X-Gm-Message-State: ALoCoQm7YfosGyYCWjXgjbO6949B21SAAWN7uWWPosCk4XNNsQuDVzO8ew9ruUMSzaAA0eXF0PDO MIME-Version: 1.0 X-Received: by 10.224.115.68 with SMTP id h4mr20726615qaq.35.1397828974432; Fri, 18 Apr 2014 06:49:34 -0700 (PDT) Received: by 10.140.49.198 with HTTP; Fri, 18 Apr 2014 06:49:34 -0700 (PDT) In-Reply-To: <5351106E.4080700@xs4all.nl> References: <1394454049-12879-1-git-send-email-hverkuil@xs4all.nl> <1394454049-12879-4-git-send-email-hverkuil@xs4all.nl> <20140416192343.30a5a8fc@samsung.com> <534F0553.2000808@xs4all.nl> <20140416231730.6252aae7@samsung.com> <534FA3BF.2010308@xs4all.nl> <20140417101310.0111d236@samsung.com> <5351106E.4080700@xs4all.nl> Date: Fri, 18 Apr 2014 09:49:34 -0400 Message-ID: Subject: Re: [REVIEW PATCH 3/3] saa7134: convert to vb2 From: Devin Heitmueller To: Hans Verkuil Cc: Mauro Carvalho Chehab , Linux Media Mailing List , Hans Verkuil Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > This was a bit confusing following the previous paragraph. I meant to say that the > *saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR. > > A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as > it should, but saa7134 can't as it requires the application to align the pointer > to a page boundary, which is non-standard. It's probably worth mentioning at this point that there's a bug in videobuf2_vmalloc() where it forces the buffer provided by userptr mode to be page aligned. This causes issues if you hand it a buffer that isn't actually page aligned, as it writes to an arbitrary offset into the buffer instead of the start of the buffer you provided. I've had the following patch in my private tree for months, but had been hesitant to submit it since I didn't know if it would effect other implementations. I wasn't sure if USERPTR mode required the buffers to be page aligned and I was violating the spec. Devin From: Devin Heitmueller Date: Fri, 17 May 2013 19:53:02 +0000 (-0400) Subject: Fix alignment bug when using VB2 with userptr mode Fix alignment bug when using VB2 with userptr mode If we pass in a USERPTR buffer that isn't page aligned, the driver will align it (and not tell userland). The result is that the driver thinks the video starts in one place while userland thinks it starts in another. This manifests itself as the video being horizontally shifted and there being garbage from the start of the field up to that point. This problem was seen with both the em28xx and uvc drivers when testing on the Davinci platform (where the buffers allocated are not necessarily page aligned). diff --git a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c index 94efa04..ad7ce7c 100644 --- a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -82,7 +82,7 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr, return NULL; buf->write = write; - offset = vaddr & ~PAGE_MASK; + offset = 0; buf->size = size;