+linux_pm. Vishwa > -----Original Message----- > From: Govindraj [mailto:govindraj.ti@xxxxxxxxx] > Sent: Tuesday, July 12, 2011 5:14 PM > To: linux-omap@xxxxxxxxxxxxxxx > Cc: Kevin Hilman; Paul Walmsley; Basak, Partha; Tony Lindgren; > Sripathy, Vishwanath; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Rajendra > Nayak; Shilimkar, Santosh > Subject: RFC: Issues using runtime API's with console uart > > Hi All, > > With recent uart runtime conversion I am facing some issues with > runtime > API usage with console. > > With runtime adaptation the clock cutting is done aggressively with > get and put. > > as below with console_write API in uart code. > > serial_omap_console_write(.....) > { > get_sync(); > . > . > . > put(); > } > > serial_omap_set_mctrl(..) > { > get_sync(); > . > . > . > put() > } > > Now if debug messages(pr_debug) from hwmod and omap_device are > enabled > then get_sync and put will internally have prints which get > redirected to > console_write and will call get_sync. > > so from a runtime API context I call another runtime API which leads > to power lock contention, since every runtime API entrant tries to > get > a power lock. > > To elaborate further from above code snippets consider set_mctrl > calling get_sync and printk from omap_hwmod calling console_write > which calls get_sync. > > -> leads to get_sync calling get_sync. > > similarly with put_sync having prints calling console driver calling > get_sync > leading to power_lock contention. > > As of today I don't see any clean approaches to be available. > > Some of the approaches I am considering is > > 1.) let the clock gating for uart be handled with idle path as done > today with > prepare and resume calls. > > 2.) Aggressively binding all get and put with console lock to > suppress > prints from get/put and to printed during console_unlock. > > uart_port_enb(..) > { > if (console_trylock()) { > get_sync(); > console_unlock(); > } > } > > Even this approach doesn't seem fool proof, Similarly if I have > port_disable > console unlock(has not yet released the console lock) > will have a print stating uart clock is disabled will call > console_write > which will call port_enb since above trylock fails and > eventually > might oops out trying > to print the message as put has already disabled the uart > clocks. > > > I don't see any clean method rather using approach[1] as of today. > > So any suggestions on any other approach will be helpful. > > --- > Thanks, > Govindraj.R _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
