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
andy.shevchenko@gmail.com wrote:
On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko
andy.shevchenko@gmail.com wrote:
> > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng > > bmeng.cn@gmail.com
wrote:
> > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > andriy.shevchenko@linux.intel.com wrote: > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > This reverts commit
720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > > > Signed-off-by: Andy Shevchenko > > > > andriy.shevchenko@linux.intel.com > > > > --- > > > > drivers/serial/ns16550.c | 40 > > > > ++++++++++++---------------------------- > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > Could you please spend some time to investigate why this > > > breaks Intel
Edison?
> > > > > > Reverting this patch would mean we break other boards > > > too as Wolfgang's patch wanted to fix the breakage in > > > the first place. Much appreciated! > > > > I guess I'm wrong person here. The DM code is a complete > > black box to
me.
> > Nevertheless, I may test any provided fix / debug / etc patch by
request.
> > > > And I think it's fair to investigate by the one who made a > > regression in the first place. > > Given that we have conflicting breakages, we need to debug Edison.
I would glad to test any suggested change or debug patch!
> Does it enable the debug UART?
If I am not mistaken, it does not.
Looks like you are right. If you know the address you could do that
- see minnowmax for an example.
Please suggest what's the best approach to proceed.
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?
1) Fix in the driver (broken by this commit: 82de42fa1468) by moving some code from ofdata_to_platdata() to probe(). 2) Fix the DM core. Simon and Marek were discussing about these 2 options. Perhaps Simon can help shed some light here.
-- With Best Regards, Andy Shevchenko