spi-nor: intel-spi: Don't assume OPMENU0/1 to be programmed by BIOS
At present the driver relies on valid OPMENU0/OPMENU1 register values that are programmed by BIOS to function correctly. However in a real world it's absolutely legitimate for a bootloader to leave these two registers untouched. Intel FSP for Baytrail exactly does like this. When we are booting from any Intel FSP based bootloaders like U-Boot, the driver refuses to work. We can of course program various flash opcodes in the OPMENU0/OPMENU1 registers, and such workaround can be added in either the bootloader codes, or the kernel driver itself. But a graceful solution would be to update the kernel driver to remove such limitation of OPMENU0/1 register dependency. The SPI controller settings are not locked under such configuration. So we can first check the controller locking status, and if it is not locked that means the driver job can be fulfilled by using a chosen OPMENU index to set up the flash opcode every time. While we are here, the missing 'Atomic Cycle Sequence' handling in the SW sequencer codes is also added. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Showing
Please register or sign in to comment