Thread (16 messages) read the whole thread 16 messages, 5 authors, 2013-10-23
STALE4665d

Revision v1 of 23 in this series.

Revisions (23)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 [diff vs current]
  7. v1 [diff vs current]
  8. v1 [diff vs current]
  9. v1 current
  10. v1 [diff vs current]
  11. v4 [diff vs current]
  12. v4 [diff vs current]
  13. v4 [diff vs current]
  14. v4 [diff vs current]
  15. v4 [diff vs current]
  16. v4 [diff vs current]
  17. v4 [diff vs current]
  18. v4 [diff vs current]
  19. v5 [diff vs current]
  20. v4 [diff vs current]
  21. v5 [diff vs current]
  22. v5 [diff vs current]
  23. v5 [diff vs current]

[PATCH 1/4] cpufreq: Add a cpufreq driver for Marvell Dove

From: andrew@lunn.ch (Andrew Lunn)
Date: 2013-10-22 15:57:58
Also in: linux-pm

Hi Viresh

Thanks for your comments. I will include them in the next version.
quoted
+static irqreturn_t dove_cpufreq_irq(int irq, void *dev)
+{
+       return IRQ_HANDLED;
+}
what is this for?
The hardware raises an interrupt when the change is complete. This
interrupt is what brings the CPU out of the WFI. I don't know the
interrupt code too well, but i think it is necessary for the driver to
acknowledged it. The interrupt core code counts interrupts which
nobody acknowledges, and after 1000 are received, it disables the
interrupt. That would probably result in the machine locking solid,
never coming out of the WFI. So i'm playing it safe and handling the
interrupt.
quoted
+static int dove_cpufreq_probe(struct platform_device *pdev)
+{
+       struct device_node *np;
+       struct resource *res;
+       int err;
+       int irq;
Above two can be merged.
Well, i was told the exact opposite by the USB serial maintainer :-) 
I will use your coding style here, and his for USB code, and try to
keep everybody happy.

 
quoted
+       priv.dev = &pdev->dev;
+
+       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+       priv.dfs = devm_ioremap_resource(&pdev->dev, res);
+       if (IS_ERR(priv.dfs))
+               return PTR_ERR(priv.dfs);
+
+       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+       priv.pmu_cr = devm_ioremap_resource(&pdev->dev, res);
+       if (IS_ERR(priv.pmu_cr))
+               return PTR_ERR(priv.pmu_cr);
+
+       res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+       priv.pmu_clk_div = devm_ioremap_resource(&pdev->dev, res);
+       if (IS_ERR(priv.pmu_clk_div))
+               return PTR_ERR(priv.pmu_clk_div);
+
+       np = of_find_node_by_path("/cpus/cpu at 0");
+       if (!np)
+               return -ENODEV;
+
+       priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
+       if (IS_ERR(priv.cpu_clk)) {
+               dev_err(priv.dev, "Unable to get cpuclk");
+               return PTR_ERR(priv.cpu_clk);
+       }
+
+       clk_prepare_enable(priv.cpu_clk);
this can fail..
In theory yes. In practice no. It is a fixed rate clock. prepare and
enable are actually NOPs for this type of clock. However the API
documentation explicitly states you need to call prepare and enable
before you can call clk_get_rate(). But i can add error checking if
you want.
quoted
+       dove_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
  Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help