<div class="gmail_quote">On Tue, Nov 8, 2011 at 2:10 PM, Matthew Garrett <span dir="ltr"><<a href="mailto:mjg59@srcf.ucam.org">mjg59@srcf.ucam.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:<br>
> On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett <<a href="mailto:mjg59@srcf.ucam.org">mjg59@srcf.ucam.org</a>> wrote:<br>
><br>
> > I feel like I'm missing something here. Where's the firmware getting its<br>
> > initial value from?<br>
><br>
><br>
> My understanding is that normally, the firmware's VBIOS can program the<br>
> value of the PWM register.  But if the firmware doesn't have the VBIOS<br>
> initialization code, it can still provide an initial value using this new<br>
> param, as part of the kernel command line.  Either way, it's up to the<br>
> person writing or selecting the firmware to decide what initial value to<br>
> provide.<br>
<br>
</div></div>So the firmware doesn't set up graphics itself, it's entirely up to the<br>
kernel? What hardware is this for?<font color="#888888"><br></font></blockquote><div><br></div>This is for an x86-based Chromebook.  Its firmware doesn't have the VBIOS support.  Previously, we had our own backlight driver that also did a similar initialization.  Now, we are trying to move away from that and use the upstream driver instead.  However, we still don't have the firmware support, which is why we have this patch to provide the missing information.<br>
<div> </div></div>