Hi Simon,
On Fri, 5 Sep 2014 10:41:54 -0600 Simon Glass sjg@chromium.org wrote:
Do you think we could use driver model instead? We have the serial infrastructure in place and I will likely merge it next week.
It moves the \r\n logic to a higher level.
It also removes the need for all the horrible #define stuff you have here to deal with multiple serial ports.
I am seeing serial_find_console_or_panic() func in drivers/serial/serial-uclass.c
static void serial_find_console_or_panic(void) { int node;
/* Check for a chosen console */ node = fdtdec_get_chosen_node(gd->fdt_blob, "stdout-path"); if (node < 0) node = fdtdec_get_alias_node(gd->fdt_blob, "console"); if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node, &cur_dev)) return;
/* * If the console is not marked to be bound before relocation, bind * it anyway. */ if (node > 0 && !lists_bind_fdt(gd->dm_root, gd->fdt_blob, node, &cur_dev)) { if (!device_probe(cur_dev)) return; cur_dev = NULL; }
It looks like CONFIG_DM_SERIAL depends on CONFIG_OF_CONTROL.
UniPhier SoCs do not support device tree control. Is the driver model serial still available? What will happen if gd->fdt_blob is not set?
Best Regards Masahiro Yamada