On Wed, Nov 12, 2014 at 08:56:34AM +0100, Tomeu Vizoso wrote:
> From: Mikko Perttunen <[email protected]>
> 
> The driver is currently only tested on Tegra124 Jetson TK1, but should
> work with other Tegra124 boards, provided that correct EMC tables are
> provided through the device tree. Older chip models have differing
> timing change sequences, so they are not currently supported.
> 
> Signed-off-by: Mikko Perttunen <[email protected]>
> Signed-off-by: Tomeu Vizoso <[email protected]>
[...]
> diff --git a/drivers/clk/tegra/clk-emc.c b/drivers/clk/tegra/clk-emc.c
> new file mode 100644
> index 0000000..75beacd
> --- /dev/null
> +++ b/drivers/clk/tegra/clk-emc.c
[...]
> +/*
> + * Rounds up unless no higher rate exists, in which case down. This way is
> + * safer since things have EMC rate floors. Also don't touch parent_rate
> + * since we don't want the CCF to play with our parent clocks.
> + */
> +static long emc_round_rate(struct clk_hw *hw, unsigned long rate,
> +                 unsigned long *parent_rate)
> +{
> +     struct tegra_emc *tegra = container_of(hw, struct tegra_emc, hw);
> +     u8 ram_code = tegra_read_ram_code();
> +     struct emc_timing *timing;
> +     int i;
> +
> +     /*
> +      * Returning the original rate will lead to a more sensible error
> +      * message when emc_set_rate fails.
> +      */
> +     if (tegra->num_timings == 0)
> +             return rate;
> +
> +     for (i = 0; i < tegra->num_timings; ++i) {
> +             timing = tegra->timings + i;
> +             if (timing->ram_code != ram_code)
> +                     continue;

Is timing->ram_code != ram_code really something that is allowed?

> +
> +             if (timing->rate >= rate)
> +                     return timing->rate;
> +     }
> +
> +     return tegra->timings[tegra->num_timings - 1].rate;

If tegra->timings has timings for different ram_codes, the last timing
might not be for the requested ram_code.

> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to