From c8a6b97fa238d4cd79ae90c721c9e77eec05f71c Mon Sep 17 00:00:00 2001 From: Richard Zhu Date: Fri, 1 Aug 2014 19:40:03 +0800 Subject: ENGR00325494 pcie:delay is requried after clks_en - the async reset input need ref clock to sync internally, when the ref clock comes after reset, internal synced reset time is too short , cannot meet the requirement so, ssp_en should be asserted at least 4us after ref clock stable. - align to the community imx pcie driver, add the about 200us delay to make sure that it can allow the pcie clks stabilize, when pcie clks are enabled on imx6q/dl/solo. Signed-off-by: Richard Zhu (cherry picked from commit 5d9635c8d92b21bc12753517fa3e9884417b19be) --- drivers/pci/host/pci-imx6.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index ed991a22020b..1ecc542037f9 100644 --- a/drivers/pci/host/pci-imx6.c +++ b/drivers/pci/host/pci-imx6.c @@ -334,6 +334,9 @@ static int imx6_pcie_deassert_core_reset(struct pcie_port *pp) IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16); } + /* allow the clocks to stabilize */ + usleep_range(200, 500); + if (gpio_is_valid(imx6_pcie->reset_gpio)) { gpio_set_value(imx6_pcie->reset_gpio, 0); mdelay(1); -- cgit v1.2.3 From 789d6703b1372ec59ddf65a7bc87bf28f9186acd Mon Sep 17 00:00:00 2001 From: Xianzhong Date: Fri, 1 Aug 2014 18:44:20 +0800 Subject: ENGR00325794 [#1087] fix video memory mutex sharing issue the root cause is video memory mutex is not global variable, it will cause video memory managment problem with mixed 2D/3D/VG. kernel panic with multiple instances stress test running glesx_viv.sh. Date: Jul 31, 2014 Signed-off-by: Xianzhong Acked-by: Jason Liu (cherry picked from commit 9cec1cbd7ca2378e5c429f57d088d23d73d9c2f3) --- drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c | 4 +--- drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h | 7 +++++++ .../gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h | 2 ++ .../gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c | 19 +++++++++++++++++++ 4 files changed, 29 insertions(+), 3 deletions(-) diff --git a/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c b/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c index d24a08b285b1..9b558ef495c4 100644 --- a/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c +++ b/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c @@ -405,7 +405,7 @@ gckKERNEL_Construct( gcmkONERROR(gckKERNEL_SecurityOpen(kernel, kernel->core, &kernel->securityChannel)); #endif /* Construct a video memory mutex. */ - gcmkONERROR(gckOS_CreateMutex(Os, &kernel->vidmemMutex)); + gcmkONERROR(gckOS_GetVideoMemoryMutex(Os, &kernel->vidmemMutex)); /* Return pointer to the gckKERNEL object. */ *Kernel = kernel; @@ -634,8 +634,6 @@ gckKERNEL_Destroy( gcmkVERIFY_OK(gckKERNEL_SecurityClose(Kernel->securityChannel)); #endif - gcmkVERIFY_OK(gckOS_DeleteMutex(Kernel->os, Kernel->vidmemMutex)); - /* Mark the gckKERNEL object as unknown. */ Kernel->object.type = gcvOBJ_UNKNOWN; diff --git a/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h b/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h index 02d00140f81e..b4743b3e27f5 100644 --- a/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h +++ b/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h @@ -1560,6 +1560,13 @@ gckOS_StopTimer( IN gctPOINTER Timer ); +/* Get the global video memory mutex. */ +gceSTATUS +gckOS_GetVideoMemoryMutex( + IN gckOS Os, + OUT gctPOINTER *Mutex + ); + /******************************************************************************\ ********************************* gckHEAP Object ******************************** \******************************************************************************/ diff --git a/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h b/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h index 88fbf7da5f2c..1dc29a3f7a6d 100644 --- a/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h +++ b/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h @@ -222,6 +222,8 @@ struct _gckOS /* External clock states. */ gctBOOL clockStates[gcdMAX_GPU_COUNT]; + + gctPOINTER vidmemMutex; }; typedef struct _gcsSIGNAL * gcsSIGNAL_PTR; diff --git a/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c b/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c index 9184e9bbd43a..89fe678f89c8 100644 --- a/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c +++ b/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c @@ -917,6 +917,9 @@ gckOS_Construct( gckOS_ImportAllocators(os); + /* Construct a video memory mutex. */ + gcmkONERROR(gckOS_CreateMutex(os, &os->vidmemMutex)); + /* Return pointer to the gckOS object. */ *Os = os; @@ -1029,6 +1032,9 @@ gckOS_Destroy( /* Destroy debug lock mutex. */ gcmkVERIFY_OK(gckOS_DeleteMutex(Os, Os->debugLock)); + /* Destroy video memory mutex. */ + gcmkVERIFY_OK(gckOS_DeleteMutex(Os, Os->vidmemMutex)); + /* Wait for all works done. */ flush_workqueue(Os->workqueue); @@ -9035,3 +9041,16 @@ gckOS_GPUPhysicalToCPUPhysical( return gcvSTATUS_OK; } +gceSTATUS +gckOS_GetVideoMemoryMutex( + IN gckOS Os, + OUT gctPOINTER *Mutex + ) +{ + gcmkHEADER_ARG("Mutex=x%X", Mutex); + + *Mutex = Os->vidmemMutex; + + gcmkFOOTER_NO(); + return gcvSTATUS_OK; +} -- cgit v1.2.3 From ef3bce5feb2ed36c9f4483287454d35ae330dbe3 Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Wed, 6 Aug 2014 13:04:09 +0800 Subject: ENGR00324668 mmc: core: add delay for SD3.0 UHS mode switch We may meet the following errors with a SD3.0 DDR50 cards during reboot test. mmc0: new ultra high speed DDR50 SDHC card at address aaaa mmcblk0: mmc0:aaaa SU08G 7.40 GiB mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00 mmcblk0: retrying using single block read mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 end_request: I/O error, dev mmcblk0, sector 0 ..... Buffer I/O error on device mmcblk0, logical block 0 mmcblk0: unable to read partition table The root cause is still unknown. Since there's an errata of Sandisk eMMC card before that it requires delay for CMD6 for eMMC DDR mode to work stable, we also suspect the SD3.0 DDR requires similar delay. (Still not confirmed by Sandisk) By adding the delay, the overnight reboot test(run 2000+ times) did not show the issue anymore. Originally it can easy show the error after about 20 times of reboot test. So this patch would be the temporary workaround for Sandisk SD3.0 DDR50 mode unstable issue. Signed-off-by: Dong Aisheng --- drivers/mmc/core/sd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index 353b844c2722..398eee195cd3 100644 --- a/drivers/mmc/core/sd.c +++ b/drivers/mmc/core/sd.c @@ -514,6 +514,13 @@ static int sd_set_bus_speed_mode(struct mmc_card *card, u8 *status) else { mmc_set_timing(card->host, timing); mmc_set_clock(card->host, card->sw_caps.uhs_max_dtr); + + /* + * FIXME: Sandisk SD3.0 cards DDR50 mode requires such + * delay to get stable, without this delay we may encounter + * CRC errors after switch to DDR50 mode + */ + mmc_delay(100); } return 0; -- cgit v1.2.3