#10137 NORM 1.5-sof: XO-1.5 camera FPS limit inaccurate?

[Zarro Boogs per Child]

#10137: XO-1.5 camera FPS limit inaccurate?
---------------------------------+------------------------------------------
           Reporter:  dsd        |       Owner:  corbet             
               Type:  defect     |      Status:  new                
           Priority:  normal     |   Milestone:  1.5-software-update
          Component:  kernel     |     Version:  not specified      
         Resolution:             |    Keywords:                     
        Next_action:  never set  |    Verified:  0                  
Deployment_affected:             |   Blockedby:                     
           Blocking:             |  
---------------------------------+------------------------------------------

Comment(by cjb):

 Hi Jon,

 Replying to [comment:9 corbet]:
 > I can see why the above would appeal from the single-kernel perspective,
 but it is also likely to be hard to upstream.

 I don't have a particularly strong opinion, but I don't understand why
 this is so -- it is not at all uncommon to have platform-specific quirks
 in a device driver.  Most subsystems are full of them, and using quirks to
 make the kernel work out of the box on as much hardware as possible
 (without requiring userspace intervention) seems to be to be an outright
 goal of the kernel to me.  So, I'd think that this quirk is actively
 *desirable* from the point of view of the kernel community, but I'm
 obviously missing something.  Do you think the issue is the quirk, or the
 way it's expressed?  Is there a more suitable way to express it (e.g. a
 quirk struct with PCI ID and quirks bitfield)?

 > My preference would be the runtime-writeable module parameter; it could
 then be tweaked in the init code.  Failing that, we could do the above,
 but it has a real chance of remaining an OLPC-only patch.  Preference?

 If you still think the dichotomy is as you describe, we'll go ahead with
 the module parameter; even though I'm surprised, I trust your intuition
 more than mine.

 > Or you could just fix the sensor clock on the 1.5 :)

 Just checked into this with hardware folks -- it turns out that their goal
 was for us to use the clock divider the whole time, but we didn't manage
 to communicate that with each other.  The reasoning is that we lost the
 CaFe, which was previously driving the clock, so we used an existing clock
 that was pretty close in order to save the money and power it'd cost to
 add another clock driver, with the understanding that we'd have to use the
 clock divider on the ov7670.  Sorry about the miscommunication.

 > So what is going on here is that the 1.5 is clocking the sensor much
 faster than 1.0 systems do - perhaps faster than the sensor is specced to
 go.

 Richard informs me that we're running it *at* the max spec.  :)  We're
 driving it at 48MHz (from the USB clock), and the suggested value is 24MHz
 (which I think is what we used on XO-1), with a max of 48.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10137#comment:13>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system