Searched hist:"3 e7914168413f7aa05a68a53ca16e84b14d6851b" (Results 1 – 2 of 2) sorted by relevance
| /rk3399_rockchip-uboot/drivers/spi/ |
| H A D | ich.h | 3e7914168413f7aa05a68a53ca16e84b14d6851b Wed Aug 16 05:38:29 UTC 2017 Bin Meng <bmeng.cn@gmail.com> x86: ich-spi: Don't read cached lock status
At present the ICH SPI controller driver reads the controller lock
status from its register in the probe routine and saves the lock
status to a member of priv. Later the driver uses the cached status
from priv to judge whether the controller setting is locked and do
different setup.
But such logic is only valid when there is only the SPI controller
driver that touches the SPI hardware. In fact the lock status change
can be trigged outside the driver, eg: during the fsp_notify() call
when Intel FSP is used.
This changes the driver to read the lock status every time when an
SPI transfer is initiated instead of reading the cached one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
|
| H A D | ich.c | 3e7914168413f7aa05a68a53ca16e84b14d6851b Wed Aug 16 05:38:29 UTC 2017 Bin Meng <bmeng.cn@gmail.com> x86: ich-spi: Don't read cached lock status
At present the ICH SPI controller driver reads the controller lock
status from its register in the probe routine and saves the lock
status to a member of priv. Later the driver uses the cached status
from priv to judge whether the controller setting is locked and do
different setup.
But such logic is only valid when there is only the SPI controller
driver that touches the SPI hardware. In fact the lock status change
can be trigged outside the driver, eg: during the fsp_notify() call
when Intel FSP is used.
This changes the driver to read the lock status every time when an
SPI transfer is initiated instead of reading the cached one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
|