> On 12.05.2016, at 20:15, Eric Anholt <eric@xxxxxxxxxx> wrote: > > kernel@xxxxxxxxxxxxxxxx writes: > >> 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. > > I don't think this is a good solution to the problem you are trying to > work around. You're relying on the fact that this driver gets > successfully probed before a driver that would -EPROBE_DEFER on a > sibling clock, which is not a guarantee. Ah - that is probably the reason why hand_off has not gone in... > > Let's please continue the debugging of clock management on linux-clk. I am just trying to find a solution that works... Still I think that having a driver that claims the clock and register range is good to have - at least this way we can have a peek at what the firmware does set up. -- 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
