85e2d61e49
We currently program userspace-provided gamma and degamma LUT's into our hardware without really checking to see whether they satisfy our hardware's rules. We should try to catch tables that are invalid for our hardware early and reject the atomic transaction. All of our platforms that accept a degamma LUT expect that the entries in the LUT are always flat or increasing, never decreasing. Also, our GLK and ICL platforms only accept degamma tables with r=g=b entries; so we should also add the relevant checks for that in anticipation of degamma support landing for those platforms. v2: - Use new API (single check function with bitmask of tests to apply) - Call helper for our gamma table as well (with no additional tests specified) so that the table size will be validated. v3: - Don't call on the gamma table since the LUT size is already tested at property blob upload and we don't have any additional hardware constraints for that LUT. v4: - Apply equal color channel check on gen10 as well; the bspec has some strange tagging for CNL platforms, but this appears to apply there as well. (Ville) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181218175158.5739-1-matthew.d.roper@intel.com |
||
---|---|---|
Documentation | ||
LICENSES | ||
arch | ||
block | ||
certs | ||
crypto | ||
drivers | ||
firmware | ||
fs | ||
include | ||
init | ||
ipc | ||
kernel | ||
lib | ||
mm | ||
net | ||
samples | ||
scripts | ||
security | ||
sound | ||
tools | ||
usr | ||
virt | ||
.clang-format | ||
.cocciconfig | ||
.get_maintainer.ignore | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
COPYING | ||
CREDITS | ||
Kbuild | ||
Kconfig | ||
MAINTAINERS | ||
Makefile | ||
README |
README
Linux kernel ============ There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. Please read Documentation/admin-guide/README.rst first. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. The formatted documentation can also be read online at: https://www.kernel.org/doc/html/latest/ There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.