On Thu, Oct 25, 2012 at 02:27:24PM -0700, Tom Rini wrote:
- PGP Signed by an unknown key
On 10/25/12 14:19, Allen Martin wrote:
On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
Hi,
On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut marex@denx.de wrote:
Dear Simon Glass,
Hi,
On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin amartin@nvidia.com wrote:
On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > Dear Allen Martin, > > [...] > >> Hi Marek, the change to return value here broke serial >> output on tegra. What I see is that the serial device >> name (s->name) is "eserial0" as set by >> serial_ns16550.c, and the name passed in from the >> stdout environment is "serial" so they don't match and >> it fails. This always used to be ok because the >> return code didn't indicate failure and iomux_doenv() >> would continue on happily, but now it causes >> iomux_doenv() to fail and no printfs() work after >> that. >> >> Not sure what the right fix is, should stdout really be >> set to "eserial0"? It seems "serial" should mean "the >> default serial device" which for the normal case is the >> one and only device. > > Looking at the source, the obvious course of action is to > fix iomux.c .
I've been looking at this call to serial_assign() from iomux.c and I'm not convinced this code does anything meaningful at all. It passes the name of a struct stdio_dev device which serial_assign() then tries to match against the registered struct serial_devices, which will never match.
What I don't understand is the case where you have a board that actually has more than one physical serial port and how the mapping from stdio_dev to serial_device happens.
Also, looking at the code to cmd_nvedit, I think your change also broke "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We always have this on for tegra, so we don't go down this code path, but it looks identical to the code in iomux.c
Sorry if I missed it - what was the resolution here? Should we revert that change?
Definitelly not. We should fix the iomux.c , possibly by flipping the inequation mark as a short term solution.
OK that's fine. Is someone working on a patch?
I'll send out my proposal for a patch. Unfortunately I don't have a board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI
Andrew's recent set of patches for am335x means I do. If I follow correctly, you're describing the case where >1 port for a driver is known, we default to say 0 but want to use 1, via the env?
Yes, exactly. I assume that's what the current calls to serial_assign() were supposed to be doing, but weren't.
-Allen