All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Florian Echtler <floe@butterbrot.org>,
	Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-input <linux-input@vger.kernel.org>,
	LMML <linux-media@vger.kernel.org>
Subject: Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
Date: Mon, 16 Mar 2015 09:53:16 +0100	[thread overview]
Message-ID: <550699FC.5070906@xs4all.nl> (raw)
In-Reply-To: <55069616.6040202@butterbrot.org>

On 03/16/2015 09:36 AM, Florian Echtler wrote:
> Hello Hans,
> 
> On 15.03.2015 17:26, Hans Verkuil wrote:
>> On 03/12/2015 08:37 PM, Florian Echtler wrote:
>>> On 09.03.2015 15:02, Hans Verkuil wrote:
>>>> On 03/09/2015 02:45 PM, Florian Echtler wrote:
>>>>> On 09.03.2015 11:09, Hans Verkuil wrote:
>>>>>> The error almost certainly comes from usb_submit_urb(). That function does some
>>>>>> checks on the sgl:
>>>>>>
>>>>> I'll do my best to track this down. Do you think this is an error in my
>>>>> code, one in the USB subsystem, or some combination of both?
>>>>
>>>> If the USB core indeed requires scatter-gather segments of specific lengths
>>>> (modulo max), then that explains the problems.
>>>> So as suggested try to see if the usb core bails out in that check and what the
>>>> 'max' value is. It looks like only XHCI allows SG segments of any size, so I really
>>>> suspect that's the problem. But I also need to know the 'max' value to fully
>>>> understand the implications.
>>>
>>> Finally managed to confirm your suspicions on a kernel with a patched
>>> dev_err call at the location you mentioned:
>>>
>>> So the SG segments are expected in multiples of 512 bytes. I assume this
>>> is not something I can fix from within my driver?
>>
>> No, you can't. I would use dma-sg, but disable the USERPTR support.
>> Also comment why USERPTR support is disabled.
>>
>> This was interesting :-)
>>
> Thanks again for your help, new patch is submitted. Just for my
> understanding: is this a hardware limitation?

Yes. Apparently only USB 3 (XHCI) has no restriction on the segment length
in a SG list.

> And why does dma-sg select
> such a weird segment size like 4080?

It's not so much dma-sg as it is the USERPTR support. In USERPTR mode the
application malloc()s memory and when you map that virtual memory block to
a SG list for the underlying physical memory, then you see that malloc does
not align the start of the memory to a page, instead it starts somewhere in
the middle of the page and you end up with a SG descriptor with a 'weird'
length. You can't do anything about that, other than just disabling USERPTR
support.

Regards,

	Hans

      reply	other threads:[~2015-03-16  8:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 15:30 [PATCH v3][RFC] add raw video stream support for Samsung SUR40 Florian Echtler
2015-02-11 11:52 ` Florian Echtler
2015-02-16 11:40   ` Hans Verkuil
2015-02-20 21:46     ` Florian Echtler
2015-02-21 10:22       ` Hans Verkuil
2015-03-06 11:24         ` Florian Echtler
2015-03-06 11:47           ` Hans Verkuil
2015-03-07 19:52             ` Florian Echtler
2015-03-07 20:57               ` Hans Verkuil
2015-03-09  9:49                 ` Florian Echtler
2015-03-09 10:09                   ` Hans Verkuil
2015-03-09 13:45                     ` Florian Echtler
2015-03-09 14:02                       ` Hans Verkuil
2015-03-12 19:37                         ` Florian Echtler
2015-03-15 16:26                           ` Hans Verkuil
2015-03-16  8:36                             ` Florian Echtler
2015-03-16  8:53                               ` Hans Verkuil [this message]

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=550699FC.5070906@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=floe@butterbrot.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.