On Wed, Oct 28, 2015 at 12:44:30PM -0700, Rodrigo Vivi wrote:
> On Wed, Oct 28, 2015 at 12:31 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Oct 28, 2015 at 04:16:45AM -0700, Rodrigo Vivi wrote:
> >
> >> +static const struct intel_device_info intel_kabylake_info = {
> >> + .is_preliminary = 1,
> >> + .is_kabylake = 1,
> >> + .gen = 9,
> >> + .num_pipes = 3,
> >> + .need_gfx_hws = 1, .has_hotplug = 1,
> >> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> >> + .has_llc = 1,
> >> + .has_ddi = 1,
> >> + .has_fpga_dbg = 1,
> >> + .has_fbc = 1,
> >> + GEN_DEFAULT_PIPEOFFSETS,
> >> + IVB_CURSOR_OFFSETS,
> >> +};
> >> +
> >> +static const struct intel_device_info intel_kabylake_gt3_info = {
> >> + .is_preliminary = 1,
> >> + .is_kabylake = 1,
> >> + .gen = 9,
> >> + .num_pipes = 3,
> >> + .need_gfx_hws = 1, .has_hotplug = 1,
> >> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> >> + .has_llc = 1,
> >> + .has_ddi = 1,
> >> + .has_fpga_dbg = 1,
> >> + .has_fbc = 1,
> >> + GEN_DEFAULT_PIPEOFFSETS,
> >> + IVB_CURSOR_OFFSETS,
> >> +};
> >
> > Let's play spot the difference. Or you could share the base kabylake
> > definitions as a macro and override the different fields.
>
> yeap, just following the style it was already there...
Bah, blame broadwell for not following the trend we established in gen7
to reduce the duplication.
> there are other things here that I don't like as well like has_fbc=1 here and
> HAS_<other_features> as defines...
> I believe we need a re-org on the platform definitions...
Always. We always need to find new ways to consolidate the feature tests
for code paths, just hw never follows a logical trend.
The one major advantage we have for using device_info is that we can and
do dump the capabilities/features.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
