Hi, > Martin Sperl <kernel@xxxxxxxxxxxxxxxx> hat am 12. Mai 2016 um 17:28 > geschrieben: > > > > > On 12.05.2016, at 16:50, Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > > > Hi Martin, > > > >> kernel@xxxxxxxxxxxxxxxx hat am 12. Mai 2016 um 14:38 geschrieben: > >> > >> > >> From: Martin Sperl <kernel@xxxxxxxxxxxxxxxx> > >> > >> As the sdram clock is a critical clock to the system > >> the minimal bcm2835-sdram driver claims (and enables) > >> this clock and also exposes the corresponding sdram > >> registers via debugfs. > > > > sounds like this driver should fix an clock handling issue. Unfortunately > > this > > isn't a solution in case the driver is disabled. > Unfortunately there is no way around this - the driver has > to be enabled so that the sdram clock or the parent pll, > which typically is plld_core, never gets disabled. > > The only other option would be marking the clock as critical > for those legacy drivers. i would prefer this option. Since this would be more a fix we could get this faster in, it's more clear why we are doing that and less to review. Did i miss a drawback? Stefan > > See also the discussions around the clock register for the > sdram clock, where we have the “normal” clock and some > pll as well - even if the “normal” clock is disabled, > then clearing the sdram register (or the parent) freezes > the system. > > > > > Does the GPU firmware handle the SDRAM controller or is it initialized by > > bootcode? > > > > AFAIK it is enabled in bootcode.bin and - as of now - the firmware > updates refresh cycles when SOC temperatures change. > FW checks every 30 seconds unless there is a key set in config.txt, > which - supposedly - produces a slight impact every 30 seconds to > the system. > > Martin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
