Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Masahiro, On 20 September 2014 01:18, Masahiro YAMADA yamad...@jp.panasonic.com wrote: Hi Simon, 2014-09-20 1:30 GMT+09:00 Simon Glass s...@chromium.org: 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? Please this patch. http://patchwork.ozlabs.org/patch/390433/ I haven't got to a pull request yet for DM, but will do this in the next few days. Can I postpone the driver-model conversion in the next phase? My first priority is to include the core support of Panasonic SoCs in the 2014.10 release. We do not have a month before that. I do not want to be aggressive now. First, I want the current well-tested code to be upstreamed and see where I stand. And then I can move forward to the next development. (Once I have a stable code in the mainline, I can consult git-bisect whenever something is broken in the future development.) That seems fine to me. It is good to do things in stages. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Simon, 2014-09-20 1:30 GMT+09:00 Simon Glass s...@chromium.org: 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? Please this patch. http://patchwork.ozlabs.org/patch/390433/ I haven't got to a pull request yet for DM, but will do this in the next few days. Can I postpone the driver-model conversion in the next phase? My first priority is to include the core support of Panasonic SoCs in the 2014.10 release. We do not have a month before that. I do not want to be aggressive now. First, I want the current well-tested code to be upstreamed and see where I stand. And then I can move forward to the next development. (Once I have a stable code in the mainline, I can consult git-bisect whenever something is broken in the future development.) -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Simon,
On Fri, 5 Sep 2014 10:41:54 -0600
Simon Glass s...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
HI Masahiro,
On 19 September 2014 06:15, Masahiro Yamada yamad...@jp.panasonic.com
wrote:
Hi Simon,
On Fri, 5 Sep 2014 10:41:54 -0600
Simon Glass s...@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?
Please this patch.
http://patchwork.ozlabs.org/patch/390433/
I haven't got to a pull request yet for DM, but will do this in the next
few days.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Simon, 2014-09-06 1:41 GMT+09:00 Simon Glass s...@chromium.org: Maybe we can move \n - \r\n logic to the upper layer and allow users to enable/disable it with a CONFIG_ option. Do you think we could use driver model instead? We have the serial infrastructure in place and I will likely merge it next week. OK. I haven't checked it yet, but I will 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. Does your board have SPL? If so, does it use serial in SPL? Yes, all the UniPhier boards have SPL support. The serial in SPL is not currently supported, but I am planning to add it in the next phase. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
On Friday, September 05, 2014 at 07:50:19 AM, Masahiro Yamada wrote:
The driver for on-chip UART used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
[...]
Hi!
+static void uniphier_serial_putc(struct uniphier_serial *port, const char
c) +{
+ if (c == '\n')
+ uniphier_serial_putc(port, '\r');
Just curious, but what is the concensus about inserting \r upon \n ? Shouldn't
this be something that the upper layers do consistently ? I recall seeing
this
in some drivers and not seeing this in the others, so I wonder why this is like
so ...
+ while (!(readb(port-lsr) UART_LSR_THRE))
+ ;
+
+ writeb(c, port-thr);
+}
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Marek,
On Fri, 5 Sep 2014 12:35:18 +0200
Marek Vasut ma...@denx.de wrote:
On Friday, September 05, 2014 at 07:50:19 AM, Masahiro Yamada wrote:
The driver for on-chip UART used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
[...]
Hi!
+static void uniphier_serial_putc(struct uniphier_serial *port, const char
c) +{
+ if (c == '\n')
+ uniphier_serial_putc(port, '\r');
Just curious, but what is the concensus about inserting \r upon \n ?
Shouldn't
this be something that the upper layers do consistently ? I recall seeing
this
in some drivers and not seeing this in the others, so I wonder why this is
like
so ...
This converts \n to \r\n.
Without this conversion, CarriageReturn is not provided,
which means the cursor goes to the next line, but
column position does not change.
For example,
printf(Hello\nWorld\n);
will be displayed on (at least my) terminal emulator like this:
Hello
World
With the conversion code, it will be displaye as follows:
Hello
World
Perhaps the behavior might depend on
which therminal emulator you are using.
(also depend on the preference
how LF and CR are handled.)
Maybe we can move \n - \r\n logic
to the upper layer and allow users to enable/disable it
with a CONFIG_ option.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
On Friday, September 05, 2014 at 02:03:38 PM, Masahiro Yamada wrote:
Hi Marek,
On Fri, 5 Sep 2014 12:35:18 +0200
Marek Vasut ma...@denx.de wrote:
On Friday, September 05, 2014 at 07:50:19 AM, Masahiro Yamada wrote:
The driver for on-chip UART used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
[...]
Hi!
+static void uniphier_serial_putc(struct uniphier_serial *port, const
char c) +{
+ if (c == '\n')
+ uniphier_serial_putc(port, '\r');
Just curious, but what is the concensus about inserting \r upon \n ?
Shouldn't this be something that the upper layers do consistently ? I
recall seeing this in some drivers and not seeing this in the others, so
I wonder why this is like so ...
This converts \n to \r\n.
Apologies, you're right. This is what I meant.
Without this conversion, CarriageReturn is not provided,
which means the cursor goes to the next line, but
column position does not change.
For example,
printf(Hello\nWorld\n);
will be displayed on (at least my) terminal emulator like this:
Hello
World
With the conversion code, it will be displaye as follows:
Hello
World
Perhaps the behavior might depend on
which therminal emulator you are using.
(also depend on the preference
how LF and CR are handled.)
I use minicom . You do have a point that it might be it.
Maybe we can move \n - \r\n logic
to the upper layer and allow users to enable/disable it
with a CONFIG_ option.
Either that or make it even run-time configurable, esp. if this depends on the
users' terminal setting.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] serial: add UniPhier serial driver
Hi Masahiro,
On 5 September 2014 06:03, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Marek,
On Fri, 5 Sep 2014 12:35:18 +0200
Marek Vasut ma...@denx.de wrote:
On Friday, September 05, 2014 at 07:50:19 AM, Masahiro Yamada wrote:
The driver for on-chip UART used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
[...]
Hi!
+static void uniphier_serial_putc(struct uniphier_serial *port, const char
c) +{
+ if (c == '\n')
+ uniphier_serial_putc(port, '\r');
Just curious, but what is the concensus about inserting \r upon \n ?
Shouldn't
this be something that the upper layers do consistently ? I recall seeing
this
in some drivers and not seeing this in the others, so I wonder why this is
like
so ...
This converts \n to \r\n.
Without this conversion, CarriageReturn is not provided,
which means the cursor goes to the next line, but
column position does not change.
For example,
printf(Hello\nWorld\n);
will be displayed on (at least my) terminal emulator like this:
Hello
World
With the conversion code, it will be displaye as follows:
Hello
World
Perhaps the behavior might depend on
which therminal emulator you are using.
(also depend on the preference
how LF and CR are handled.)
Maybe we can move \n - \r\n logic
to the upper layer and allow users to enable/disable it
with a CONFIG_ option.
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.
Does your board have SPL? If so, does it use serial in SPL?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
