On Fri, Sep 27, 2019 at 2:55 AM Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > (dropping folks who're probably not interested...) > > On 26/09/2019 17:12, Adam Ford wrote: > > On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > >> > >> On 25/09/2019 23:51, Adam Ford wrote: > >> > >>>> Has anyone debugged why the hang is happening? > >>> I started to debug this, but I got distracted when I noticed the LCD > >>> did't work at all on modern kernels. I have that fixed now, so I can > >>> go back to investigating this. > > I dont' have the same board, but I was testing with omap3 beagle xm. I > can reproduce rather similar issue, although I don't get a hang but > instead sync lost and underflow flood (which makes the device unusable). > > It looks like a bug in omap clock handling. > > DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes > from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck. > > When the DSS driver sets dss1_alwon_fck_3430es2 rate to 27000000 or > 27870967, which can be created with m4 dividers 32 and 31, it looks like > the divider goes to bypass, or to a very small value. DSS gets a very > high clock rate and breaks down. Is there anything I can do to help troubleshoot this? I could insert a hack that checks if we're omap3 and if so make the divider equal to 4, but that seems like just a hack. I can run more tests or insert code somewhere if you want. adam > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
