[U-Boot] [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices

[Vabhav Sharma]

> -----Original Message-----
> From: Wolfgang Denk <wd at denx.de>
> Sent: Friday, October 26, 2018 4:57 PM
> To: Vabhav Sharma <vabhav.sharma at nxp.com>
> Cc: Marek Vasut <marex at denx.de>; u-boot at lists.denx.de; u-boot-
> dm at lists.denx.de; sjg at chromium.org; yamada.masahiro at socionext.com;
> bmeng.cn at gmail.com
> Subject: Re: [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices
> 
> Dear Vabhav,
> 
> In message
> <VI1PR04MB48005B3CB205F14C4670CC2BF3F70 at VI1PR04MB4800.eurprd04.
> prod.outlook.com> you wrote:
> >
> > > U-Boot does lazy initialization intentionally.  It is wrong to
> > > initialize devices which are not actually used.
> 
> > There is configuration option to enable the device using platform data
> > or device tree using DM model.
> 
> "enable" means we have all required information needed to initialize them,
> if we need them.  The need arises only when someone wants to transfer
> data over that UART.  If nobody uses the UArt, there is no need to ever
> initialize it.
On u-boot, only one console is used
There is need to use multiple console for network firmware logging, linux boot
> 
> Lazy initialization is a good thing - it saves resources, especially memory and
> time.  Think for example of boot time optimizations...
I understand
> 
> > For e.g: 2 UART controllers are enabled in device tree but DM model
> > initialized only one, This is limitation
> 
> In which way is this a limitation?  We use only one UART (for the serial
> console), so it works as supposed: only the used devices are fully initialized.
Limitation for aforesaid example
> 
> 
> > My suggestion is to initialize all devices which are enabled, E.g.
> > use case is using UART1 for uboot consoled and UART2 for linux boot
> 
> What do you mean "for Linux boot"?  If Linux needs the UART, it will
> initialize it itself in the Linux dvice driver.
Example is PL011 UART linux driver which expect initialization(integer and fractional baud date) done by bootloader
> 
> > On NXP SoC, We also use UART3 for ethernet firmware logging but using
> > DM model all enabled devices are not probed  posing limitation.
> 
> Again, this is intentional, and not a limitation.
> 
> And what exactly do you mean by "UART3 for ethernet firmware logging"?
Different console than linux boot console.
> 
> Maybe you should rethink your software concept.  We don't want to have a
> zillion of ports in used if not really necessary.  Either you use standard
> channels (STDOUT, STDERR) for logging.  Also, there used to be a syslog
> compatible logging driver.
Agree
> 
> > > I have a feeling that you attempt to do the Wong Thing.
> 
> > I quoted the reason above and also discussed on in email(23 may) "
> > [U-Boot-DM] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller
> > Support" with suggested solution from Simon which is sent as patch for
> > review.
> 
> But Simon also explained "U-Boot only probes things in a 'lazy'
> manner so far", and there should be really good reasons for deviating from
> this principle.  In no way should a "probe all devices" be made the default.
I see.
Not default and config will be selected as required 
Sent patch has config option
> 
> And Andreas also wrote how to solve this issue in a board-specific way if it is
> really, really needed on some board.
> 
> However, you still fail to explain why you ned multiple serial ports in U-Boot
> running in parallel.
I am trying to convince you for the discussed problem faced recently in DM model
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Well, the way I see it, logic is only a way of being ignorant by num-
> bers.                                 - Terry Pratchett, _Small Gods_