Russell King - ARM Linux writes:
> On Thu, May 28, 2015 at 05:03:12PM -0700, Eric Anholt wrote:
>> We're currently using a fixed frequency clock specified in the DT, so
>> enabling is a no-op. However, the RPi firmware-based clocks driver
>> can actually disable unused clocks, so when switching
On Thu, May 28, 2015 at 05:03:12PM -0700, Eric Anholt wrote:
> We're currently using a fixed frequency clock specified in the DT, so
> enabling is a no-op. However, the RPi firmware-based clocks driver
> can actually disable unused clocks, so when switching to use it we
> ended up losing our MMC
On Thu, May 28, 2015 at 05:03:12PM -0700, Eric Anholt wrote:
We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op. However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Thu, May 28, 2015 at 05:03:12PM -0700, Eric Anholt wrote:
We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op. However, the RPi firmware-based clocks driver
can actually disable unused clocks, so
We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op. However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC clock once all devices were probed.
Signed-off-by: Eric Anholt
---
We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op. However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC clock once all devices were probed.
Signed-off-by: Eric Anholt
6 matches
Mail list logo