[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <BF982CDB-28CF-4AB3-BC4B-E1D88F34E72A@martin.sperl.org>
Date: Thu, 12 May 2016 21:46:17 +0200
From: Martin Sperl <kernel@...tin.sperl.org>
To: Eric Anholt <eric@...olt.net>
Cc: Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Stephen Warren <swarren@...dotorg.org>,
Lee Jones <lee@...nel.org>,
Russell King <linux@....linux.org.uk>,
devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] add minimal bcm2835-sdram driver
> On 12.05.2016, at 20:15, Eric Anholt <eric@...olt.net> wrote:
>
> kernel@...tin.sperl.org writes:
>
>> From: Martin Sperl <kernel@...tin.sperl.org>
>>
>> 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.
Powered by blists - more mailing lists