On Tue, Nov 8, 2011 at 5:49 PM, Olof Johansson wrote:
> Hi,
>
> On Tue, Nov 8, 2011 at 3:11 PM, Matthew Garrett wrote:
>> On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
>>
>>> How about a DMI table check that overrides whatever is setup (or not
>>> setup) from the video bios? We
Hi,
On Tue, Nov 8, 2011 at 3:11 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
>
>> How about a DMI table check that overrides whatever is setup (or not
>> setup) from the video bios? We know exactly what platforms need this
>> so that table would be
On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
> How about a DMI table check that overrides whatever is setup (or not
> setup) from the video bios? We know exactly what platforms need this
> so that table would be easy to specify.
dmi's horribly unscalable. It's much better to ha
On Tue, Nov 8, 2011 at 2:47 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:41:56PM -0800, Simon Que wrote:
>
>> There is a backup kernel partition that can be used for boot.
>>
>> Failing that, the system can boot from a recovery image over USB.
>
> So absolutely no video code in the firm
On Tue, Nov 08, 2011 at 02:41:56PM -0800, Simon Que wrote:
> There is a backup kernel partition that can be used for boot.
>
> Failing that, the system can boot from a recovery image over USB.
So absolutely no video code in the firmware at all? Ok. What I'd really
rather see here is some generi
On Tue, Nov 8, 2011 at 2:28 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:27:04PM -0800, Simon Que wrote:
>
> > 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.
On Tue, Nov 08, 2011 at 02:27:04PM -0800, Simon Que wrote:
> 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
On Tue, Nov 8, 2011 at 2:10 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:
> > On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett
> wrote:
> >
> > > I feel like I'm missing something here. Where's the firmware getting
> its
> > > initial value from?
> >
> >
On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:
> On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett wrote:
>
> > I feel like I'm missing something here. Where's the firmware getting its
> > initial value from?
>
>
> My understanding is that normally, the firmware's VBIOS can program th
On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett wrote:
> I feel like I'm missing something here. Where's the firmware getting its
> initial value from?
My understanding is that normally, the firmware's VBIOS can program the
value of the PWM register. But if the firmware doesn't have the VBIOS
I feel like I'm missing something here. Where's the firmware getting its
initial value from?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Use 0x1000 as the default backlight PWM max value and period. This is
passed in as a module parameter to i915_drv and is used to program the
PWM registers. It can be set to other values based on the needs of each
system.
Signed-off-by: Simon Que
---
Matthew, this patch has been reworked to bett
12 matches
Mail list logo
