On 5/2/19 5:46 AM, Ley Foon Tan wrote: > On Tue, Apr 30, 2019 at 5:56 PM Marek Vasut <[email protected]> wrote: >> >> On 4/30/19 9:40 AM, Ley Foon Tan wrote: >> [...] >>>>>>> +static int altera_sdram_probe(struct udevice *dev) >>>>>>> +{ >>>>>>> + int ret; >>>>>>> + struct reset_ctl_bulk resets; >>>>>>> + >>>>>>> + ret = reset_get_bulk(dev, &resets); >>>>>>> + if (ret) { >>>>>>> + dev_err(dev, "Can't get reset: %d\n", ret); >>>>>>> + return -ENODEV; >>>>>>> + } >>>>>>> + reset_deassert_bulk(&resets); >>>>>>> + >>>>>>> + if (sdram_mmr_init_full(dev) != 0) { >>>>>>> + puts("SDRAM init failed.\n"); >>>>>>> + goto failed; >>>>>>> + } >>>>>>> + >>>>>>> + return 0; >>>>>>> + >>>>>>> +failed: >>>>>>> + reset_release_bulk(&resets); >>>>>>> + return -ENODEV; >>>>>>> } >>>>>> Are you missing altera_sdram_remove() , which would assert reset here ? >>>>> Will add it. >>>> >>>> But won't that prevent the DRAM controller from working ? >>> Added assert reset in _remove, SDRAM controller still can work after >>> boot to Uboot. >>> Seem _remove is not called when boot to Uboot. >> >> Look at DM_FLAG_OS_PREPARE > Tested add DM_FLAG_OS_PREPARE flag, but still didn't see it call to _remove(). > > BTW, I think we shouldn't assert SDRAM controller. Otherwise, SDRAM is > not working in next boot stage.
Hence my question above -- "But won't that prevent the DRAM controller from working ?" I think you're right. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
