Thread (20 messages) 20 messages, 5 authors, 2014-03-07

RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

From: Anton Tikhomirov <hidden>
Date: 2014-03-06 08:52:27
Also in: linux-samsung-soc, lkml

Hello,
Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver



On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
quoted
Hi Kamil,

...
quoted
+| 3. Supporting SoCs
++--------------------
+
+To support a new SoC a new file should be added to the drivers/phy
+directory. Each SoC's configuration is stored in an instance of the
+struct samsung_usb2_phy_config.
+
+struct samsung_usb2_phy_config {
+	const struct samsung_usb2_common_phy *phys;
+	unsigned int num_phys;
+	bool has_mode_switch;
You missed rate_to_clk here.
quoted
+};
+
...
quoted
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
samsung-
quoted
quoted
usb2.c
new file mode 100644
index 0000000..c3b7719
--- /dev/null
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -0,0 +1,222 @@
+/*
+ * Samsung SoC USB 1.1/2.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski <k.debski@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2
as
quoted
quoted
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include "phy-samsung-usb2.h"
+
+static int samsung_usb2_phy_power_on(struct phy *phy)
+{
+	struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
+	struct samsung_usb2_phy_driver *drv = inst->drv;
+	int ret;
+
+	dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
+		inst->cfg->label);
+	ret = clk_prepare_enable(drv->clk);
clk_prepare_enable() can sleep, and therefore doesn't allow
samusng_usb2_phy_power_on() to be used in atomic context
(e.g. inside spin_lock-ed area), what sometimes may be desirable.
What about to prepare clock in probe, and just enable it here
(note: clk_enable() doesn't sleep).
The PHY power-on callback is anyway called with mutex held, so I guess
it's fine to have clk_prepare_enable() here.
If we rely totally on generic PHY functions such as phy_power_on()
and friends, why do we need to use locking in callbacks at all.
Thanks
Kishon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help