Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On 04/13/2015 10:52 PM, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 08:15:29PM +0300, Imre Deak wrote: Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. Yup, I think just supporting the latest one in the driver is what we want. The filename versioning is there so different kernel versions, supporting different interfaces, can all boot with the same userspace, each kernel loading the appropriate firmware. Can we have a symbolic link which can be hardcoded in intel_csr.c and option will be given to user during installing the firmware to create a symbolic link for the firmware wanted to load. Want to avoid version number mentioned in firmware file name as it getting change with latest fixes, bot not any API/inteface changes. Agree as bxt and skl both are gen9 we can name as skl_dmc_gen9.bin for now and discussion is going to finalize the name. Is it ok? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Tue, Apr 14, 2015 at 02:46:56PM +0530, Animesh Manna wrote: On 04/13/2015 10:52 PM, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 08:15:29PM +0300, Imre Deak wrote: Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. Yup, I think just supporting the latest one in the driver is what we want. The filename versioning is there so different kernel versions, supporting different interfaces, can all boot with the same userspace, each kernel loading the appropriate firmware. Can we have a symbolic link which can be hardcoded in intel_csr.c and option will be given to user during installing the firmware to create a symbolic link for the firmware wanted to load. Want to avoid version number mentioned in firmware file name as it getting change with latest fixes, bot not any API/inteface changes. Agree as bxt and skl both are gen9 we can name as skl_dmc_gen9.bin for now and discussion is going to finalize the name. Is it ok? Why would we need a symlink? what would be its name? skl_dmc_gen9.bin does not answer the requirement that we need to encode the API/interface version in the filename. The firmware on 01.org skl_dmc_ver4.bin seems to be what we want. HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, 2015-04-13 at 18:02 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 07:52:54PM +0300, Imre Deak wrote: On Mon, 2015-04-13 at 17:34 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 03:54:02PM +0530, Animesh Manna wrote: diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h new file mode 100644 index 000..c2a5a53 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_csr.h + [...] +#define I915_CSR_SKL i915/dmc_gen9.bin I'm guessing the BXT DMC firwmare will be different from SKL's? Remember that one of the requirements is to be able to have the same OS image boot on both SKL and BXT. That means the firmware names have to be different for SKL and BXT. We probably should have skl in the name here. Also, we need to be able to be able to support Interface versions. Ie. if the firmware interface changes in such a way a different loading code is needed, we need to be able to have both firmware on the disk so both an old kernel and a new kernel can work with the same user space. Right now, the naming scheme of the firmware does have a version on it, hopefully that's this Interface version. Thoughts? Yes, the above file name looks incorrect. dmc_gen9.bin was the name for the firmware image with the old layout. This patchset adds support for the new firmware layout starting from ver 1, while the old layout doesn't need to be supported. In an earlier version of this patch the filename was changed to i915/skl_dmc_ver1.bin not sure why that change got dropped. I think we could just use this latter name. First public firmware is already v4 [1], no idea is the version bumps are actual API/interface changes. Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, Apr 13, 2015 at 08:15:29PM +0300, Imre Deak wrote: Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. Yup, I think just supporting the latest one in the driver is what we want. The filename versioning is there so different kernel versions, supporting different interfaces, can all boot with the same userspace, each kernel loading the appropriate firmware. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna animesh.ma...@intel.com Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_dma.c | 11 +-
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On 04/13/2015 04:33 PM, Imre Deak wrote: On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna animesh.ma...@intel.com Signed-off-by: Imre Deak imre.d...@intel.com ---
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On ma, 2015-04-13 at 18:37 +0530, Animesh Manna wrote: On 04/13/2015 04:33 PM, Imre Deak wrote: On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, 2015-04-13 at 17:34 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 03:54:02PM +0530, Animesh Manna wrote: diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h new file mode 100644 index 000..c2a5a53 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_csr.h + [...] +#define I915_CSR_SKL i915/dmc_gen9.bin I'm guessing the BXT DMC firwmare will be different from SKL's? Remember that one of the requirements is to be able to have the same OS image boot on both SKL and BXT. That means the firmware names have to be different for SKL and BXT. We probably should have skl in the name here. Also, we need to be able to be able to support Interface versions. Ie. if the firmware interface changes in such a way a different loading code is needed, we need to be able to have both firmware on the disk so both an old kernel and a new kernel can work with the same user space. Right now, the naming scheme of the firmware does have a version on it, hopefully that's this Interface version. Thoughts? Yes, the above file name looks incorrect. dmc_gen9.bin was the name for the firmware image with the old layout. This patchset adds support for the new firmware layout starting from ver 1, while the old layout doesn't need to be supported. In an earlier version of this patch the filename was changed to i915/skl_dmc_ver1.bin not sure why that change got dropped. I think we could just use this latter name. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, Apr 13, 2015 at 07:52:54PM +0300, Imre Deak wrote: On Mon, 2015-04-13 at 17:34 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 03:54:02PM +0530, Animesh Manna wrote: diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h new file mode 100644 index 000..c2a5a53 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_csr.h + [...] +#define I915_CSR_SKL i915/dmc_gen9.bin I'm guessing the BXT DMC firwmare will be different from SKL's? Remember that one of the requirements is to be able to have the same OS image boot on both SKL and BXT. That means the firmware names have to be different for SKL and BXT. We probably should have skl in the name here. Also, we need to be able to be able to support Interface versions. Ie. if the firmware interface changes in such a way a different loading code is needed, we need to be able to have both firmware on the disk so both an old kernel and a new kernel can work with the same user space. Right now, the naming scheme of the firmware does have a version on it, hopefully that's this Interface version. Thoughts? Yes, the above file name looks incorrect. dmc_gen9.bin was the name for the firmware image with the old layout. This patchset adds support for the new firmware layout starting from ver 1, while the old layout doesn't need to be supported. In an earlier version of this patch the filename was changed to i915/skl_dmc_ver1.bin not sure why that change got dropped. I think we could just use this latter name. First public firmware is already v4 [1], no idea is the version bumps are actual API/interface changes. -- Damien [1] https://01.org/linuxgraphics/downloads/2015/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, Apr 13, 2015 at 03:54:02PM +0530, Animesh Manna wrote: diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h new file mode 100644 index 000..c2a5a53 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_csr.h + [...] +#define I915_CSR_SKL i915/dmc_gen9.bin I'm guessing the BXT DMC firwmare will be different from SKL's? Remember that one of the requirements is to be able to have the same OS image boot on both SKL and BXT. That means the firmware names have to be different for SKL and BXT. We probably should have skl in the name here. Also, we need to be able to be able to support Interface versions. Ie. if the firmware interface changes in such a way a different loading code is needed, we need to be able to have both firmware on the disk so both an old kernel and a new kernel can work with the same user space. Right now, the naming scheme of the firmware does have a version on it, hopefully that's this Interface version. Thoughts? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
