re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm

2014-01-30 Thread matthew green

>> Defer i915drm_attach_framebuffer until interrupts are running.
>> 
>> The i915 code initialization relies on counting hardclock ticks for a
>> delay (ugh).
>> 
>> Not an issue for modules, but it will matter when we build drm2 into
>> the kernel proper.
> 
>not sure why this is a problem generally.  there have been
>defer for interrupts primatives in our kernel for almost
>2 deacdes now.
> 
> Yes, that is exactly what I used:
> 
> -   i915drm_attach_framebuffer(self);
> +   /* Attach a framebuffer, but not until interrupts work.  */
> +   config_interrupts(self, &i915drm_attach_framebuffer);
> 
> What is the problem you're referring to?

i mean your comment about builtin driver.

ah, i see.  you've fixed the problem, now.  good :-)


Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm

2014-01-30 Thread Taylor R Campbell
   Date: Thu, 30 Jan 2014 15:28:00 +1100
   from: matthew green 

   > Defer i915drm_attach_framebuffer until interrupts are running.
   > 
   > The i915 code initialization relies on counting hardclock ticks for a
   > delay (ugh).
   > 
   > Not an issue for modules, but it will matter when we build drm2 into
   > the kernel proper.

   not sure why this is a problem generally.  there have been
   defer for interrupts primatives in our kernel for almost
   2 deacdes now.

Yes, that is exactly what I used:

-   i915drm_attach_framebuffer(self);
+   /* Attach a framebuffer, but not until interrupts work.  */
+   config_interrupts(self, &i915drm_attach_framebuffer);

What is the problem you're referring to?


re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm

2014-01-29 Thread matthew green

> Module Name:  src
> Committed By: riastradh
> Date: Wed Jan 29 19:47:09 UTC 2014
> 
> Modified Files:
>   src/sys/external/bsd/drm2/i915drm [riastradh-drm2]: i915_pci.c
> 
> Log Message:
> Defer i915drm_attach_framebuffer until interrupts are running.
> 
> The i915 code initialization relies on counting hardclock ticks for a
> delay (ugh).
> 
> Not an issue for modules, but it will matter when we build drm2 into
> the kernel proper.

not sure why this is a problem generally.  there have been
defer for interrupts primatives in our kernel for almost
2 deacdes now.


.mrg.