[U-Boot] [PATCH 1/4 v2] serial: Add Zynq serial driver

[Marek Vasut <marex@denx.de>]

Dear Joe Hershberger,

> Hi Marek,
> 
> On Thu, Sep 13, 2012 at 9:01 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Michal Simek,
> > 
> >> On 09/13/2012 02:33 PM, Marek Vasut wrote:
> >> > Dear Michal Simek,
> >> > 
> >> >> On 09/13/2012 11:21 AM, Marek Vasut wrote:
> >> >>> Dear Michal Simek,
> >> >>> 
> >> >>>> The driver is used on Xilinx Zynq platform.
> >> >>>> 
> >> >>>> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> >>>> 
> >> >>>> ---
> >> >>>> v2: Use Zynq name instead of Dragonfire and XPSS/XDFUART
> >> >>>> 
> >> >>>>       Rename driver name
> >> >>>>       Remove driver description
> >> >>>> 
> >> >>>> ---
> >> >>>> 
> >> >>>>    drivers/serial/Makefile      |    1 +
> >> >>>>    drivers/serial/serial_zynq.c |  200
> >> >>>> 
> >> >>>> ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 201
> >> >>>> insertions(+), 0 deletions(-)
> >> >>>> 
> >> >>>>    create mode 100644 drivers/serial/serial_zynq.c
> >> >>> 
> >> >>> [...]
> >> >>> 
> >> >>> It looks ok, but can you make it support CONFIG_SERIAL_MULTI right
> >> >>> away please?
> >> >> 
> >> >> Yes, it will add serial_multi in the next patch.
> >> >> Can you give me your ACK or reviewed-by line? :-)
> >> > 
> >> > Just squash them into one patch please.
> >> 
> >> Done.
> > 
> > Thanks ... my idea is to switch to serial_multi completely, then rework
> > stdio, unify serial on top of it and clean up the whole subsystem.
> > Thanks for helping!
> 
> I have a patch that I'll send soon that moves the "nulldev" driver to
> the serial driver (if CONFIG_SERIAL_MULTI is defined) so that it is
> possible to avoid serial init.

Thanks, this will break my massive patchset though. Can you check 
git://git.denx.de/u-boot-marex.git / stdio branch ? I did something to nulldev 
there. Probably ignore the top 7 patches, they're bogus and need further work. 
It's all still work in progress to some point.

> I had the problem that the serial port
> on my Zynq product lives in the fabric instead of using the hard-core
> ones.

I see ... why don't you implement nulldev_serial instead and leave nulldev stdio 
as is?

> This means that the FPGA neds to be configured first, but since
> I'm using u-boot for that too, I need it to start as null and switch
> to the fabric serial after the FPGA is configured.  Anyway, just more
> support for supporting CONFIG_SERIAL_MULTI.
> 
> -Joe

Best regards,
Marek Vasut