Re: [PATCH v2] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i814 - Bandgap Temperature read Dtemp can be corrupted
On Friday 10 April 2015 12:06 PM, Keerthy wrote:
Bandgap Temperature read Dtemp can be corrupted
DESCRIPTION
Read accesses to registers listed below can be corrupted due to
incorrect resynchronization between
clock domains.
Read access to registers below can be corrupted :
• CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
• CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
WORKAROUND
Multiple reads to CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA[9:0]:
BGAP_DTEMPMPU/GPU/CORE/DSPEVE/IVA is needed to discard false value and
read right value:
1. Perform two successive reads to BGAP_DTEMP bit field.
(a) If read1 returns Val1 and read2 returns Val1, then
right value is Val1.
(b) If read1 returns Val1, read 2 returns Val2, a
third read is needed.
2. Perform third read
(a) If read3 returns Val2 then right value is Val2.
(b) If read3 returns Val3, then right value is Val3.
The above in gist means if val1 and val2 are the same then we can go
ahead with that value
else we need a third read which will be right since synchronization
will be complete by then.
Signed-off-by: Keerthy j-keer...@ti.com
---
A Gentle ping on this. This has the comments fixed.
Changes in V2:
* Added more details in the description part.
* Indented the comments.
* Renamed ti_dra7_bandgap_read_temp to ti_errata814_bandgap_read_temp.
.../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 37 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 +++
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index a492927..58b5c66 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -420,7 +420,8 @@ const struct ti_bandgap_data dra752_data = {
TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
- TI_BANDGAP_FEATURE_HISTORY_BUFFER,
+ TI_BANDGAP_FEATURE_HISTORY_BUFFER |
+ TI_BANDGAP_FEATURE_ERRATA_814,
.fclock_name = l3instr_ts_gclk_div,
.div_ck_name = l3instr_ts_gclk_div,
.conv_table = dra752_adc_to_temp,
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 74c0e34..94acd80 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -119,6 +119,37 @@ exit:
}
/**
+ * ti_errata814_bandgap_read_temp() - helper function to read dra7 sensor
temperature
+ * @bgp: pointer to ti_bandgap structure
+ * @reg: desired register (offset) to be read
+ *
+ * Function to read dra7 bandgap sensor temperature. This is done separately
+ * so as to workaround the errata Bandgap Temperature read Dtemp can be
+ * corrupted - Errata ID: i814.
+ * Read accesses to registers listed below can be corrupted due to incorrect
+ * resynchronization between clock domains.
+ * Read access to registers below can be corrupted :
+ * CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
+ * CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
+ *
+ * Return: the register value.
+ */
+static u32 ti_errata814_bandgap_read_temp(struct ti_bandgap *bgp, u32 reg)
+{
+ u32 val1, val2;
+
+ val1 = ti_bandgap_readl(bgp, reg);
+ val2 = ti_bandgap_readl(bgp, reg);
+
+ /* If both times we read the same value then that is right */
+ if (val1 == val2)
+ return val1;
+
+ /* if val1 and val2 are different read it third time */
+ return ti_bandgap_readl(bgp, reg);
+}
+
+/**
* ti_bandgap_read_temp() - helper function to read sensor temperature
* @bgp: pointer to ti_bandgap structure
* @id: bandgap sensor id
@@ -148,7 +179,11 @@ static u32 ti_bandgap_read_temp(struct ti_bandgap *bgp,
int id)
}
/* read temperature */
- temp = ti_bandgap_readl(bgp, reg);
+ if (TI_BANDGAP_HAS(bgp, ERRATA_814))
+ temp = ti_errata814_bandgap_read_temp(bgp, reg);
+ else
+ temp = ti_bandgap_readl(bgp, reg);
+
temp = tsr-bgap_dtemp_mask;
if (TI_BANDGAP_HAS(bgp, FREEZE_BIT))
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b3adf72..b2da3fc 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -318,6 +318,9 @@ struct ti_temp_sensor {
* TI_BANDGAP_FEATURE_HISTORY_BUFFER - used when the bandgap device features
*a history buffer
[PATCH 2/6] phy: twl4030-usb: remove pointless 'suspended' test in 'suspend' callback.
When the runtime_suspend callback is running, 'runtime_status' is always RPM_SUSPENDING, so pm_runtime_suspended() will always fail. Similarly while the runtime_resume callback is running 'runtime_status' is RPM_RESUMING, so pm_runtime_active() will always fail. So remove these two pointless tests. Signed-off-by: NeilBrown n...@brown.name --- drivers/phy/phy-twl4030-usb.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 3078f80bf520..590c2b1c1a94 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -396,8 +396,6 @@ static int twl4030_usb_runtime_suspend(struct device *dev) struct twl4030_usb *twl = dev_get_drvdata(dev); dev_dbg(twl-dev, %s\n, __func__); - if (pm_runtime_suspended(dev)) - return 0; __twl4030_phy_power(twl, 0); regulator_disable(twl-usb1v5); @@ -413,8 +411,6 @@ static int twl4030_usb_runtime_resume(struct device *dev) int res; dev_dbg(twl-dev, %s\n, __func__); - if (pm_runtime_active(dev)) - return 0; res = regulator_enable(twl-usb3v1); if (res) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function.
The USB phy should initialize with power-off, and will be powered on by the USB system when a cable connection is detected. Having this pm_runtime_get_sync() during probe causes the phy to *always* be powered on. Removing it returns to sensible power management. Fixes: 96be39ab34b77c6f6f5cd6ae03aac6c6449ee5c4 Signed-off-by: NeilBrown n...@brown.name --- drivers/phy/phy-twl4030-usb.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 590c2b1c1a94..3a707dd14238 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -715,7 +715,6 @@ static int twl4030_usb_probe(struct platform_device *pdev) pm_runtime_use_autosuspend(pdev-dev); pm_runtime_set_autosuspend_delay(pdev-dev, 2000); pm_runtime_enable(pdev-dev); - pm_runtime_get_sync(pdev-dev); /* Our job is to use irqs and status from the power module * to keep the transceiver disabled when nothing's connected. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] phy: twl4030-usb: make runtime pm more reliable.
From: NeilBrown ne...@suse.de
A construct like:
if (pm_runtime_suspended(twl-dev))
pm_runtime_get_sync(twl-dev);
is against the spirit of the runtime_pm interface as it
makes the internal refcounting useless.
In this case it is also racy, particularly as 'put_autosuspend'
is used to drop a reference.
When that happens a timer is started and the device is
runtime-suspended after the timeout.
If the above code runs in this window, the device will not be
found to be suspended so no pm_runtime reference is taken.
When the timer expires the device will be suspended, which is
against the intention of the code.
So be more direct is taking and dropping references.
If twl-linkstat is VBUS_VALID or ID_GROUND, then hold a
pm_runtime reference, otherwise don't.
Define cable_present() to test for this condition.
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index bc42d6a8939f..3078f80bf520 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -144,6 +144,16 @@
#define PMBR1 0x0D
#define GPIO_USB_4PIN_ULPI_2430C (3 0)
+/*
+ * If VBUS is valid or ID is ground, then we know a
+ * cable is present and we need to be runtime-enabled
+ */
+static inline bool cable_present(enum omap_musb_vbus_id_status stat)
+{
+ return stat == OMAP_MUSB_VBUS_VALID ||
+ stat == OMAP_MUSB_ID_GROUND;
+}
+
struct twl4030_usb {
struct usb_phy phy;
struct device *dev;
@@ -536,8 +546,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
mutex_lock(twl-lock);
if (status = 0 status != twl-linkstat) {
+ status_changed =
+ cable_present(twl-linkstat) !=
+ cable_present(status);
twl-linkstat = status;
- status_changed = true;
}
mutex_unlock(twl-lock);
@@ -553,15 +565,11 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
* USB_LINK_VBUS state. musb_hdrc won't care until it
* starts to handle softconnect right.
*/
- if ((status == OMAP_MUSB_VBUS_VALID) ||
- (status == OMAP_MUSB_ID_GROUND)) {
- if (pm_runtime_suspended(twl-dev))
- pm_runtime_get_sync(twl-dev);
+ if (cable_present(status)) {
+ pm_runtime_get_sync(twl-dev);
} else {
- if (pm_runtime_active(twl-dev)) {
- pm_runtime_mark_last_busy(twl-dev);
- pm_runtime_put_autosuspend(twl-dev);
- }
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
}
omap_musb_mailbox(status);
}
@@ -767,6 +775,9 @@ static int twl4030_usb_remove(struct platform_device *pdev)
/* disable complete OTG block */
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
+
+ if (cable_present(twl-linkstat))
+ pm_runtime_put_noidle(twl-dev);
pm_runtime_mark_last_busy(twl-dev);
pm_runtime_put(twl-dev);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
From: NeilBrown ne...@suse.de
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek pa...@ucw.cz
Signed-off-by: NeilBrown ne...@suse.de
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: on, off.
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ unknown indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb *twl,
int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
+ floating,
+ unknown
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl-dev);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0 || !(ret ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret 0 || (ret 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ if (ret 0)
+ return TWL4030_ID_UNKNOWN;
+ ret = ffs(ret) - 1;
+ if (ret TWL4030_GROUND || ret TWL4030_FLOATING)
+ return TWL4030_ID_UNKNOWN;
+
+ return ret;
+}
+
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
@@ -532,6 +582,16 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
}
static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
+static ssize_t twl4030_usb_id_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ return scnprintf(buf, PAGE_SIZE, %s\n,
+twl4030_id_names[twl4030_get_id(twl)]);
+}
+static DEVICE_ATTR(id, 0444, twl4030_usb_id_show, NULL);
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -709,6 +769,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(pdev-dev, dev_attr_id))
+ dev_warn(pdev-dev, could not create sysfs file\n);
ATOMIC_INIT_NOTIFIER_HEAD(twl-phy.notifier);
@@ -753,6 +815,7 @@ static int twl4030_usb_remove(struct platform_device *pdev)
pm_runtime_get_sync(twl-dev);
cancel_delayed_work(twl-id_workaround_work);
device_remove_file(twl-dev, dev_attr_vbus);
+ device_remove_file(twl-dev, dev_attr_id);
/* set transceiver mode to power on defaults */
twl4030_usb_set_mode(twl, -1);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] phy: twl4030-usb: add extcon to report cable connections.
From: NeilBrown ne...@suse.de
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 67 +
1 file changed, 67 insertions(+)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 1d6f3e70193e..c42153d43ec2 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -40,6 +40,7 @@
#include linux/regulator/consumer.h
#include linux/err.h
#include linux/slab.h
+#include linux/extcon.h
/* Register defines */
@@ -173,6 +174,9 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
+ /* cable connection */
+ struct extcon_dev edev;
+
struct delayed_work id_workaround_work;
};
@@ -592,6 +596,54 @@ static ssize_t twl4030_usb_id_show(struct device *dev,
}
static DEVICE_ATTR(id, 0444, twl4030_usb_id_show, NULL);
+static const char *usb_cables[] = {
+ USB, /* id is floating */
+ Charger-downstream, /* id is floating and D+ shorted to D- */
+ USB-Host, /* id is ground */
+ USB-ACA, /* Accessory Charger Adapter id is something else */
+ NULL
+};
+enum {
+ TWL_CABLE_USB,
+ TWL_CABLE_CHARGER, /* Not used - twl4030 can detect charger,
+* but driver cannot yet */
+ TWL_CABLE_OTG,
+ TWL_CABLE_ACA,
+};
+static u32 all_exclusive[] = {0x, 0};
+
+static void twl4030_usb_report_cable(struct twl4030_usb *twl)
+{
+ enum twl4030_id_status sts;
+
+ if (!cable_present(twl-linkstat)) {
+ extcon_set_state(twl-edev, 0);
+ return;
+ }
+
+ sts = twl4030_get_id(twl);
+
+ switch (sts) {
+ case TWL4030_FLOATING: /* USB downstream */
+ extcon_update_state(twl-edev,
+ 1TWL_CABLE_USB,
+ 1TWL_CABLE_USB);
+ break;
+ case TWL4030_GROUND: /* USB host */
+ extcon_update_state(twl-edev,
+ 1TWL_CABLE_OTG,
+ 1TWL_CABLE_OTG);
+ break;
+ default: /* Some resistor */
+ extcon_update_state(twl-edev,
+ 1TWL_CABLE_ACA,
+ 1TWL_CABLE_ACA);
+ /* An ACA should set port to 'host' mode */
+ twl-linkstat = OMAP_MUSB_ID_GROUND;
+ break;
+ }
+}
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -628,6 +680,7 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
pm_runtime_put_autosuspend(twl-dev);
}
omap_musb_mailbox(status);
+ twl4030_usb_report_cable(twl);
}
/* don't schedule during sleep - irq works right then */
@@ -766,6 +819,20 @@ static int twl4030_usb_probe(struct platform_device *pdev)
}
usb_add_phy_dev(twl-phy);
+ twl-edev.name = devm_kasprintf(twl-dev, GFP_KERNEL, %s-usb,
+ dev_name(twl-dev-parent));
+ twl-edev.supported_cable = usb_cables;
+ twl-edev.mutually_exclusive = all_exclusive;
+ twl-edev.print_name = NULL; /* why would you change this? */
+ twl-edev.print_state = NULL; /* probably want to change this */
+
+ twl-edev.dev.parent = pdev-dev;
+ err = extcon_dev_register(twl-edev);
+ if (err) {
+ dev_err(pdev-dev, register extcon failed\n);
+ return err;
+ }
+
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
dev_warn(pdev-dev, could not create sysfs file\n);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/4] hwspinlock core omap dt support
Hi, Apologies for the delay on this. Gentle reminder. Can you please provide your ack on the bindings in this series (Patches 1 3) for Ohad to queue up the series for 4.1. Ping again, if you can provide your ack on these bindings and the qcom hwmutex bindings, then Ohad can pick up both the series for 4.1. Both series are blocked on getting the binding acks. Both the bindings look sane to me, so for patches 1 and 3: Acked-by: Mark Rutland mark.rutl...@arm.com Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
n900 in 4.1-rc0
Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Enhancements to twl4030 phy to support better charging.
Hi Kishon, this is a slightly modified version of the series I sent earlier. I've removed that patches which use the old 'notifier chain' and will solve the issue of communicating current available separately. I've added a couple of patches which fix some pm_runtime issues. In particular: phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function. Fixes a bug which causes the usb phy to remain permanently powered on, hence the Cc to Tony. If these could be queued for some future merge window, I would really appreciate it. Thanks, NeilBrown --- NeilBrown (6): phy: twl4030-usb: make runtime pm more reliable. phy: twl4030-usb: remove pointless 'suspended' test in 'suspend' callback. phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function. phy: twl4030-usb: add ABI documentation phy: twl4030-usb: add support for reading resistor on ID pin. phy: twl4030-usb: add extcon to report cable connections. .../ABI/testing/sysfs-platform-twl4030-usb | 30 drivers/phy/phy-twl4030-usb.c | 164 ++-- 2 files changed, 180 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-twl4030-usb -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] phy: twl4030-usb: add ABI documentation
From: NeilBrown ne...@suse.de This driver device one local attribute: vbus. Describe that in Documentation/ABI/testing/sysfs-platform/twl4030-usb. Signed-off-by: NeilBrown n...@brown.name --- .../ABI/testing/sysfs-platform-twl4030-usb |8 1 file changed, 8 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-twl4030-usb diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb b/Documentation/ABI/testing/sysfs-platform-twl4030-usb new file mode 100644 index ..512c51be64ae --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb @@ -0,0 +1,8 @@ +What: /sys/bus/platform/devices/*twl4030-usb/vbus +Description: + Read-only status reporting if VBUS (approx 5V) + is being supplied by the USB bus. + + Possible values: on, off. + + Changes are notified via select/poll. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n900 in 4.1-rc0
On 16/04/15 10:32, Pavel Machek wrote: Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? To such a question, the only answer I have is Yes. For a more useful reply, I'm afraid you'll have to ask a better question. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i813
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains
under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect
re-synchronization between
clock domains. The comparison between configured threshold and current
temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate event
generation.
No spurious event occurs as long as the threshold value stays unchanged.
Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence when
the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Signed-off-by: Keerthy j-keer...@ti.com
---
.../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 41 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 ++-
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index 58b5c66..4cd051d 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -421,7 +421,8 @@ const struct ti_bandgap_data dra752_data = {
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
TI_BANDGAP_FEATURE_HISTORY_BUFFER |
- TI_BANDGAP_FEATURE_ERRATA_814,
+ TI_BANDGAP_FEATURE_ERRATA_814 |
+ TI_BANDGAP_FEATURE_ERRATA_813,
.fclock_name = l3instr_ts_gclk_div,
.div_ck_name = l3instr_ts_gclk_div,
.conv_table = dra752_adc_to_temp,
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 94acd80..c2c585a 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -445,7 +445,7 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
{
struct temp_sensor_data *ts_data = bgp-conf-sensors[id].ts_data;
struct temp_sensor_registers *tsr;
- u32 thresh_val, reg_val, t_hot, t_cold;
+ u32 thresh_val, reg_val, t_hot, t_cold, ctrl;
int err = 0;
tsr = bgp-conf-sensors[id].registers;
@@ -477,8 +477,47 @@ static int ti_bandgap_update_alert_threshold(struct
ti_bandgap *bgp, int id,
~(tsr-threshold_thot_mask | tsr-threshold_tcold_mask);
reg_val |= (t_hot __ffs(tsr-threshold_thot_mask)) |
(t_cold __ffs(tsr-threshold_tcold_mask));
+
+ /**
+* Errata i813:
+* Spurious Thermal Alert: Talert can happen randomly while the device
+* remains under the temperature limit defined for this event to trig.
+* This spurious event is caused by a incorrect re-synchronization
+* between clock domains. The comparison between configured threshold
+* and current temperature value can happen while the value is
+* transitioning (metastable), thus causing inappropriate event
+* generation. No spurious event occurs as long as the threshold value
+* stays unchanged. Spurious event can be generated while a thermal
+* alert threshold is modified in
+* CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
+*/
+
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Mask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr-bgap_mask_ctrl);
+
+ if (hot)
+ ctrl = ~tsr-mask_hot_mask;
+ else
+ ctrl = ~tsr-mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr-bgap_mask_ctrl);
+ }
+
+ /* Write the threshold value */
ti_bandgap_writel(bgp, reg_val, tsr-bgap_threshold);
+ if (TI_BANDGAP_HAS(bgp, ERRATA_813)) {
+ /* Unmask t_hot and t_cold events at the IP Level */
+ ctrl = ti_bandgap_readl(bgp, tsr-bgap_mask_ctrl);
+ if (hot)
+ ctrl |= tsr-mask_hot_mask;
+ else
+ ctrl |= tsr-mask_cold_mask;
+
+ ti_bandgap_writel(bgp, ctrl, tsr-bgap_mask_ctrl);
+ }
+
if (err) {
dev_err(bgp-dev, failed to reprogram thot threshold\n);
err = -EIO;
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b2da3fc..0c52f7a 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -320,7 +320,8 @@ struct ti_temp_sensor {
*
*
Re: [RFC][PATCH v2 02/13] usb: otg-fsm: support multiple instances
On 16/04/15 14:36, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:49PM +0300, Roger Quadros wrote:
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
OTG device has only one port. See 3.1.1.
If you go to pass OTG Certification, the lab requires that there is only
one port at your board.
We're not breaking OTG compliance by this ;).
Moreover this structure is not limited to OTG but for DRD (dual-role) use as
well.
We can have multiple DRD ports per board.
cheers,
-roger
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 1736bbe..0caa37b 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
protocol)
return 0;
}
-static int state_changed;
-
/* Called when leaving a state. Do state clean up jobs here */
static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state
old_state)
{
@@ -123,7 +121,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
usb_otg_state old_state)
/* Called when entering a state */
static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
{
-state_changed = 1;
+fsm-state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -255,7 +253,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
state = fsm-otg-state;
-state_changed = 0;
+fsm-state_changed = 0;
/* State machine state change judgement */
switch (state) {
@@ -368,7 +366,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
-VDBG(quit statemachine, changed = %d\n, state_changed);
-return state_changed;
+VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+return fsm-state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index c5b74c5..85a9150 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -183,6 +183,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+bool state_changed;
};
struct otg_fsm_ops {
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 05/13] usb: otg: add OTG core
On Tue, Apr 14, 2015 at 01:41:52PM +0300, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/Makefile | 1 +
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-otg.c | 743
+++
drivers/usb/common/usb-otg.h | 71 +
drivers/usb/core/Kconfig | 8 +
include/linux/usb/usb-otg.h | 94 ++
There is otg.h at include/linux/usb/, why create another usb-otg.h,
it may confuse the user in future
If I understand correct, in your plan, both DRD and OTG FSM devices will run
OTG state machine code, right?
Peter
6 files changed, 918 insertions(+)
create mode 100644 drivers/usb/common/usb-otg.c
create mode 100644 drivers/usb/common/usb-otg.h
create mode 100644 include/linux/usb/usb-otg.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..07f59a5 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,5 +60,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
obj-$(CONFIG_USB_COMMON) += common/
+obj-$(CONFIG_USB_OTG_CORE) += common/
obj-$(CONFIG_USBIP_CORE) += usbip/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index ca2f8bd..573fc75 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,3 +7,4 @@ usb-common-y+= common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usb-otg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..e848e08
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,743 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/list.h
+#include linux/usb/otg.h
+#include linux/usb/phy.h /* enum usb_otg_state */
+#include linux/usb/gadget.h
+#include linux/usb/usb-otg.h
+#include linux/workqueue.h
+
+#include usb-otg.h
+
+/* to link timer with callback data */
+struct otg_timer {
+ struct hrtimer timer;
+ ktime_t timeout;
+ /* callback data */
+ int *timeout_bit;
+ struct otg_data *otgd;
+};
+
+struct otg_hcd {
+ struct usb_hcd *hcd;
+ unsigned int irqnum;
+ unsigned long irqflags;
+};
+
+struct otg_data {
+ struct device *dev; /* HCD GCD's parent device */
+
+ struct otg_fsm fsm;
+ /* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+ struct otg_fsm_ops fsm_ops; /* private copy for override */
+ struct usb_otg otg; /* allocator for fsm-otg */
+
+ struct otg_hcd primary_hcd;
+ struct otg_hcd shared_hcd;
+
+ /* saved hooks to OTG device */
+ int (*start_host)(struct otg_fsm *fsm, int on);
+ int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+ struct list_head list;
+
+ struct work_struct work;/* OTG FSM work */
+ struct workqueue_struct *wq;
+
+ struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+ bool fsm_running;
+ /* use otg-fsm.lock for serializing access */
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/**
+ * check if device is in our OTG list and return
+ * otg_data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ */
+static struct otg_data *usb_otg_device_get_otgd(struct device *parent_dev)
+{
+ struct otg_data *otgd;
+
+ list_for_each_entry(otgd, otg_list, list) {
+ if (otgd-dev == parent_dev)
+ return otgd;
+ }
+
+ return NULL;
+}
+
+/**
+ * timer callback to set timeout bit and kick FSM
+ */
+static enum hrtimer_restart set_tmout(struct hrtimer *data)
Re: [RFC][PATCH v2 04/13] usb: gadget: add usb_gadget_start/stop()
On Tue, Apr 14, 2015 at 01:41:51PM +0300, Roger Quadros wrote:
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 74
+++
include/linux/usb/gadget.h| 3 ++
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..3aa5dd5 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
*/
static inline int usb_gadget_udc_start(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
return udc-gadget-ops-udc_start(udc-gadget, udc-driver);
}
@@ -204,10 +205,83 @@ static inline int usb_gadget_udc_start(struct usb_udc
*udc)
*/
static inline void usb_gadget_udc_stop(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
udc-gadget-ops-udc_stop(udc-gadget);
}
/**
+ * usb_gadget_start - start the usb gadget controller and connect to bus
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ */
+int usb_gadget_start(struct usb_gadget *gadget)
+{
+ int ret;
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ ret = usb_gadget_udc_start(udc);
+ if (ret)
+ dev_err(udc-dev, USB Device Controller didn't start: %d\n,
+ ret);
+ else
+ usb_gadget_connect(udc-gadget);
OTG FSM manages its pullup/pulldown itself through its fsm-ops-loc_conn
+
+ mutex_unlock(udc_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_start);
+
+/**
+ * usb_gadget_stop - disconnect from bus and stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Disconnect from the bus (disable pull) and stop the
+ * gadget controller.
+ */
+int usb_gadget_stop(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
+ usb_gadget_udc_stop(udc);
+ mutex_unlock(udc_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_stop);
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e2f00fd..7ada7e6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -922,6 +922,9 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver);
*/
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver);
+int usb_gadget_start(struct usb_gadget *gadget);
+int usb_gadget_stop(struct usb_gadget *gadget);
+
extern int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget
*gadget);
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 05/13] usb: otg: add OTG core
On 16/04/15 15:02, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:52PM +0300, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/Makefile | 1 +
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-otg.c | 743
+++
drivers/usb/common/usb-otg.h | 71 +
drivers/usb/core/Kconfig | 8 +
include/linux/usb/usb-otg.h | 94 ++
There is otg.h at include/linux/usb/, why create another usb-otg.h,
it may confuse the user in future
I can reuse that file.
If I understand correct, in your plan, both DRD and OTG FSM devices will run
OTG state machine code, right?
That was my original plan but then I thought it unnecessary to initialize
all those OTG timers if only DRD operation is needed so I've implemented a
very simple DRD state machine. see patch 7.
cheers,
-roger
Peter
6 files changed, 918 insertions(+)
create mode 100644 drivers/usb/common/usb-otg.c
create mode 100644 drivers/usb/common/usb-otg.h
create mode 100644 include/linux/usb/usb-otg.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..07f59a5 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,5 +60,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
obj-$(CONFIG_USB_GADGET)+= gadget/
obj-$(CONFIG_USB_COMMON)+= common/
+obj-$(CONFIG_USB_OTG_CORE) += common/
obj-$(CONFIG_USBIP_CORE)+= usbip/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index ca2f8bd..573fc75 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,3 +7,4 @@ usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usb-otg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..e848e08
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,743 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/list.h
+#include linux/usb/otg.h
+#include linux/usb/phy.h /* enum usb_otg_state */
+#include linux/usb/gadget.h
+#include linux/usb/usb-otg.h
+#include linux/workqueue.h
+
+#include usb-otg.h
+
+/* to link timer with callback data */
+struct otg_timer {
+struct hrtimer timer;
+ktime_t timeout;
+/* callback data */
+int *timeout_bit;
+struct otg_data *otgd;
+};
+
+struct otg_hcd {
+struct usb_hcd *hcd;
+unsigned int irqnum;
+unsigned long irqflags;
+};
+
+struct otg_data {
+struct device *dev; /* HCD GCD's parent device */
+
+struct otg_fsm fsm;
+/* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+struct otg_fsm_ops fsm_ops; /* private copy for override */
+struct usb_otg otg; /* allocator for fsm-otg */
+
+struct otg_hcd primary_hcd;
+struct otg_hcd shared_hcd;
+
+/* saved hooks to OTG device */
+int (*start_host)(struct otg_fsm *fsm, int on);
+int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+struct list_head list;
+
+struct work_struct work;/* OTG FSM work */
+struct workqueue_struct *wq;
+
+struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+bool fsm_running;
+/* use otg-fsm.lock for serializing access */
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/**
+ * check if device is in our OTG list and return
+ * otg_data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ */
+static struct otg_data *usb_otg_device_get_otgd(struct device *parent_dev)
+{
+struct otg_data *otgd;
+
+list_for_each_entry(otgd, otg_list, list) {
+
Re: [RFC][PATCH v2 02/13] usb: otg-fsm: support multiple instances
On Tue, Apr 14, 2015 at 01:41:49PM +0300, Roger Quadros wrote:
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
OTG device has only one port. See 3.1.1.
If you go to pass OTG Certification, the lab requires that there is only
one port at your board.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 1736bbe..0caa37b 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
protocol)
return 0;
}
-static int state_changed;
-
/* Called when leaving a state. Do state clean up jobs here */
static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state
old_state)
{
@@ -123,7 +121,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
usb_otg_state old_state)
/* Called when entering a state */
static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
{
- state_changed = 1;
+ fsm-state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -255,7 +253,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
state = fsm-otg-state;
- state_changed = 0;
+ fsm-state_changed = 0;
/* State machine state change judgement */
switch (state) {
@@ -368,7 +366,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
- VDBG(quit statemachine, changed = %d\n, state_changed);
- return state_changed;
+ VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+ return fsm-state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index c5b74c5..85a9150 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -183,6 +183,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+ bool state_changed;
};
struct otg_fsm_ops {
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/4] hwspinlock core omap dt support
On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland mark.rutl...@arm.com wrote: Hi, Apologies for the delay on this. Gentle reminder. Can you please provide your ack on the bindings in this series (Patches 1 3) for Ohad to queue up the series for 4.1. Ping again, if you can provide your ack on these bindings and the qcom hwmutex bindings, then Ohad can pick up both the series for 4.1. Both series are blocked on getting the binding acks. Both the bindings look sane to me, so for patches 1 and 3: Acked-by: Mark Rutland mark.rutl...@arm.com Great, thanks a lot Mark! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 03/13] usb: otg-fsm: Prevent build warning VDBG redefined
On 16/04/15 14:41, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:50PM +0300, Roger Quadros wrote:
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by moving the VDBG defination into the
usb-otg-fsm.c file where it is used.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: VDBG redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location of the
previous definition
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 9 +
include/linux/usb/otg-fsm.h | 15 ---
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 0caa37b..35f311a 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,15 @@
#include linux/usb/otg.h
#include linux/usb/otg-fsm.h
+#undef VDBG
+
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug([%s] fmt , \
+ __func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
It is obsolete too, we may use dev_vdbg instead of it.
ok, we need to add 'struct device *' to 'struct otg_fsm' then.
cheers,
-roger
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 85a9150..73136aa 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include linux/mutex.h
#include linux/errno.h
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug([%s] fmt , \
- __func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk(Current Location [%s]:[%d]\n, __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF (0)
#define PROTO_HOST (1)
#define PROTO_GADGET(2)
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 04/13] usb: gadget: add usb_gadget_start/stop()
On Thu, Apr 16, 2015 at 03:07:41PM +0300, Roger Quadros wrote:
On 16/04/15 14:48, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:51PM +0300, Roger Quadros wrote:
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 74
+++
include/linux/usb/gadget.h| 3 ++
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..3aa5dd5 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
*/
static inline int usb_gadget_udc_start(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
return udc-gadget-ops-udc_start(udc-gadget, udc-driver);
}
@@ -204,10 +205,83 @@ static inline int usb_gadget_udc_start(struct
usb_udc *udc)
*/
static inline void usb_gadget_udc_stop(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
udc-gadget-ops-udc_stop(udc-gadget);
}
/**
+ * usb_gadget_start - start the usb gadget controller and connect to bus
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ */
+int usb_gadget_start(struct usb_gadget *gadget)
+{
+ int ret;
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ ret = usb_gadget_udc_start(udc);
+ if (ret)
+ dev_err(udc-dev, USB Device Controller didn't start: %d\n,
+ ret);
+ else
+ usb_gadget_connect(udc-gadget);
OTG FSM manages its pullup/pulldown itself through its fsm-ops-loc_conn
That API usb_gadget_udc_start() is used by DRD (dual-role) FSM as well
and it doesn't use ops-loc_conn. So i'm wondering how to make this work for
both.
I could probably remove the pull up control from usb_gadget_start/stop()
and move it into the DRD FSM.
Just like I comment your at your 5th patch, if we want both DRD and OTG FSM
devices run the same code. From our experience, it can cover both at
runtime if we can handle otg descriptor well (no otg descriptor for
DRD device).
Peter
+
+ mutex_unlock(udc_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_start);
+
+/**
+ * usb_gadget_stop - disconnect from bus and stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Disconnect from the bus (disable pull) and stop the
+ * gadget controller.
+ */
+int usb_gadget_stop(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
+ usb_gadget_udc_stop(udc);
+ mutex_unlock(udc_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_stop);
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e2f00fd..7ada7e6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -922,6 +922,9 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver);
*/
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver);
+int usb_gadget_start(struct usb_gadget *gadget);
+int usb_gadget_stop(struct usb_gadget *gadget);
+
extern int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget
*gadget);
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 03/13] usb: otg-fsm: Prevent build warning VDBG redefined
On Tue, Apr 14, 2015 at 01:41:50PM +0300, Roger Quadros wrote:
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by moving the VDBG defination into the
usb-otg-fsm.c file where it is used.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: VDBG redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location of the
previous definition
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 9 +
include/linux/usb/otg-fsm.h | 15 ---
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 0caa37b..35f311a 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,15 @@
#include linux/usb/otg.h
#include linux/usb/otg-fsm.h
+#undef VDBG
+
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug([%s] fmt , \
+ __func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
It is obsolete too, we may use dev_vdbg instead of it.
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 85a9150..73136aa 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include linux/mutex.h
#include linux/errno.h
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug([%s] fmt , \
- __func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk(Current Location [%s]:[%d]\n, __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF (0)
#define PROTO_HOST (1)
#define PROTO_GADGET (2)
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 01/13] usb: otg-fsm: Add documentation for struct otg_fsm
On Tue, Apr 14, 2015 at 01:41:48PM +0300, Roger Quadros wrote:
struct otg_fsm is the interface to the OTG state machine.
Document the input, output and internal state variables.
Definations are taken from Table 7-2 and Table 7-4 of
the USB OTG EH Specification Rev.2.0
Re-arrange some of the members as per use case for more
clarity.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/usb/otg-fsm.h | 80
+
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index b6ba1bf..c5b74c5 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -57,37 +57,103 @@ enum otg_fsm_timer {
NUM_OTG_FSM_TIMERS,
};
-/* OTG state machine according to the OTG spec */
+/**
+ * struct otg_fsm - OTG state machine according to the OTG spec
+ *
+ * OTG hardware Inputs
+ *
+ * Common inputs for A and B device
What's the intention you leave two spaces at above line?
+ * @id: TRUE for B-device, FALSE for A-device.
+ * @adp_change: TRUE when current ADP measurement (n) value, compared to the
+ * ADP measurement taken at n-2, differs by more than CADP_THR
+ * @power_up:TRUE when the OTG device first powers up its USB system
and
+ * ADP measurement taken if ADP capable
+ *
+ * A-Device state inputs
+ * @a_srp_det: TRUE if the A-device detects SRP
+ * @a_vbus_vld: TRUE when VBUS voltage is in regulation
+ * @b_conn: TRUE if the A-device detects connection from the B-device
+ * @a_bus_resume: TRUE when the B-device detects that the A-device is
signaling
+ * a resume (K state)
+ * B-Device state inputs
+ * @a_bus_suspend: TRUE when the B-device detects that the A-device has put
the bus into suspend
+ * @a_conn: TRUE if the B-device detects a connection from the A-device
+ * @b_se0_srp: TRUE when the line has been at SE0 for more than the
minimum
+ * time before generating SRP
+ * @b_ssend_srp: TRUE when the VBUS has been below VOTG_SESS_VLD for more
than
+ *the minimum time before generating SRP
+ * @b_sess_vld: TRUE when the B-device detects that the voltage on VBUS
is
+ * above VOTG_SESS_VLD
+ * @test_device: TRUE when the B-device switches to B-Host and detects an
OTG test device
+ *FIXME: must be set by host/hub driver
Yes, according to pid/vid pair.
+ *
+ * Application inputs (A-Device)
+ * @a_bus_drop: TRUE when A-device application needs to power down the
bus
+ * @a_bus_req: TRUE when A-device application wants to use the bus.
+ * FALSE to suspend the bus
+ *
+ * Application inputs (B-Device)
+ * @b_bus_req: TRUE during the time that the Application running on the
+ * B-device wants to use the bus
+ *
+ * Auxilary inputs
+ * @a_sess_vld: ??
See OTG spec 1.3, and obsolete now.
+ * @b_bus_suspend: ??
+ * @b_bus_resume:??
They are used at current otg fsm, just for B-host.
+ *
+ * OTG Output status. Read only for users. updated by otg_ops() helpers
+ *
+ * Outputs for Both A and B device
+ * @drv_vbus:TRUE when A-device is driving VBUS
+ * @loc_conn:TRUE when the local device has signaled that it is
connected to the bus
+ * @loc_sof: TRUE when the local device is generating activity on the bus
+ * @adp_prb: TRUE when the local device is in the process of doing ADP
probing
+ *
+ * Outputs for B-device state
+ * @adp_sns: TRUE when the B-device is in the process of carrying out ADP
sensing
+ * @data_pulse: TRUE when the B-device is performing data line pulsing
+ *
+ * Internal Variables
+ *
+ * a_set_b_hnp_en: TRUE when the A-device has successfully set the
b_hnp_enable bit in the B-device.
+ * FIXME: OTG fsm uses otg-host-b_hnp_enable instead
a_set_b_hnp_en is for otg 2.0 and it should instead of
otg-host-b_hnp_enable at otg fsm.
+ * b_srp_done: TRUE when the B-device has completed initiating SRP
+ * b_hnp_enable: TRUE when the B-device has accepted the
SetFeature(b_hnp_enable) B-device
+ *FIXME: OTG fsm uses otg-gadget-b_hnp_enable instead
Yes
+ * a_clr_err:Asserted (by application ?) to clear a_vbus_err due to
an overcurrent condition
+ * and causes the A-device to transition to a_wait_vfall
+ */
struct otg_fsm {
/* Input */
int id;
int adp_change;
int power_up;
- int test_device;
- int a_bus_drop;
- int a_bus_req;
int a_srp_det;
int a_vbus_vld;
int b_conn;
int a_bus_resume;
int a_bus_suspend;
int a_conn;
- int b_bus_req;
int b_se0_srp;
int b_ssend_srp;
int b_sess_vld;
+ int test_device;
+ int a_bus_drop;
+ int a_bus_req;
+ int b_bus_req;
+
/* Auxilary inputs */
Re: [RFC][PATCH v2 02/13] usb: otg-fsm: support multiple instances
On Thu, Apr 16, 2015 at 02:58:20PM +0300, Roger Quadros wrote:
On 16/04/15 14:36, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:49PM +0300, Roger Quadros wrote:
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
OTG device has only one port. See 3.1.1.
If you go to pass OTG Certification, the lab requires that there is only
one port at your board.
We're not breaking OTG compliance by this ;).
Moreover this structure is not limited to OTG but for DRD (dual-role) use as
well.
We can have multiple DRD ports per board.
Ok, the code is ok for keeping multiple instances.
Peter
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 1736bbe..0caa37b 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
protocol)
return 0;
}
-static int state_changed;
-
/* Called when leaving a state. Do state clean up jobs here */
static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state
old_state)
{
@@ -123,7 +121,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
usb_otg_state old_state)
/* Called when entering a state */
static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state
new_state)
{
- state_changed = 1;
+ fsm-state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -255,7 +253,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
state = fsm-otg-state;
- state_changed = 0;
+ fsm-state_changed = 0;
/* State machine state change judgement */
switch (state) {
@@ -368,7 +366,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
- VDBG(quit statemachine, changed = %d\n, state_changed);
- return state_changed;
+ VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+ return fsm-state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index c5b74c5..85a9150 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -183,6 +183,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+ bool state_changed;
};
struct otg_fsm_ops {
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 04/13] usb: gadget: add usb_gadget_start/stop()
On 16/04/15 14:48, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:51PM +0300, Roger Quadros wrote:
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 74
+++
include/linux/usb/gadget.h| 3 ++
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..3aa5dd5 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
*/
static inline int usb_gadget_udc_start(struct usb_udc *udc)
{
+dev_dbg(udc-dev, %s\n, __func__);
return udc-gadget-ops-udc_start(udc-gadget, udc-driver);
}
@@ -204,10 +205,83 @@ static inline int usb_gadget_udc_start(struct usb_udc
*udc)
*/
static inline void usb_gadget_udc_stop(struct usb_udc *udc)
{
+dev_dbg(udc-dev, %s\n, __func__);
udc-gadget-ops-udc_stop(udc-gadget);
}
/**
+ * usb_gadget_start - start the usb gadget controller and connect to bus
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ */
+int usb_gadget_start(struct usb_gadget *gadget)
+{
+int ret;
+struct usb_udc *udc = NULL;
+
+dev_dbg(gadget-dev, %s\n, __func__);
+mutex_lock(udc_lock);
+list_for_each_entry(udc, udc_list, list)
+if (udc-gadget == gadget)
+goto found;
+
+dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+__func__);
+mutex_unlock(udc_lock);
+return -EINVAL;
+
+found:
+ret = usb_gadget_udc_start(udc);
+if (ret)
+dev_err(udc-dev, USB Device Controller didn't start: %d\n,
+ret);
+else
+usb_gadget_connect(udc-gadget);
OTG FSM manages its pullup/pulldown itself through its fsm-ops-loc_conn
That API usb_gadget_udc_start() is used by DRD (dual-role) FSM as well
and it doesn't use ops-loc_conn. So i'm wondering how to make this work for
both.
I could probably remove the pull up control from usb_gadget_start/stop()
and move it into the DRD FSM.
cheers,
-roger
+
+mutex_unlock(udc_lock);
+
+return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_start);
+
+/**
+ * usb_gadget_stop - disconnect from bus and stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Disconnect from the bus (disable pull) and stop the
+ * gadget controller.
+ */
+int usb_gadget_stop(struct usb_gadget *gadget)
+{
+struct usb_udc *udc = NULL;
+
+dev_dbg(gadget-dev, %s\n, __func__);
+mutex_lock(udc_lock);
+list_for_each_entry(udc, udc_list, list)
+if (udc-gadget == gadget)
+goto found;
+
+dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+__func__);
+mutex_unlock(udc_lock);
+return -EINVAL;
+
+found:
+usb_gadget_disconnect(udc-gadget);
+udc-driver-disconnect(udc-gadget);
+usb_gadget_udc_stop(udc);
+mutex_unlock(udc_lock);
+
+return 0;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_stop);
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e2f00fd..7ada7e6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -922,6 +922,9 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver);
*/
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver);
+int usb_gadget_start(struct usb_gadget *gadget);
+int usb_gadget_stop(struct usb_gadget *gadget);
+
extern int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget
*gadget);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i813
On Thu, Apr 16, 2015 at 1:18 PM, Keerthy j-keer...@ti.com wrote:
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains
under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect
re-synchronization between
clock domains. The comparison between configured threshold and current
temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate
event generation.
No spurious event occurs as long as the threshold value stays unchanged.
Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence
when the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Signed-off-by: Keerthy j-keer...@ti.com
---
.../thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +-
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 41
+-
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 4 ++-
3 files changed, 45 insertions(+), 3 deletions(-)
...
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
index b2da3fc..0c52f7a 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
@@ -320,7 +320,8 @@ struct ti_temp_sensor {
*
* TI_BANDGAP_FEATURE_ERRATA_814 - used to workaorund when the bandgap device
* has Errata 814
- *
+ * TI_BANDGAP_FEATURE_ERRATA_813 - used to workaorund when the bandgap device
+ * has Errata 813
workaorund?
--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 03/13] usb: otg-fsm: Prevent build warning VDBG redefined
On Thu, Apr 16, 2015 at 02:59:12PM +0300, Roger Quadros wrote:
On 16/04/15 14:41, Peter Chen wrote:
On Tue, Apr 14, 2015 at 01:41:50PM +0300, Roger Quadros wrote:
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by moving the VDBG defination into the
usb-otg-fsm.c file where it is used.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: VDBG redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location of
the previous definition
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 9 +
include/linux/usb/otg-fsm.h | 15 ---
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 0caa37b..35f311a 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,15 @@
#include linux/usb/otg.h
#include linux/usb/otg-fsm.h
+#undef VDBG
+
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug([%s] fmt , \
+ __func__, ## args)
+#else
+#define VDBG(stuff...)do {} while (0)
+#endif
+
It is obsolete too, we may use dev_vdbg instead of it.
ok, we need to add 'struct device *' to 'struct otg_fsm' then.
I am not sure if we will keep struct device * for otg device at last,
if it is, you can use otg's.
Peter
cheers,
-roger
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 85a9150..73136aa 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include linux/mutex.h
#include linux/errno.h
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug([%s] fmt , \
- __func__, ## args)
-#else
-#define VDBG(stuff...)do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk(Current Location [%s]:[%d]\n, __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF (0)
#define PROTO_HOST(1)
#define PROTO_GADGET (2)
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi Paul, On Sat, Apr 11, 2015 at 10:19 AM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: On Sat, Apr 11, 2015 at 12:03 AM, Paul Walmsley p...@pwsan.com wrote: On Fri, 10 Apr 2015, Lad, Prabhakar wrote: On Fri, Apr 10, 2015 at 11:51 PM, Paul Walmsley p...@pwsan.com wrote: Hi Prabhakar On Fri, 10 Apr 2015, Lad, Prabhakar wrote: Hi Paul, On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. I see that this patch is not into linux-next yet. thanks for the ping. This slipped through the cracks here due to the kernel version number change from 3.21 to 4.1 :-( Sorry about that; I will requeue for either 4.1-rc or 4.2. Unfortunately I don't have an AM43xx board. Is suspend/resume broken without this patch? If so, then v4.1-rc seems like the appropriate target. there is kernel soft crashes without this patch, so this needs to go in for v4.1-rc. Could you provide some further detail? Does it crash during boot, or during suspend, or ... ? Also could you describe what you mean by soft crash ? with patch [1] applied and VPFE being enabled and this patch missing (ARM: AM43xx: hwmod: add VPFE hwmod entries) I have attached the boot log. By soft crash I meant it doesn't get hung :) With the above patch (ARM: AM43xx: hwmod: add VPFE hwmod entries) applied all goes well. [1] https://lkml.org/lkml/2015/3/12/1001 Any update on this ? Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM errata 430973 on multi platform kernels
* Sebastian Reichel s...@kernel.org [150415 09:32]: Hi, On Thu, Apr 09, 2015 at 02:48:43PM +0100, Russell King - ARM Linux wrote: On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote: On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote: Works for me. The above needs the following fix folded in to build: --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -532,7 +532,7 @@ __v7_ca9mp_proc_info: __v7_ca8_proc_info: .long 0x410fc080 .long 0xff00 - __v7_proc __v7_ca8mp_proc_info, proc_fns = ca8_processor_functions + __v7_proc __v7_ca8_proc_info, __v7_setup, proc_fns = ca8_processor_functions .size __v7_ca8_proc_info, . - __v7_ca8_proc_info #endif /* CONFIG_ARM_LPAE */ Thanks, merged into the original patch. Do you want to give me an ack for this, thanks? I tried to test this together with Tony's follow up patch, but I get this after applying the patch to v4.0: sre@earth ~/src/linux [430973-fix] % make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: 'include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h AS arch/arm/mm/proc-v7.o arch/arm/mm/proc-v7.S: Assembler messages: arch/arm/mm/proc-v7.S:535: Error: invalid operands (*ABS* and .text sections) for `|' arch/arm/mm/proc-v7.S:535: Error: invalid operands (*ABS* and .text sections) for `|' scripts/Makefile.build:294: recipe for target 'arch/arm/mm/proc-v7.o' failed make[1]: *** [arch/arm/mm/proc-v7.o] Error 1 Makefile:947: recipe for target 'arch/arm/mm' failed make: *** [arch/arm/mm] Error 2 make: *** Waiting for unfinished jobs Maybe test the version in Linux next: a6d746789825 (ARM: proc-v7: avoid errata 430973 workaround for non-Cortex A8 CPUs) And then apply my patch on top. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x OMAP2 common clock external fixed-clock registration
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351
clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the
mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
snip
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate
accuracy phase
ref27002700
0 0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get
in the first place, as far as I understand this destroys the clock
handle, which is still being used later in the code.
-Tero
Not sure how this ever worked. This has been in the code since the
initial commit.
Sebastian?
Regards,
Mike
+ clock-frequency = 2700;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no
matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM errata 430973 on multi platform kernels
On 10 April 2015 at 00:37, Grazvydas Ignotas nota...@gmail.com wrote: May I ask how do you perform the smc call? A point worth mentioning is that TI advises that r1-r4 may be clobbered in general, and at least on GP dm814x and am335x devices r4 is in fact clobbered, even though it is normally a callee-save register. Also, on aforementioned devices, the secure-world MMU is enabled, with translation table 0 being 1KB @ 0x402f2000, used for secure VA 0x - 0x0fff (the rest goes via translation table 1 in secure ROM). It is generally not consulted in practice since secrom locks two dTLB and two iTLB entries. The GP secure monitor doesn't actually perform any data access whatsoever, so the two dTLB can and should be unlocked considering that TLB entries are a rather scarce resource (32 per side) and a dTLB miss incurs a 24-cycle minimum penalty (compare with 8-cycle minimum penalty for L1 cache miss). Unlocking the second iTLB entry is also safe, but if both iTLB entries are unlocked, you need to preserve or repopulate the relevant translation entry (VA 0x0030 - PA 0x) to be able to perform an SMC. Everything that happens in secure monitor mode is heavily double-checked by the SSM, so while you're free to choose a cache policy, any creativity beyond that will piss off the SSM and cause it to hit the MPU security violation global reset. Once appropriate fixes to the auxiliary control register have been applied, generally no further SMCs are needed hence all TLB entries can be unlocked. Since it would be reasonable for a bootloader to do this, I recommend checking whether a fix is needed and not unconditionally performing an SMC. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: i2c: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. --- drivers/i2c/busses/i2c-omap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..6b5d4bd 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1423,6 +1423,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1433,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT PATCH 2/2] gpio: omap: ensure that runtime pm will disable unused gpio banks
* Tony Lindgren t...@atomide.com [150319 16:08]:
* Tony Lindgren t...@atomide.com [150307 00:08]:
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150306
11:27]:
From: Grygorii Strashko grygorii.stras...@linaro.org
Now there are two points related to Runtime PM usage:
1) bank state doesn't need to be checked in places where
Rintime PM is used, bacause Runtime PM maintains its
own usage counter:
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
so, it's safe to drop such checks.
2) There is a call of pm_runtime_get_sync() in omap_gpio_irq_type(),
but no corresponding put. As result, GPIO devices could be
powered on forever if at least one GPIO was used as IRQ.
Hence, allow powering off GPIO banks by adding missed
pm_runtime_put(bank-dev) at the end of omap_gpio_irq_type().
Nice to see this happening, but I think before merging this we need
to test to be sure that the pm_runtime calls actually match.. I'm
not convinced right now.. We may still have uninitialized entry
points similar to 3d009c8c61f9 (gpio: omap: Fix bad device
access with setup_irq()).
OK so I finally got around testing this along with your bank
removal set. Looks like this patch causes a regression at least
with n900 keyboard LEDs with off-idle. The LED won't come back
on after restore from off-idle. Anyways, now we have something
reproducable :) So I'll try to debug it further at some point,
might be few days before I get to it.
Sorry for the delay, finally got around to this one :)
Here's what I came up with, only lightly tested so far. Note that
we need to keep the PM runtime per bank, not per GPIO. Will repost
a proper patch after some more testing.
This should not cause any functional changes, mostly just removal
of code that can all be done in omap_enable/disable_gpio_module.
Regards,
Tony
8 -
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -86,6 +86,7 @@ struct gpio_bank {
#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
#define LINE_USED(line, offset) (line (BIT(offset)))
+static void omap_reset_gpio(struct gpio_bank *bank, unsigned offset);
static void omap_gpio_unmask_irq(struct irq_data *d);
static inline struct gpio_bank *omap_irq_data_get_bank(struct irq_data *d)
@@ -419,8 +420,16 @@ static int omap_set_gpio_triggering(struct gpio_bank
*bank, int gpio,
return 0;
}
-static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset,
+ bool is_irq)
{
+ unsigned long flags;
+
+ /* PM runtime is per bank, not per GPIO line */
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
+
+ spin_lock_irqsave(bank-lock, flags);
if (bank-regs-pinctrl) {
void __iomem *reg = bank-base + bank-regs-pinctrl;
@@ -438,11 +447,30 @@ static void omap_enable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+
+ if (is_irq) {
+ omap_set_gpio_direction(bank, offset, 1);
+ bank-irq_usage |= BIT(offset);
+ } else {
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ bank-mod_usage |= BIT(offset);
+ }
+ spin_unlock_irqrestore(bank-lock, flags);
}
-static void omap_disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+static void omap_disable_gpio_module(struct gpio_bank *bank, unsigned offset,
+bool is_irq)
{
void __iomem *base = bank-base;
+ unsigned long flags;
+
+ spin_lock_irqsave(bank-lock, flags);
+ if (is_irq)
+ bank-irq_usage = ~(BIT(offset));
+ else
+ bank-mod_usage = ~(BIT(offset));
+
+ omap_reset_gpio(bank, offset);
if (bank-regs-wkup_en
!LINE_USED(bank-mod_usage, offset)
@@ -463,6 +491,11 @@ static void omap_disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ /* PM runtime is per bank, not per GPIO line */
+ if (!BANK_USED(bank))
+ pm_runtime_put(bank-dev);
}
static int omap_gpio_is_input(struct gpio_bank *bank, unsigned offset)
@@ -472,15 +505,6 @@ static int omap_gpio_is_input(struct gpio_bank *bank,
unsigned offset)
return readl_relaxed(reg) BIT(offset);
}
-static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned offset)
-{
- if (!LINE_USED(bank-mod_usage, offset)) {
- omap_enable_gpio_module(bank, offset);
- omap_set_gpio_direction(bank, offset, 1);
- }
- bank-irq_usage |= BIT(offset);
-}
-
static int
Re: n900 in 4.1-rc0
* Marc Zyngier marc.zyng...@arm.com [150416 02:38]: On 16/04/15 10:32, Pavel Machek wrote: Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? To such a question, the only answer I have is Yes. For a more useful reply, I'm afraid you'll have to ask a better question. Just tried it at 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085 and it boots just fine on my n900. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n900 in 4.1-rc0
On 16 April 2015 at 02:32, Pavel Machek pa...@ucw.cz wrote: Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? Looks like DT and legacy booting are working fine in our labs. [0][1] Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Tyler [0] http://kernelci.org/boot/omap3-n900/ [1] http://kernelci.org/boot/omap3-n900,legacy/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x OMAP2 common clock external fixed-clock registration
On 16.04.2015 18:17, Michael Welling wrote: On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: On 04/15/2015 11:51 PM, Michael Welling wrote: On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote: [...] There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. Not sure how this ever worked. This has been in the code since the initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x OMAP2 common clock external fixed-clock registration
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
On 16.04.2015 18:17, Michael Welling wrote:
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org
wrote:
[...]
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get
in the first place, as far as I understand this destroys the clock
handle, which is still being used later in the code.
Not sure how this ever worked. This has been in the code since the
initial commit.
The reason it worked before may be related with recent rework of
clk_put() itself and clk cookies instead of pointers. I lost track on
the recent clk subsystem changes here, sorry.
However, droping the clk immediately surely isn't right.
The thing is, we can remove the clk_put() just because there is no
_remove() for that driver. I remember that back in the days the driver
was mainlined, clk removal wasn't too easy.
FWIW, as soon as _remove() support will be added by someone, we'll have
to rethink passing struct clk* by platform_data or at least
double-check if we ever used [of_]clk_get() to obtain it.
Mind to send a patch removing the clk_put() on !IS_ERR and add a proper
error path instead? While of_clk_get() is the only calls that need
cleanup on error in si5351_dt_parse() we should probably move that
calls to the end of this function. Otherwise we'd also have to cleanup
on every of_parse_foo() failure.
What would be the proper error path?
What cleanup is required?
It should be noted that there are more deep rooted issues with the driver
that I have noticed. For one the driver behaves differently if the debugging
is on and when it is off.
Here is what the kernel reports with debugging off:
root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary
clock enable_cnt prepare_cntrate accuracy
phase
ref27002700 0
0
xtal 002700 0
0
pllb 00 59994 0
0
ms0 001249 0
0
clk0 001249 0
0
plla 00 59994 0
0
ms2 00 8219178 0
0
clk2 00 8219178 0
0
ms1 0094117646 0
0
clk1 0094117646 0
0
Here is what the kernel reports with debugging on:
clock enable_cnt prepare_cntrate accuracy
phase
ref27002700 0
0
xtal 002700 0
0
pllb 00 884736000 0
0
ms0 0018432000 0
0
clk0 0018432000 0
0
plla 00 897023997 0
0
ms2 0012287999 0
0
clk2 0012287999 0
0
ms1 00 140709646 0
0
clk1 00 140709646 0
0
Note this is with the following devicetree entry:
si5351: clock-generator {
#address-cells = 1;
#size-cells = 0;
#clock-cells = 1;
compatible = silabs,si5351a-msop;
reg = 0x60;
status = okay;
/* connect xtal input to 27MHz reference */
clocks = ref27;
/* connect xtal input as source of pll0 and pll1 */
silabs,pll-source = 0 0, 1 0;
clkout0: clkout0 {
reg = 0;
[PATCH] ARM: dts: dra7: Fix efuse register size for ABB
Fix a typo in DRA7 dtsi where 12 bytes are needed for register description of ABB efuse registers, however only 8 bytes are provided to map. For some weird reason, this does not generate abort at offset 0x8, probably due to default maps already provided in io.c for the bus register ranges. Reported-by: Matt Gessner matt.gess...@windriver.com Reported-by: Suman Anna s-a...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/dra7.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 5332b57b4950..92b8bb873f43 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -911,7 +911,7 @@ ti,clock-cycles = 16; reg = 0x4ae07ddc 0x4, 0x4ae07de0 0x4, - 0x4ae06014 0x4, 0x4a003b20 0x8, + 0x4ae06014 0x4, 0x4a003b20 0xc, 0x4ae0c158 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -944,7 +944,7 @@ ti,clock-cycles = 16; reg = 0x4ae07e34 0x4, 0x4ae07e24 0x4, - 0x4ae06010 0x4, 0x4a0025cc 0x8, + 0x4ae06010 0x4, 0x4a0025cc 0xc, 0x4a002470 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -977,7 +977,7 @@ ti,clock-cycles = 16; reg = 0x4ae07e30 0x4, 0x4ae07e20 0x4, - 0x4ae06010 0x4, 0x4a0025e0 0x8, + 0x4ae06010 0x4, 0x4a0025e0 0xc, 0x4a00246c 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -1010,7 +1010,7 @@ ti,clock-cycles = 16; reg = 0x4ae07de4 0x4, 0x4ae07de8 0x4, - 0x4ae06010 0x4, 0x4a003b08 0x8, + 0x4ae06010 0x4, 0x4a003b08 0xc, 0x4ae0c154 0x4; reg-names = setup-address, control-address, int-address, efuse-address, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x crypto module clocks
On 13 April 2015 at 12:27, Tero Kristo t-kri...@ti.com wrote:
pka/rng/des is using l4ls_gclk.
Does any instance of subarctic actually have a working DES
accelerator? Looking at the L4LS memory map, the only plausible
location for it would be 0x48315000 (sec context) / 0x48316000 (pub
context), but after enabling it manually in PRCM I still get a bus
error on attempt to read the version register (offset 0x30) through
either context.
(Of course it doesn't seem likely that anyone will miss it anyway...)
The PKA does appear to work, but it's missing from the hwmod data and
device tree. Given the TRM's (annoying) usual silence on crypto
modules, I'll summarize the relevant integration info I have:
For device-tree:
pka: pka@48318000 {
reg = 0x48318000 0x4000;
interrupts = 110;
};
Relevant wrapper registers:
0x1fe0 revision (highlander format)
0x1ff0 sysconfig
0x1ff4 sysstatus
0x1ff8 irq rawstatus
0x1ffc irq enabled
For sysconfig, looks like bit 0 is autoidle, bit 1 reset, bits 4-5
(oddly) seem to be idlemode, though any mode other than force-idle
(the reset default) behaves like no-idle.
Clkctrl register is at offset 0xa4.
To be honest I don't understand all the hwmod stuff well enough yet to
attempt a patch myself.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 08/13] usb: otg: hub: Notify OTG fsm when A device sets b_hnp_enable
On Tue, Apr 14, 2015 at 01:41:55PM +0300, Roger Quadros wrote:
This is the a_set_b_hnp_enable flag in the OTG state machine
diagram and must be set when the A-Host has successfully set
the b_hnp_enable feature of the OTG-B-Peripheral attached to it.
When this bit changes we kick our OTG FSM to make note of the
change and act accordingly.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/core/hub.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d7c3d5a..ab0d498 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -22,6 +22,7 @@
#include linux/usb/hcd.h
#include linux/usb/otg.h
#include linux/usb/quirks.h
+#include linux/usb/usb-otg.h
#include linux/workqueue.h
#include linux/mutex.h
#include linux/random.h
@@ -2270,6 +2271,9 @@ static int usb_enumerate_device_otg(struct usb_device
*udev)
can't set HNP mode: %d\n,
err);
bus-b_hnp_enable = 0;
+ } else {
+ /* notify OTG fsm about
a_set_b_hnp_enable */
+ usb_otg_kick_fsm(udev-bus-controller);
}
}
}
@@ -4244,8 +4248,13 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
*/
if (!hdev-parent) {
delay = HUB_ROOT_RESET_TIME;
- if (port1 == hdev-bus-otg_port)
+ if (port1 == hdev-bus-otg_port) {
hdev-bus-b_hnp_enable = 0;
+#ifdef CONFIG_USB_OTG
+ /* notify OTG fsm about a_set_b_hnp_enable change */
+ usb_otg_kick_fsm(hdev-bus-controller);
+#endif
+ }
}
/* Some low speed devices have problems with the quick delay, so */
--
2.1.0
Since the fsm has already kicked, the only thing we need is update
fsm.a_set_b_hnp_enable, but this flag is missing at current fsm
structure.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
From: Illia Smyrnov illia.smyr...@globallogic.com
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x4480, so correct offset is 0x80. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov illia.smyr...@globallogic.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/bus/omap_l3_noc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 95254585db86..a314d800f394 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -274,7 +274,7 @@ static struct l3_flagmux_data dra_l3_flagmux_clk1 = {
static struct l3_target_data dra_l3_target_data_clk2[] = {
{0x0, HOST CLK1,},
- {0x0, HOST CLK2,},
+ {0x80, HOST CLK2,},
{0xdead, L3_TARGET_NOT_SUPPORTED,},
{0x3400, SHA2_2,},
{0x0900, BB2D,},
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x OMAP2 common clock external fixed-clock registration
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote: On 17.04.2015 00:09, Michael Welling wrote: On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: On 16.04.2015 18:17, Michael Welling wrote: On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: On 04/15/2015 11:51 PM, Michael Welling wrote: On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote: [...] There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. Not sure how this ever worked. This has been in the code since the initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. What would be the proper error path? What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. So for every error return in the probe function and in the of si5351_dt_parse it needs to clk_put first right? See attached patch to see if we are on the same page. It should be noted that there are more deep rooted issues with the driver that I have noticed. For one the driver behaves differently if the debugging is on and when it is off. I guess you mean #define DEBUG in the driver? Yes. Here is what the kernel reports with debugging off: Do you have any measurement equipment to check what is actually set? Yes, I have an oscilloscope here at my desk. The reported numbers do not always correspond to the actual output in some cases. The ms2 output has appeared to stop working all together sometime whilest testing. I may have to solder a new chip on there. Could misconfiguration damage the chip? root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 59994 0 0 ms0 001249 0 0 clk0 001249 0 0 plla 00 59994 0 0 ms2 00 8219178 0 0 clk2 00 8219178 0 0 ms1 0094117646 0 0 clk1 0094117646 0 0 Here is what the kernel reports with debugging on: clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 884736000 0 0 ms0 0018432000 0 0 clk0 0018432000 0 0 Is this what you expect for clk0? Yes. plla
Re: AM335x OMAP2 common clock external fixed-clock registration
On 17.04.2015 00:09, Michael Welling wrote: On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: On 16.04.2015 18:17, Michael Welling wrote: On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: On 04/15/2015 11:51 PM, Michael Welling wrote: On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote: [...] There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. Not sure how this ever worked. This has been in the code since the initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. What would be the proper error path? What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. It should be noted that there are more deep rooted issues with the driver that I have noticed. For one the driver behaves differently if the debugging is on and when it is off. I guess you mean #define DEBUG in the driver? Here is what the kernel reports with debugging off: Do you have any measurement equipment to check what is actually set? root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 59994 0 0 ms0 001249 0 0 clk0 001249 0 0 plla 00 59994 0 0 ms2 00 8219178 0 0 clk2 00 8219178 0 0 ms1 0094117646 0 0 clk1 0094117646 0 0 Here is what the kernel reports with debugging on: clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 884736000 0 0 ms0 0018432000 0 0 clk0 0018432000 0 0 Is this what you expect for clk0? plla 00 897023997 0 0 ms2 0012287999 0 0 clk2 0012287999 0 0 ditto for clk2? ms1 00 140709646 0 0 clk1 00 140709646 0 0 This is wrong, I agree. Looks like round_rate()/recalc_rate() of msynth or clkout is broken with respect to non-pll-master clocks. I had a quick look at drivers/clk.c too, there has been a lot of churn in clk API since I last booted my device
Re: [RFC][PATCH v2 06/13] usb: hcd: Add hcd add/remove functions for OTG use
On Tue, Apr 14, 2015 at 01:41:53PM +0300, Roger Quadros wrote:
The existing usb_add/remove_hcd() functionality
remains unchanged for non-OTG devices. For OTG
devices they only register the HCD with the OTG core.
Introduce _usb_add/remove_hcd() for use by OTG core.
These functions actually add/remove the HCD.
Would you please explain why additional _usb_add/remove_hcd are needed?
Peter
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg.c | 14 +++---
drivers/usb/core/hcd.c | 24 ++--
include/linux/usb/hcd.h | 3 +++
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index e848e08..860e2e7 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -198,18 +198,18 @@ static int usb_otg_start_host(struct otg_fsm *fsm, int
on)
otgd-start_host(fsm, on);
/* start host */
- usb_add_hcd(otgd-primary_hcd.hcd, otgd-primary_hcd.irqnum,
- otgd-primary_hcd.irqflags);
+ _usb_add_hcd(otgd-primary_hcd.hcd, otgd-primary_hcd.irqnum,
+ otgd-primary_hcd.irqflags);
if (otgd-shared_hcd.hcd) {
- usb_add_hcd(otgd-shared_hcd.hcd,
- otgd-shared_hcd.irqnum,
- otgd-shared_hcd.irqflags);
+ _usb_add_hcd(otgd-shared_hcd.hcd,
+ otgd-shared_hcd.irqnum,
+ otgd-shared_hcd.irqflags);
}
} else {
/* stop host */
if (otgd-shared_hcd.hcd)
- usb_remove_hcd(otgd-shared_hcd.hcd);
- usb_remove_hcd(otgd-primary_hcd.hcd);
+ _usb_remove_hcd(otgd-shared_hcd.hcd);
+ _usb_remove_hcd(otgd-primary_hcd.hcd);
/* OTG device operations */
if (otgd-start_host)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..9a9c0f7 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/phy.h
+#include linux/usb/usb-otg.h
#include usb.h
@@ -2622,7 +2623,7 @@ static void usb_put_invalidate_rhdev(struct usb_hcd
*hcd)
* buffers of consistent memory, register the bus, request the IRQ line,
* and call the driver's reset() and start() routines.
*/
-int usb_add_hcd(struct usb_hcd *hcd,
+int _usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags)
{
int retval;
@@ -2827,6 +2828,17 @@ err_phy:
}
return retval;
}
+EXPORT_SYMBOL_GPL(_usb_add_hcd);
+
+int usb_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags)
+{
+ /* If OTG device, OTG core takes care of adding HCD */
+ if (usb_otg_register_hcd(hcd, irqnum, irqflags))
+ return _usb_add_hcd(hcd, irqnum, irqflags);
+
+ return 0;
+}
EXPORT_SYMBOL_GPL(usb_add_hcd);
/**
@@ -2837,7 +2849,7 @@ EXPORT_SYMBOL_GPL(usb_add_hcd);
* Disconnects the root hub, then reverses the effects of usb_add_hcd(),
* invoking the HCD's stop() method.
*/
-void usb_remove_hcd(struct usb_hcd *hcd)
+void _usb_remove_hcd(struct usb_hcd *hcd)
{
struct usb_device *rhdev = hcd-self.root_hub;
@@ -2911,6 +2923,14 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_invalidate_rhdev(hcd);
}
+EXPORT_SYMBOL_GPL(_usb_remove_hcd);
+
+void usb_remove_hcd(struct usb_hcd *hcd)
+{
+ /* If OTG device, OTG core takes care of stopping HCD */
+ if (usb_otg_unregister_hcd(hcd))
+ _usb_remove_hcd(hcd);
+}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
void
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 68b1e83..7993ae7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -433,7 +433,10 @@ extern void usb_put_hcd(struct usb_hcd *hcd);
extern int usb_hcd_is_primary_hcd(struct usb_hcd *hcd);
extern int usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags);
+extern int _usb_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags);
extern void usb_remove_hcd(struct usb_hcd *hcd);
+extern void _usb_remove_hcd(struct usb_hcd *hcd);
extern int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1);
struct platform_device;
--
2.1.0
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
