Hi Guennadi,
On Tue, Sep 10, 2013 at 12:55 AM, Guennadi Liakhovetski
<g.liakhovetski@xxxxxx> wrote:
> Using the same clock for all device instances is non-portable and obtaining
> clock references by an ID without using a device pointer is discouraged.
> This is also not needed, because on platforms, where this driver is used,
> suitable clocks are available for the I2C controllers, that are children of
> the peripheral clock and just pass its rate 1-to-1 to controllers. This
> patch switches the driver to obtain references to correct clocks.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@xxxxxxxxx>
> ---
> drivers/i2c/busses/i2c-rcar.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index 7e71cf4..7b986cb 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -227,7 +227,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
> u32 bus_speed,
> struct device *dev)
> {
> - struct clk *clkp = clk_get(NULL, "peripheral_clk");
> + struct clk *clkp = clk_get(dev, NULL);
> u32 scgd, cdf;
> u32 round, ick;
> u32 scl;
I agree that passing struct device to clk_get() is a good idea. Thanks
for spotting this.
What are the run-time dependencies for this patch? Do all affected I2C
controllers have MSTP bits with proper parents already, or will this
patch cause breakage for some SoCs?
Thanks,
/ magnus
--
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
