[lkml]   [2011]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch] Increase USBFS Bulk Transfer size
    On Fri, Oct 14, 2011 at 5:42 AM, Markus Rechberger
    <> wrote:
    > On Fri, Oct 14, 2011 at 4:47 AM, Markus Rechberger
    > <> wrote:
    >> On Fri, Oct 14, 2011 at 12:19 AM, James Courtier-Dutton
    >> <> wrote:
    >>> Why don't you try a bulk size of 12032 instead of 24064 and not try 12288 as
    >>> you appear to be doing in the logs. Post the logs for that.
    >> I tried that earlier already of course it fails. If I could pick a
    >> smaller transfer size I would be happy since
    >> the device would work with all 2.6.x kernels out of the box and I
    >> wouldn't have to waste my time with it.
    >> Unfortunately it requires the 24064 bytes.
    >> The more flexible device A which is mentioned here confirms that there
    >> can be some impact on the
    >> bulk transfer size.
    >> However to learn about this it's needed to look at the bottom line of
    >> USB on the physical layer.
    >> And I disagree with Alan Cox it's not about being a crappy device or
    >> not, it's more like about something
    >> that is not well understood here. Most people are familiar with
    >> Software only here and not with the physical
    >> USB bottom Layer, otherwise the fact that the devices can have an
    >> impact on this wouldn't be such a surprise.
    > however to not say that I'm unwilling to do that and that is the
    > reason for not accepting this patch
    > even if the value is exposed to sysfs, it still requires the static
    > value in the kernel. The current value
    > used in the patch is based on what is in the HW specs of device A
    > which has the flexible bulk transfer setting.
    > The inflexible device which uses 24064 bytes works with all other
    > Operating systems by using that value
    > and gives exactly the same results with other transfer sizes than that.

    I didn't check this before the half of it is of course not a multiple
    of 512 so the
    logfile only shows up 11776 of course.

    24064 is the smallest common multiple of 188 and 512.


     \ /
      Last update: 2011-10-14 05:51    [W:0.021 / U:1.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site