* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 21:59 [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI Allen Martin
@ 2012-10-25 22:29 ` Marek Vasut
2012-10-25 22:36 ` Tom Rini
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Marek Vasut @ 2012-10-25 22:29 UTC (permalink / raw)
To: u-boot
Dear Allen Martin,
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin <amartin@nvidia.com>
> ---
> common/cmd_nvedit.c | 7 ++++++-
> common/iomux.c | 10 ----------
> doc/driver-model/UDM-serial.txt | 5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval, /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
Drop this, it's default. There's no CONFIG_SERIAL_MULTI in the tree at all
anymore.
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
>
> /*
> * Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
> */
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> - * This was taken from common/cmd_nvedit.c.
> - * This will never work because serial_assign() returns
> - * 1 upon error, not -1.
> - * This would almost always return an error anyway because
> - * serial_assign() expects the name of a serial device, like
> - * serial_smc, but the user generally only wants to set serial.
> - */
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt
> b/doc/driver-model/UDM-serial.txt index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places. It's important to consider current
> implementation of CONFIG_SERIAL_MULTI though. This resides in
> common/serial.c and behaves as a multiplexer for serial ports. This, by
> calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout",
> "stderr" -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of
> the +serial ports is the currently active port. The environmental
> variables +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c
> and manages all console input/output from U-Boot. For serial port, only
> one IOMUX is
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 14+ messages in thread* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 21:59 [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI Allen Martin
2012-10-25 22:29 ` Marek Vasut
@ 2012-10-25 22:36 ` Tom Rini
2012-10-25 22:36 ` Joe Hershberger
2012-10-25 22:43 ` Stephen Warren
3 siblings, 0 replies; 14+ messages in thread
From: Tom Rini @ 2012-10-25 22:36 UTC (permalink / raw)
To: u-boot
On Thu, Oct 25, 2012 at 02:59:50PM -0700, Allen Martin wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin <amartin@nvidia.com>
Two things. First, should I or should I not need to have
CONFIG_CONSOLE_MUX set? If I set it, adding serial=eserial3 to my
default environment switches from eserial0 to eserial3 when we get to
that point in the boot, otherwise I do have to manually setenv serial
eserial3 for anything to happen. And the second thing, I can't get any
output on the other UART, either way. It goes away from eserial0 but
nothing ever shows up to eserial3 (the easiest one here to test).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121025/d17afa93/attachment.pgp>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 21:59 [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI Allen Martin
2012-10-25 22:29 ` Marek Vasut
2012-10-25 22:36 ` Tom Rini
@ 2012-10-25 22:36 ` Joe Hershberger
2012-10-25 22:45 ` Stephen Warren
2012-10-25 22:43 ` Stephen Warren
3 siblings, 1 reply; 14+ messages in thread
From: Joe Hershberger @ 2012-10-25 22:36 UTC (permalink / raw)
To: u-boot
Hi Allen,
On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin <amartin@nvidia.com>
> ---
> common/cmd_nvedit.c | 7 ++++++-
> common/iomux.c | 10 ----------
> doc/driver-model/UDM-serial.txt | 5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char *oldval,
> /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
Changes to this directly conflict with the environment callback series
I sent out RFC (soon be be a real series). Can we hold off on this
until that happens?
> /*
> * Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
> */
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> - * This was taken from common/cmd_nvedit.c.
> - * This will never work because serial_assign() returns
> - * 1 upon error, not -1.
> - * This would almost always return an error anyway because
> - * serial_assign() expects the name of a serial device, like
> - * serial_smc, but the user generally only wants to set serial.
> - */
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
> index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from platform-dependent places.
> It's important to consider current implementation of CONFIG_SERIAL_MULTI though.
> This resides in common/serial.c and behaves as a multiplexer for serial ports.
> This, by calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout", "stderr"
> -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of the
> +serial ports is the currently active port. The environmental variables
> +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c and
> manages all console input/output from U-Boot. For serial port, only one IOMUX is
> --
> 1.7.10.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 14+ messages in thread* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:36 ` Joe Hershberger
@ 2012-10-25 22:45 ` Stephen Warren
2012-10-25 22:47 ` Joe Hershberger
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Warren @ 2012-10-25 22:45 UTC (permalink / raw)
To: u-boot
On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> Hi Allen,
>
> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>> Add a new special environment variable "serial" that allows selection
>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> that were not doing anything.
...
> Changes to this directly conflict with the environment callback series
> I sent out RFC (soon be be a real series). Can we hold off on this
> until that happens?
The problem here is that serial output on Tegra simply doesn't work
(after some point in boot?) without this patch. It seems better to get
everything working before adding new features doesn't it? Otherwise, if
the environment callback stuff (or any other change right now) breaks
something Tegra-specific, there would be no way to identify which change
broke it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:45 ` Stephen Warren
@ 2012-10-25 22:47 ` Joe Hershberger
2012-10-25 22:53 ` Allen Martin
0 siblings, 1 reply; 14+ messages in thread
From: Joe Hershberger @ 2012-10-25 22:47 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/25/2012 04:36 PM, Joe Hershberger wrote:
>> Hi Allen,
>>
>> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>>> Add a new special environment variable "serial" that allows selection
>>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
>>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>>> that were not doing anything.
> ...
>> Changes to this directly conflict with the environment callback series
>> I sent out RFC (soon be be a real series). Can we hold off on this
>> until that happens?
>
> The problem here is that serial output on Tegra simply doesn't work
> (after some point in boot?) without this patch. It seems better to get
> everything working before adding new features doesn't it? Otherwise, if
> the environment callback stuff (or any other change right now) breaks
> something Tegra-specific, there would be no way to identify which change
> broke it.
Fair enough. However I don't think this patch is the right way to fix it.
-Joe
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:47 ` Joe Hershberger
@ 2012-10-25 22:53 ` Allen Martin
2012-10-25 23:18 ` Joe Hershberger
0 siblings, 1 reply; 14+ messages in thread
From: Allen Martin @ 2012-10-25 22:53 UTC (permalink / raw)
To: u-boot
On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
> Hi Stephen,
>
> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> >> Hi Allen,
> >>
> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> >>> Add a new special environment variable "serial" that allows selection
> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >>> that were not doing anything.
> > ...
> >> Changes to this directly conflict with the environment callback series
> >> I sent out RFC (soon be be a real series). Can we hold off on this
> >> until that happens?
> >
> > The problem here is that serial output on Tegra simply doesn't work
> > (after some point in boot?) without this patch. It seems better to get
> > everything working before adding new features doesn't it? Otherwise, if
> > the environment callback stuff (or any other change right now) breaks
> > something Tegra-specific, there would be no way to identify which change
> > broke it.
>
> Fair enough. However I don't think this patch is the right way to fix it.
>
Ok, would removing the existing calls to serial_assign() from iomux.c
and cmd_nvedit.c be an ok first step? They don't appear to do
anything useful right now and that would fix tegra and raspberry pi.
-Allen
--
nvpublic
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:53 ` Allen Martin
@ 2012-10-25 23:18 ` Joe Hershberger
2012-10-25 23:21 ` Allen Martin
0 siblings, 1 reply; 14+ messages in thread
From: Joe Hershberger @ 2012-10-25 23:18 UTC (permalink / raw)
To: u-boot
Hi Allen,
On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin <amartin@nvidia.com> wrote:
> On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
>> Hi Stephen,
>>
>> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
>> >> Hi Allen,
>> >>
>> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>> >>> Add a new special environment variable "serial" that allows selection
>> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
>> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> >>> that were not doing anything.
>> > ...
>> >> Changes to this directly conflict with the environment callback series
>> >> I sent out RFC (soon be be a real series). Can we hold off on this
>> >> until that happens?
>> >
>> > The problem here is that serial output on Tegra simply doesn't work
>> > (after some point in boot?) without this patch. It seems better to get
>> > everything working before adding new features doesn't it? Otherwise, if
>> > the environment callback stuff (or any other change right now) breaks
>> > something Tegra-specific, there would be no way to identify which change
>> > broke it.
>>
>> Fair enough. However I don't think this patch is the right way to fix it.
>>
>
> Ok, would removing the existing calls to serial_assign() from iomux.c
> and cmd_nvedit.c be an ok first step? They don't appear to do
> anything useful right now and that would fix tegra and raspberry pi.
I think that's fine to just remove those 2 calls. Seem like a good
short-term solution.
-Joe
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 23:18 ` Joe Hershberger
@ 2012-10-25 23:21 ` Allen Martin
0 siblings, 0 replies; 14+ messages in thread
From: Allen Martin @ 2012-10-25 23:21 UTC (permalink / raw)
To: u-boot
On Thu, Oct 25, 2012 at 04:18:11PM -0700, Joe Hershberger wrote:
> Hi Allen,
>
> On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin <amartin@nvidia.com> wrote:
> > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
> >> Hi Stephen,
> >>
> >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> >> >> Hi Allen,
> >> >>
> >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> >> >>> Add a new special environment variable "serial" that allows selection
> >> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> >>> that were not doing anything.
> >> > ...
> >> >> Changes to this directly conflict with the environment callback series
> >> >> I sent out RFC (soon be be a real series). Can we hold off on this
> >> >> until that happens?
> >> >
> >> > The problem here is that serial output on Tegra simply doesn't work
> >> > (after some point in boot?) without this patch. It seems better to get
> >> > everything working before adding new features doesn't it? Otherwise, if
> >> > the environment callback stuff (or any other change right now) breaks
> >> > something Tegra-specific, there would be no way to identify which change
> >> > broke it.
> >>
> >> Fair enough. However I don't think this patch is the right way to fix it.
> >>
> >
> > Ok, would removing the existing calls to serial_assign() from iomux.c
> > and cmd_nvedit.c be an ok first step? They don't appear to do
> > anything useful right now and that would fix tegra and raspberry pi.
>
> I think that's fine to just remove those 2 calls. Seem like a good
> short-term solution.
>
Ok, I'll send out a patch for that now, thanks.
-Allen
--
nvpublic
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 21:59 [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI Allen Martin
` (2 preceding siblings ...)
2012-10-25 22:36 ` Joe Hershberger
@ 2012-10-25 22:43 ` Stephen Warren
2012-10-25 22:46 ` Joe Hershberger
3 siblings, 1 reply; 14+ messages in thread
From: Stephen Warren @ 2012-10-25 22:43 UTC (permalink / raw)
To: u-boot
On 10/25/2012 03:59 PM, Allen Martin wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
So I think this requires (for example) the following environment variables:
stdout=serial
serial=eserial0
Is it possible to allow the following instead:
stdout=eserial0
That way, one could presumably set:
stdout=eserial0,eserial3
and hence allow the use of multiple serial consoles?
^ permalink raw reply [flat|nested] 14+ messages in thread* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:43 ` Stephen Warren
@ 2012-10-25 22:46 ` Joe Hershberger
2012-10-25 22:50 ` Allen Martin
0 siblings, 1 reply; 14+ messages in thread
From: Joe Hershberger @ 2012-10-25 22:46 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/25/2012 03:59 PM, Allen Martin wrote:
>> Add a new special environment variable "serial" that allows selection
>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> that were not doing anything.
>
> So I think this requires (for example) the following environment variables:
>
> stdout=serial
> serial=eserial0
>
> Is it possible to allow the following instead:
>
> stdout=eserial0
This is precisely what the patch I had pre-Marek serial did.
> That way, one could presumably set:
>
> stdout=eserial0,eserial3
Though it didn't allow this.
-Joe
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:46 ` Joe Hershberger
@ 2012-10-25 22:50 ` Allen Martin
2012-10-25 23:17 ` Joe Hershberger
0 siblings, 1 reply; 14+ messages in thread
From: Allen Martin @ 2012-10-25 22:50 UTC (permalink / raw)
To: u-boot
On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
> Hi Stephen,
>
> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 10/25/2012 03:59 PM, Allen Martin wrote:
> >> Add a new special environment variable "serial" that allows selection
> >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> that were not doing anything.
> >
> > So I think this requires (for example) the following environment variables:
> >
> > stdout=serial
> > serial=eserial0
> >
> > Is it possible to allow the following instead:
> >
> > stdout=eserial0
>
> This is precisely what the patch I had pre-Marek serial did.
In your patch would "stdout=serial" still work for case where there is
only one serial port? I think it's important to try to preserve that
to no be too disruptive.
>
> > That way, one could presumably set:
> >
> > stdout=eserial0,eserial3
>
> Though it didn't allow this.
>
Shouldn't that be (nearly) transparent through iomux?
-Allen
--
nvpublic
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 22:50 ` Allen Martin
@ 2012-10-25 23:17 ` Joe Hershberger
2012-10-26 10:27 ` Marek Vasut
0 siblings, 1 reply; 14+ messages in thread
From: Joe Hershberger @ 2012-10-25 23:17 UTC (permalink / raw)
To: u-boot
Hi Allen,
On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin <amartin@nvidia.com> wrote:
> On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
>> Hi Stephen,
>>
>> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> > On 10/25/2012 03:59 PM, Allen Martin wrote:
>> >> Add a new special environment variable "serial" that allows selection
>> >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
>> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> >> that were not doing anything.
>> >
>> > So I think this requires (for example) the following environment variables:
>> >
>> > stdout=serial
>> > serial=eserial0
>> >
>> > Is it possible to allow the following instead:
>> >
>> > stdout=eserial0
>>
>> This is precisely what the patch I had pre-Marek serial did.
>
> In your patch would "stdout=serial" still work for case where there is
> only one serial port? I think it's important to try to preserve that
> to no be too disruptive.
It used to support stdout=serial based on not being
CONFIG_SERIAL_MULTI. Now that that's gone, I'm guessing it would
simply be based on only having one registered serial device.
>>
>> > That way, one could presumably set:
>> >
>> > stdout=eserial0,eserial3
>>
>> Though it didn't allow this.
>>
>
> Shouldn't that be (nearly) transparent through iomux?
If that's what iomux does, then sure! I haven't used I/O mux on a
device before.
-Joe
^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
2012-10-25 23:17 ` Joe Hershberger
@ 2012-10-26 10:27 ` Marek Vasut
0 siblings, 0 replies; 14+ messages in thread
From: Marek Vasut @ 2012-10-26 10:27 UTC (permalink / raw)
To: u-boot
Dear Joe Hershberger,
> Hi Allen,
>
> On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin <amartin@nvidia.com> wrote:
> > On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
> >> Hi Stephen,
> >>
> >> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org>
wrote:
> >> > On 10/25/2012 03:59 PM, Allen Martin wrote:
> >> >> Add a new special environment variable "serial" that allows selection
> >> >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> >> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> >> that were not doing anything.
> >> >
> >> > So I think this requires (for example) the following environment
> >> > variables:
> >> >
> >> > stdout=serial
> >> > serial=eserial0
> >> >
> >> > Is it possible to allow the following instead:
> >> >
> >> > stdout=eserial0
> >>
> >> This is precisely what the patch I had pre-Marek serial did.
> >
> > In your patch would "stdout=serial" still work for case where there is
> > only one serial port? I think it's important to try to preserve that
> > to no be too disruptive.
>
> It used to support stdout=serial based on not being
> CONFIG_SERIAL_MULTI. Now that that's gone, I'm guessing it would
> simply be based on only having one registered serial device.
>
> >> > That way, one could presumably set:
> >> >
> >> > stdout=eserial0,eserial3
> >>
> >> Though it didn't allow this.
> >
> > Shouldn't that be (nearly) transparent through iomux?
>
> If that's what iomux does, then sure! I haven't used I/O mux on a
> device before.
This is what we should do, indeed.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 14+ messages in thread