search for: has_calibration

...alibration registers */ > + if (device->chipset == 0xea) > + goto skip_clk_init; I'm concerned that this won't scale in the future. Perhaps a better solution would be to add a "flags" or "features" field to struct nouveau_device along with feature bits such as HAS_CALIBRATION or similar. That way we don't have to touch this code for every new future Tegra chip. Unless perhaps if there's a reason to expect things to change in newer generations. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: applic...

...== 0xea) >>> + goto skip_clk_init; >> >> I'm concerned that this won't scale in the future. Perhaps a better >> solution would be to add a "flags" or "features" field to struct >> nouveau_device along with feature bits such as HAS_CALIBRATION or >> similar. >> >> That way we don't have to touch this code for every new future Tegra >> chip. Unless perhaps if there's a reason to expect things to change in >> newer generations. > I've already handled this in a slightly different way in the tree...

...goto skip_clk_init; >>>> >>>> I'm concerned that this won't scale in the future. Perhaps a better >>>> solution would be to add a "flags" or "features" field to struct >>>> nouveau_device along with feature bits such as HAS_CALIBRATION or >>>> similar. >>>> >>>> That way we don't have to touch this code for every new future Tegra >>>> chip. Unless perhaps if there's a reason to expect things to change in >>>> newer generations. >>> I've already handl...

...(device->chipset == 0xea) >> + goto skip_clk_init; > > I'm concerned that this won't scale in the future. Perhaps a better > solution would be to add a "flags" or "features" field to struct > nouveau_device along with feature bits such as HAS_CALIBRATION or > similar. > > That way we don't have to touch this code for every new future Tegra > chip. Unless perhaps if there's a reason to expect things to change in > newer generations. I've already handled this in a slightly different way in the tree I'd previously pointe...

...;> + goto skip_clk_init; >>> >>> I'm concerned that this won't scale in the future. Perhaps a better >>> solution would be to add a "flags" or "features" field to struct >>> nouveau_device along with feature bits such as HAS_CALIBRATION or >>> similar. >>> >>> That way we don't have to touch this code for every new future Tegra >>> chip. Unless perhaps if there's a reason to expect things to change in >>> newer generations. >> I've already handled this in a slightly di...

...gt;> >>>>> >>>>> I'm concerned that this won't scale in the future. Perhaps a better >>>>> solution would be to add a "flags" or "features" field to struct >>>>> nouveau_device along with feature bits such as HAS_CALIBRATION or >>>>> similar. >>>>> >>>>> That way we don't have to touch this code for every new future Tegra >>>>> chip. Unless perhaps if there's a reason to expect things to change in >>>>> newer generations. >>>&gt...

Hi everyone, Here is the second batch of patches to add GK20A support to Nouveau. This time we are adding the actual chip support, and this series brings the driver to a point where a slightly-tweaked Mesa successfully runs shaders and renders triangles on GBM! Many thanks to Thierry Reding and the people on the #nouveau IRC channel for their help without which we would not have reached this