On Fri, Apr 3, 2020 at 10:56 AM Ang, Chee Hong chee.hong.ang@intel.com wrote:
On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong chee.hong.ang@intel.com wrote:
On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong chee.hong.ang@intel.com wrote:
On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote: > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass sjg@chromium.org
wrote:
> > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> > > > > > > This reverts commit
720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
Adding SoCFPGA folks to this thread as the first commit (82de42fa1468) is also breaking platforms there and then their fix for that problem is also causing problems, if I follow right.
Yes. This commit (82de42fa1468) breaks our A10 platform. I did submit similar patch to move some init code from ofdata_to_platdata() to
probe() for our clock driver as well.
Check out the thread here: https://lists.denx.de/pipermail/u-boot/2020-April/405252.html
I see half or less of the messages in the thread by above link. Can you summarize what should have been done in order to fix this?
- Fix in the driver (broken by this commit: 82de42fa1468) by moving some
code from ofdata_to_platdata() to probe().
- Fix the DM core.
Simon and Marek were discussing about these 2 options. Perhaps Simon can help shed some light here.
I have a question. Does revert of 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c makes any difference to SoCFPGA?
This commit: 82de42fa1468 break our SoCFPGA A10 clock driver. This commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c does not affect our SoCFPGA platforms. We just want to know which way to go. Fixing our A10 clock driver or fix the DM core. Seems like this commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c go with option 1 (fixing the driver).
I dunno what 720f9e is actually fixing, it breaks definitely the ordering.
So, I'm going to send a v3 of revert of 720f9e since it is not related to SoCFPGA.