On Wed, 27 Apr 2011 16:23:00 +0800, "Feng, Boqun" <boqun.f...@intel.com> wrote: > Err...I just send another two patches before read this letter. : ) > > Ironlake and g4x share the same bsd_ring, so they share the same > bsd_ring_put/get_irq functions of the ring. Given this, we can't just > change the function name to g4x_ring_put/get_irq. If we do so, we > need ironlake_ring_put/get_irq, too. > So I just use a if-else in bsd_ring_*_irq to find out the version of the > chipset and do different work. > Is that OK?
That's ok. We are slowly pushing the branches out to the initialisation so that the code paths each generation takes are a little clearer. At the moment, I'm more concerned about making sure our functions are consistently named and prefixed with the chipset they first work with. So we have: intel_ -> general functions, used by all i8xx_ -> gen2 i915_ -> gen3 (915/945) g33_, pineview_ -> gen3 (blk/pnv) # perhaps just g33 as pnv = g33 + mobile? i965_ -> gen4 (brw/crl) g4x_ -> gen4 (egl/ctg) ironlake_, sandybridge_, ivybridge_ -> etc So ironlake can call a g4x function, but never vice versa. [And I'd love to be able to bring the same level of consistency to our register names. Along with making sure that they correspond with public docs.] The current best practice for enablement is then to introduce new functions for new chipsets (copy and paste, then modify) ensure the hardware is working, then reduce until we have the minimal code with no regressions. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
