[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-omap
Subject:    Re: [PATCH V2] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4
From:       Tony Lindgren <tony () atomide ! com>
Date:       2015-11-30 22:18:34
Message-ID: 20151130221833.GI23396 () atomide ! com
[Download RAW message or body]

* Nishanth Menon <nm@ti.com> [151022 19:49]:
> On 10/22/2015 08:01 PM, Praneeth wrote:
> > Hi Nishanth,
> > 
> > On 10/22/2015 07:24 PM, Praneeth Bajjuri wrote:
> > > From: "J.D. Schroeder" <jay.schroeder@garmin.com>
> > > 
> > > UART4 low level debug support. This helps in debugging with UART4
> > > serial console output on DRA7 based platforms.
> > > 
> > > Extending the following fix for UART4.
> > > commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
> > > enabled on UART3")
> > > 
> > > For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
> > > On DRA7, UART4 hwmod doesn't have this flag enabled,
> > > failure observed when UART4 is used for low level debugging.
> > > 
> > > Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
> > Replying to your question from V1
> > 
> > we have DRA7 based platforms with UART1/UART3/UART4 for serial console.
> > 
> > 1,3 seems to be already fixed in mainline. Hence sending fix only for 4
> 
> Tony or others can comment. IMHO, 1c7e36bfc3e2 is an excellent example.
> it considered just UART3 as the missing thing. UART1 was already done.
> now, we have UART4, tomorrow, some other board will have UART2, how many
> patch on top of patch do we want to do for the same problem?
> 
> Phytech
> http://phytec.com/site/assets/files/2109/phytec_am57x-som_pb_release.pdf
> is a SOM module (page 2 - UART5,3 go to expansion connector).
> 
> And then you have
> http://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/#diagram
>  
> When we see issues like these that are probably symptoms, we might as
> well try and do as wide a solution as necessary.
> 
> if we stick with the rule that we will only enable DEBUG_LL only for
> those boards that are actually in upstream, then obviously, this patch
> should be dropped.
> 
> I do think, personally, that by introducing changes such as enabling
> DEBUG_LL for all ports, we are making the "evil vendor tree" less
> different from upstream and hence reduce cost of upstreaming - hopefully
> this might help motivate various product folks to actually provide
> upstream support for their products (N900 is still my favourite phone
> which actually works in upstream kernel- thanks to a lot of passionate
> community folks) - we really want to see more of those actual products
> function and be maintained with upstream kernel.

Yeah it's not a nice setup right now.. But I'll apply this anyways as
we're still very much depending on the DEBUG_LL for board bring up.

We should just move to moving CONFIG_SERIAL_EARLYCON with earlycon on
the cmdline or stdout-path = "serial3:115200n8" in the dts chosen.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]