Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Tue, Oct 2, 2012 at 6:08 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote: On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown Why would that be helpful? Most platforms don't support DT at all, and I'm not sure how to put it correctly. All I'm trying to tell is mfd is a framework that exposes a set of API's to create and remove a device among others. If a mfd child device is not created using mfd API, it'll be unfair to expect that child be removed properly using mfd API. Like in this patch, the device is created using of_platform_populate (not a mfd API) but is removed using mfd_remove_devices (mfd API) [which should result in an abort]. That doesn't sound terribly clever, no, though it's not immediately clear to me if the non-clever bit is using mfd_remove_devices() or of_platform_populate(). This means mfd framework does not have an API to create a device from dt data or so do I think since of_platform_populate() is used. Thats why I suggested the idea of extending mfd_add_devices() (or adding a new API in mfd framework) to create child devices from dt data so that we'll have API's in mfd framework to both create and delete a device. The trouble that always exists with representing MFD children in DT is that unless you've got a usefully reusable IP block which is clearly separate from the chip integration you end up essentially just dumping the Linux data structures into DT which often doesn't leave you with something which describes the hardware. indeed! Thanks Kishon -- 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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar sourav.pod...@ti.com wrote: smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Tested on omap5430 evm with 3.6-rc6 custom kernel. Can we have this line in comment section and not in commit log? Cc: Samuel Ortiz sa...@linux.intel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- Changes since v2: - Change the cache type, max register assignment - remove of_device_table, since i2c based device gets probed according to i2c_device_id through dt. - Modify the remove function - Minor return patch cleanups. Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 12 drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 ++ 5 files changed, 291 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt new file mode 100644 index 000..6b492e8 --- /dev/null +++ b/Documentation/smsc_ece1099.txt @@ -0,0 +1,56 @@ +What is smsc-ece1099? +-- + +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion +or GPIO Expansion device. The device supports a keyboard +scan matrix of 23x8. The device is connected to a Master +via the SMSC BC-Link interface or via the SMBus. +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals +are multiplexed with GPIOs. + +Interrupt generation + + +Interrupts can be generated by an edge detection on a GPIO +pin or an edge detection on one of the bus interface pins. +Interrupts can also be detected on the keyboard scan interface. +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if +any bit in one of the Interrupt Status registers is 1 and +the corresponding Interrupt Mask bit is also 1. + +In order for software to determine which device is the source +of an interrupt, it should first read the Group Interrupt Status Register +to determine which Status register group is a source for the interrupt. +Software should read both the Status register and the associated Mask register, +then AND the two values together. Bits that are 1 in the result of the AND +are active interrupts. Software clears an interrupt by writing a 1 to the +corresponding bit in the Status register. + +Communication Protocol +-- + +- SMbus slave Interface + The host processor communicates with the ECE1099 device + through a series of read/write registers via the SMBus + interface. SMBus is a serial communication protocol between + a computer host and its peripheral devices. The SMBus data + rate is 10KHz minimum to 400 KHz maximum + +- Slave Bus Interface + The ECE1099 device SMBus implementation is a subset of the + SMBus interface to the host. The device is a slave-only SMBus device. + The implementation in the device is a subset of SMBus since it + only supports four protocols. + + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the + only valid SMBus protocols for the device. + +- BC-LinkTM Interface + The BC-Link is a proprietary bus that allows communication + between a Master device and a Companion device. The Master + device uses this serial bus to read and write registers + located on the Companion device. The bus comprises three signals, + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the + clock, BC_CLK, and the Companion device is the source for an + independent asynchronous interrupt signal, BC_INT#. The ECE1099 + supports BC-Link speeds up to 24MHz. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b1a1462..dedc874 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -385,6 +385,18 @@ config MFD_T7L66XB help Support for Toshiba Mobile IO Controller T7L66XB +config MFD_SMSC + bool Support for the SMSC ECE1099 series chips + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + help +If you say yes here you get support for the +ece1099 chips from SMSC. + +To compile this driver as a module, choose M here: the +module will be called smsc. *bool* attribute for MFD_SMSC, does not allow to select the driver as module. use *trisate* instead. + config MFD_TC6387XB bool Support Toshiba TC6387XB depends on ARM HAVE_CLK diff --git
Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi,
On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Oct 01, 2012 at 05:00:06PM +0530, ABRAHAM, KISHON VIJAY wrote:
On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Delete irrelevant context from your replies, it makes it much easier to
find new text.
+static int smsc_i2c_remove(struct i2c_client *i2c)
+{
+ struct smsc *smsc = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(smsc-dev);
IMO, this should have resulted in an abort (hint: see
mfd_remove_devices_fn()). Trying to do mfd_remove_devices without
mfd_add_devices(). Use device_for_each_child here to remove the
device.
No, this is not at all sensible - if there's an mfd_remove_devices()
function we really ought to be able to use it to remove the children.
If we can't do that we should fix the API usability, not open code the
same stuff in every user.
What makes more sense to me is extend mfd_add_devices to create child
devices from dt data. Then for removing devices, one can use
mfd_remove_devices().
Thanks
Kishon
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Oct 01, 2012 at 05:23:15PM +0530, ABRAHAM, KISHON VIJAY wrote: On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown No, this is not at all sensible - if there's an mfd_remove_devices() function we really ought to be able to use it to remove the children. If we can't do that we should fix the API usability, not open code the same stuff in every user. What makes more sense to me is extend mfd_add_devices to create child devices from dt data. Then for removing devices, one can use mfd_remove_devices(). Why would that be helpful? Most platforms don't support DT at all, and I'm not sure how to put it correctly. All I'm trying to tell is mfd is a framework that exposes a set of API's to create and remove a device among others. If a mfd child device is not created using mfd API, it'll be unfair to expect that child be removed properly using mfd API. Like in this patch, the device is created using of_platform_populate (not a mfd API) but is removed using mfd_remove_devices (mfd API) [which should result in an abort]. This means mfd framework does not have an API to create a device from dt data or so do I think since of_platform_populate() is used. Thats why I suggested the idea of extending mfd_add_devices() (or adding a new API in mfd framework) to create child devices from dt data so that we'll have API's in mfd framework to both create and delete a device. Thanks Kishon -- 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 6/6] usb: dwc3: core: add dt support for dwc3 core
Hi,
On Sun, Sep 30, 2012 at 10:17 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 28-09-2012 14:53, Kishon Vijay Abraham I wrote:
Added dwc3 support for dwc3 core and update the documentation with
device tree binding information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
[...]
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 08a5738..0c17a7a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
[...]
@@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_matach[] = {
I guess you meant 'of_dwc3_match' here and below?
indeed.. will re-post the patch..
Thanks
Kishon
--
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 v2 1/2] usb: phy: add a new driver for usb3 phy
Hi,
On Thu, Sep 27, 2012 at 7:48 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+ unsigned long rate;
+ struct clk *sys_clk;
+
+ sys_clk = clk_get(NULL, sys_clkin);
+ if (IS_ERR(sys_clk)) {
+ pr_err(%s: unable to get sys_clkin\n, __func__);
+ return -EINVAL;
+ }
+
+ rate = clk_get_rate(sys_clk);
+ rate = rate/100;
+ clk_put(sys_clk);
Actually, you're supposed to hold on to the struct clk all the time your
driver is making use of that - you're not supposed to drop it.
That has several advantages: if clk_get() fails, then you're failing
earlier on (when the driver is being probed) and when some event occurs.
Ok. Will post a patch fixing it.
Thanks
Kishon
--
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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Fri, Sep 28, 2012 at 4:18 AM, Cousson, Benoit b-cous...@ti.com wrote: On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. So how can we handle reg writes to control module until we have a control module driver. usb2 phy does not have a hwmod data for itself. Do you think we should add a new hwmod data for usb2 phy and use this in the usb2phy data node in the dts file? Thanks Kishon -- 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 1/6] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
Hi, On Fri, Sep 28, 2012 at 6:27 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Sep 28, 2012 at 06:23:10PM +0530, Kishon Vijay Abraham I wrote: Used of_platform_populate() to populate dwc3 core platform_device from device tree data. Since now the allocation of unique device id is handled be of_*, removed the call to dwc3_get_device_id. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I think it's best if you split the use of device_for_each_child() from this patch. So first do the device_for_each_child() part, then later use of_platform_populate(). I think it's better to have it both together as of_platform_populate will create the device and the device_for_each_child() part will delete it on error conditions and during driver removal. In this patch the first device_for_each_child() comes in error condition and it is not needed if we have not created the device using of_platform_populate. Thanks Kishon -- 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 2/6] usb: dwc3-omap: use runtime API's to enable clocks
Hi,
On Fri, Sep 28, 2012 at 6:28 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 28, 2012 at 06:23:11PM +0530, Kishon Vijay Abraham I wrote:
Before accessing any register, runtime API's should be invoked to enable
the clocks. runtime API's are added here to prevent abort during register
access.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34578de..6a0e17f 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
+#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
@@ -281,6 +282,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
omap-irq = irq;
omap-base = base;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret 0) {
+ dev_err(dev, get_sync failed with err %d\n, ret);
+ goto err1;
+ }
+
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
utmi_mode = of_get_property(node, utmi-mode, size);
@@ -354,6 +362,8 @@ err1:
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
{
device_for_each_child(pdev-dev, NULL, dwc3_remove_core);
+ pm_runtime_put(pdev-dev);
+ pm_runtime_disable(pdev-dev);
You're going to disable pm_runtime here, so it's better to use
pm_runtime_put_sync(), I guess ??
sure. Will post a patch fixing it.
Thanks
Kishon
--
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 4/6] usb: dwc3-omap: Add an API to write to dwc mailbox
Hi,
On Fri, Sep 28, 2012 at 6:29 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 28, 2012 at 06:23:13PM +0530, Kishon Vijay Abraham I wrote:
Add an API in the omap glue layer to write to the mailbox register which
can be used by comparator driver(twl). To pass the detection of the attached
device (signified by VBUS, ID) to the dwc3 core, dwc3 core has to write
to the mailbox regiter.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 59
+
include/linux/usb/dwc3-omap.h | 30 +
2 files changed, 89 insertions(+)
create mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index a1704c6..7ae4d73 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
+#include linux/usb/dwc3-omap.h
#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
@@ -126,6 +127,8 @@ struct dwc3_omap {
u32 dma_status:1;
};
+struct dwc3_omap *_omap;
+
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
return readl(base + offset);
@@ -136,6 +139,56 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
+void omap_dwc3_mailbox(enum omap_dwc3_vbus_id_status status)
all other functions are dwc3_omap_, let's keep it consistent.
Sure.
Thanks
Kishon
--
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 6/6] usb: dwc3: core: add dt support for dwc3 core
Hi, On Fri, Sep 28, 2012 at 6:32 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Sep 28, 2012 at 06:23:15PM +0530, Kishon Vijay Abraham I wrote: Added dwc3 support for dwc3 core and update the documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/dwc3.txt | 24 drivers/usb/dwc3/core.c| 14 -- 2 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt new file mode 100644 index 000..87d5eeb --- /dev/null +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -0,0 +1,24 @@ +SYNOPSIS DWC3 CORE + +DWC3- USB3 CONTROLLER + +Required properties: + - compatible: Should be synopsis,dwc3 synopsys and I think: - compatible: Must be synopsys,dwc3 reads a bit better. Will re-post this patch. Thanks Kishon -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Fri, Sep 28, 2012 at 8:42 PM, Cousson, Benoit b-cous...@ti.com wrote: On 9/28/2012 3:07 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Fri, Sep 28, 2012 at 4:18 AM, Cousson, Benoit b-cous...@ti.com wrote: On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. So how can we handle reg writes to control module until we have a control module driver. usb2 phy does not have a hwmod data for itself. Do you think we should add a new hwmod data for usb2 phy and use this in the usb2phy data node in the dts file? Now, I'm confused... didn't you already do that? What was the hwmod you added? That was in usb_otg_hs (musb glue for omap) for writing to MUSB mailbox. This is for usb2 phy for powering on/off the PHY. Thanks Kishon -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Thu, Sep 27, 2012 at 7:54 PM, Rob Herring robherri...@gmail.com wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Please find the discussion @ https://patchwork.kernel.org/patch/1415261/ Thanks Kishon -- 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] drivers: phy: add generic PHY framework
Hi,
On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde m...@pengutronix.de wrote:
On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
[...]
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What about adding a struct phy_res, doing so,m you don't need these
casts, and it's easier to add more pointers if needed.
Wont we still need to do the cast since you get only a void pointer.
Maybe I'm not getting you.
As res is a void pointer, no need to hast to to a struct phy_res
pointer, if you think that's unclean code, you can still cast it. But
IMHO the code is far more readable.
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+ int index = 0;
+ struct phy *phy;
^^
Please remove that stray space.
Sure.
+ struct phy_bind *phy_map = NULL;
+
+ list_for_each_entry(phy_map, phy_bind_list, list)
+ if (!(strcmp(phy_map-dev_name, dev_name(dev
+ index++;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-desc-of_node)
+ continue;
+
+ phy_map = phy_bind(dev_name(dev), index,
dev_name(phy-dev));
+ if (!IS_ERR(phy_map)) {
+ phy_map-phy = phy;
+ phy_map-auto_bind = true;
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+/**
+ * devm_phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres
data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, u8 index)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = phy_get(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
nitpick: when when if has { }, else should have, too.
Sure.
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * devm_phy_put - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+ int r;
+
+ r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+ dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * devm_of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ *
+ * Returns the phy driver associated with the given phandle value
Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
Hi,
On Wed, Sep 26, 2012 at 11:57 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev,
usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
sure, but you don't need to bail out. Print a warning message such as:
dev_dbg(pdev-dev, couldn't get refclk960m, trying without\n);
but then we'll get this debug message for omap4 which actually doesn't
need 960m clk.
Thanks
Kishon
--
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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. + +This is usually a subnode of ocp2scp to which it is connected. How is usb port to phy connection described? Currently the usb controller to phy connection is established only by type. We have a couple of patches being currently discussed in the list to establish the connection by phandle. https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework: devm_of_phy_get()) http://www.spinics.net/lists/linux-usb/msg69547.html Thanks Kishon -- 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: query on [PATCH 2/3] usb: otg: add device tree support to otg library
Hi, On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de wrote: Hi Afzal, On 09/25/2012 10:47 AM, Mohammed, Afzal wrote: This is a query regarding patch, usb: otg: add device tree support to otg library [1] It seems there is so far no consensus on this change. After I have posted this patch, Kishon had posted a better solution [2]. We discussed the patch, but he has not posted any updates since then. Do you have ideas to proceed on this ? is there something that I can help you to proceed on this ? I'm interested in to get these patches into the kernel soon. Kishon any news on this patch? Something like this would be required for USB support on beagle bone (AM335X), which has 2 phy's of same type. Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Will post the next version by this week. Thanks Kishon -- 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 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
Thanks
Kishon
--
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 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi, On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent ra...@rab.in wrote: 2012/9/6 Kishon Vijay Abraham I kis...@ti.com: All the PHY configuration other than VBUS, ID GND and OTG SRP are removed from twl6030. The phy configurations are taken care by the dedicated usb2 phy driver. So twl6030 is made as comparator driver for VBUS and ID detection. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the old non-dt support). Some patches are queued only for 3.7. In case you want to use MUSB please use these patches on linux-next.. [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries (from Benoit) [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) Pls note all these patches are queued for 3.7 Thanks Kishon -- 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 1/4] usb: phy: add a new driver for usb3 phy
Hi,
On Wed, Sep 19, 2012 at 8:11 PM, Marc Kleine-Budde m...@pengutronix.de wrote:
On 09/19/2012 01:30 PM, Kishon Vijay Abraham I wrote:
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 18 +
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb3.c | 369
+
include/linux/usb/omap_usb.h | 72
5 files changed, 469 insertions(+)
create mode 100644 drivers/usb/phy/omap-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..7c5fd89 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..353dc0c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_USB3
+ tristate OMAP USB3 PHY Driver
+ select USB_OTG_UTILS
+ help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..973b1e6 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
+obj-$(CONFIG_OMAP_USB3) += omap-usb3.o
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..4dc84ca
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,369 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb/omap_usb.h
+#include linux/of.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+static struct usb_dpll_params omap_usb3_dpll_params[NUM_SYS_CLKS] = {
+ {1250, 5, 4, 20, 0},/* 12 MHz */
+ {3125, 20, 4, 20, 0}, /* 16.8 MHz */
+ {1172, 8, 4, 20, 65537},/* 19.2 MHz */
+ {1250, 12, 4, 20, 0}, /* 26 MHz */
+ {3125, 47, 4, 20, 92843}, /* 38.4 MHz */
+};
+
+/**
+ * omap5_usb_phy_power - power on/off the serializer using control module
+ * @phy: struct omap_usb *
+ * @on: 0 to off and 1 to on based on powering on or off the PHY
+ *
+ * omap_usb3 can call this API to power on or off the PHY.
+ */
+static int omap5_usb_phy_power(struct
Re: [RFC PATCH] drivers: phy: add generic PHY framework
Hi, On Mon, Sep 17, 2012 at 6:50 AM, Chen Peter-B29397 b29...@freescale.com wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. What's an example of the same phy user binds to multiple phys? Single controller using multiple phys.. I only remembered that Felipe said there are two phy users for one single phy at omap5 that is both usb3 and sata uses the same phy. *index* is used when a single controller uses multiple phys. For example it could be used for dwc3 (usb3 controller) where it uses usb2 phy and usb3 phy. Thanks Kishon -- 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] drivers: phy: add generic PHY framework
Hi, On Fri, Sep 14, 2012 at 5:58 PM, Marc Kleine-Budde m...@pengutronix.de wrote: On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has information about the PHY and ops like init, exit, suspend, resume, poweron, shutdown. Some comments inside. While looking over the code, I was thinking why not abstract the phy with a bus in the linux kernel. The ethernet phys are on the mdio_bus, see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and bindings, well... have to think about it. Marc Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- This framework is actually intended to be used by all the PHY drivers in the kernel. Though it's going to take a while for that, I intend to migrate existing USB/OTG phy drivers to use this framework as we align on the design of this framework. Once I migrate these phy drivers, I'll be able to test this framework (I haven't tested this framework so far). I sent this patch early so as to get review comments and align on the design. Thanks :-) drivers/Kconfig |2 + drivers/Makefile|2 + drivers/phy/Kconfig | 13 ++ drivers/phy/Makefile|5 + drivers/phy/phy-core.c | 437 +++ include/linux/phy/phy.h | 181 6 files changed, 640 insertions(+) create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..8488818 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -152,4 +152,6 @@ source drivers/vme/Kconfig source drivers/pwm/Kconfig +source drivers/phy/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..63d6bbe 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -38,6 +38,8 @@ obj-y += char/ # gpu/ comes after char for AGP vs DRM startup obj-y+= gpu/ +obj-y+= phy/ + obj-$(CONFIG_CONNECTOR) += connector/ # i810fb and intelfb depend on char/agp/ diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig new file mode 100644 index 000..34f7077 --- /dev/null +++ b/drivers/phy/Kconfig @@ -0,0 +1,13 @@ +# +# PHY +# + +menuconfig GENERIC_PHY + tristate Generic PHY Support + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile new file mode 100644 index 000..9e9560f --- /dev/null +++ b/drivers/phy/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the phy drivers. +# + +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..c55446a --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,437 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2012 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/kernel.h +#include linux/export.h +#include linux/module.h +#include linux/err.h +#include linux/device.h +#include linux/slab.h +#include linux/of.h +#include linux/phy/phy.h + +static struct class *phy_class; +static LIST_HEAD(phy_list); +static DEFINE_MUTEX(phy_list_mutex); +static LIST_HEAD(phy_bind_list); + +static
Re: [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Hi, On Wed, Sep 12, 2012 at 3:58 AM, Paul Walmsley p...@pwsan.com wrote: Hi Kishon, Benoît, On Fri, 7 Sep 2012, Kishon Vijay Abraham I wrote: Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this ocp2scp module does not have any fck but does have a single opt_clock, it is added as the main_clk for ocp2scp. Also removed phy_48m as the optional clock since it is now made as the main clock. By this the driver need not enable/disable phy_48m clk separately and runtime_get/runtime_put will take care of that. Looking at this patch, it doesn't seem to make sense from a hardware point of view. If you look at the OMAP4430 TRM Rev. AE, Table 23-1166 Clocks and Resets, the 48MHz clock input is listed as an Optional functional clock. The main functional clock is listed as INIT_960M_FCLK, which according to the same TRM, Section 3.6.3.9.1 Overview, is an alias for the clock we call dpll_usb_clkdcoldo_ck. So if any clock should be the main functional clock in the hwmod data, shouldn't it be dpll_usb_clkdcoldo_ck? The goal with the hwmod data is/was to have it match the hardware. ... More to the point, I guess I don't see what the problem is with adding a few lines to the ocp2scp driver to control the phy_48m optional It should be added in omap-usb2 driver rather. clock via the clock framework. Is there some reason why you couldn't prepare enable it after the pm_runtime_get_*(), and disable and unprepare it before the pm_runtime_put_*() ? We have omap-usb2 driver that is used for both omap4 and omap5. But this 48m clock is used only in omap4. And we dint have any *main_clk* in the ocp2scp_usb_phy_hwmod. So in order avoid some checks in the omap-usb2 driver, we added 48m clk as the main clock of ocp2scp_usb_phy_hwmod. Thanks Kishon -- 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] arm/dts: omap: Add omap-usb2 dt data
Hi, On Tue, Sep 11, 2012 at 1:53 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Kishon, On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote: Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is connected to ocp2scp, omap-usb2 dt data is added as a child node of ocp2scp. Could you add more details about the omap-usb2? I think information about omap-usb2 driver is added in *usb: phy: add a new driver for omap usb2 phy.*. Do you want the same thing to be added here? You must update the Documentation binding with that compatible name. Yes. It's part of *usb: phy: add a new driver for omap usb2 phy.* Is it already part of the driver serie? The MUSB driver is referring to ti,musb-omap2430 only. Will correct the Documentation for MUSB. Thanks Kishon -- 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 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control
module,
omap2430 will handle the register writes to control module by itself.
So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
btw, that's not different than what's already in tree, the only
difference is that now hwmod knows about it...
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
sure, that's doable... Kishon, can you do this ASAP ? I want to send my
pull requests tomorrow at the latest.
Sure. Will send now.
Thanks
Kishon
--
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 v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
Hi,
On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,omap4-musb or ti,omap3-musb
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
reg and interrupt properties are missing here.
I would encourage to specify reg and interrupt properties in every
node getting newly added to the OMAP DTS files.
Sure. will add that in my next version.
Thanks
Kishon
--
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 v7 1/7] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Mon, Aug 6, 2012 at 6:37 PM, Kishon Vijay Abraham I kis...@ti.com wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 17 ++ drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c| 271 include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 7 files changed, 382 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt index d2fe064..bb0c7f4 100644 --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -8,3 +8,6 @@ properties: Sub-nodes: All the devices connected to ocp2scp are described using sub-node to ocp2scp +- usb2phy : + The binding details of usb2phy can be found in: + Documentation/devicetree/bindings/usb/omap-usb.txt The above two lines should be added in omap-ocp2scp.txt (this file was added as part of omap: add ocp2scp as a bus driver and is in linux-next). However this file is still not in Felipe's xceiv branch. So I'm not sure how I can get this patch merged in Felipe's tree without conflict. Thanks Kishon -- 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] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Hi, On Mon, Jul 2, 2012 at 2:25 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this ocp2scp module does not have any fck but does have a single opt_clock, it is added as the main_clk for ocp2scp. Also removed phy_48m as the optional clock since it is now made as the main clock. Cc: Benoît Cousson b-cous...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com If there is not any comments for this patch, can someone queue it. This is needed for musb to be functional with dt in omap4. Thanks Kishon -- 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 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
Hi, On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham I kis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com If there isn't any comments for this patch, can someone queue it up? Thanks Kishon -- 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 08/13] arm/dts: am33xx: Add dt data for usbss
Hi, On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu ravib...@ti.com wrote: From: Ajay Kumar Gupta ajay.gu...@ti.com Added device tree data for usbss on am33xx. There are two musb controllers on am33xx platform so have port0_mode and port1_mode additional data. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com One Signed-off-by: Ravi Babu would suffice :-) Thanks Kishon -- 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 v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: From: Santhapuri, Damodar damodar.santhap...@ti.com AM335x uses NOP transceiver driver and need to enable builtin PHY by writing into usb_ctrl register available in system control module register space. This is being added at musb glue driver layer untill a separate system control module driver is available. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Kishon, you were adding a real phy driver for OMAP's internal phy logic on one of your patches and I believe this will conflict with your changes, right ? Indeed. My final patch of that series removes some of the functions from omap_phy_internal.c (which was taken care in the phy driver). How does this look to you ? Is this at least correct ? I suppose the correct way would be to actually have the system control module driver which we have been waiting, right ? Correct. I think once we have the system control module driver in place, we'll have everything wrt control module register writes implemented in correct way. Thanks Kishon -- 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 v9 01/13] usb: musb: dsps: add phy control logic to glue
On Fri, Aug 31, 2012 at 6:49 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: From: Santhapuri, Damodar damodar.santhap...@ti.com AM335x uses NOP transceiver driver and need to enable builtin PHY by writing into usb_ctrl register available in system control module register space. This is being added at musb glue driver layer untill a separate system control module driver is available. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Kishon, you were adding a real phy driver for OMAP's internal phy logic on one of your patches and I believe this will conflict with your changes, right ? Indeed. My final patch of that series removes some of the functions from omap_phy_internal.c (which was taken care in the phy driver). How does this look to you ? Is this at least correct ? I suppose the correct way would be to actually have the system control module driver which we have been waiting, right ? Correct. I think once we have the system control module driver in place, we'll have everything wrt control module register writes implemented in correct way. So $SUBJECT will pretty much be thrown away once we have SCM driver, in that case it's best to wait a bit longer and apply this series once SCM driver is available and after your series too... you agree ? Yes. That would be better. Thanks Kishon -- 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] usb otg: TWL4030_USB depends on USB_MUSB_OMAP2PLUS in Kconfig
Hi, On Fri, Aug 24, 2012 at 12:57 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 23, 2012 at 10:38:44PM +0200, Peter Meerwald wrote: Signed-off-by: Peter Meerwald pme...@pmeerw.net I need a commit log explaining why we need to add this extra depend ;-) --- drivers/usb/otg/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..fefca18 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS Can you add this for twl6030 also? Thanks Kishon -- 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: [RESEND PATCH v4 0/2] omap: add ocp2scp as a bus driver
On Wed, Aug 22, 2012 at 6:04 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote: This patch series has been lying here for long. If no one has any comments on this patch series, can someone pick it up? I've added them now as a drivers/ocp2scp branch arm-soc and pulled them into the next/drivers topic branch. Thanks Arnd :-) -Kishon -- 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: linux 3.6-rc2, undefined reference to omap_musb_mailbox
Hi, On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. EXPORT_SYMBOL_GPL() should sort that out, right ? No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c. Thanks Kishon -- 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: linux 3.6-rc2, undefined reference to omap_musb_mailbox
Hi, On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. EXPORT_SYMBOL_GPL() should sort that out, right ? No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c. I see you're missing an extern on the function prototype (on the header). Not sure how modules.dep is generated, but maybe it needs the extern there. Can you check it out ? That isn't helping either. Thanks Kishon -- 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: linux 3.6-rc2, undefined reference to omap_musb_mailbox
Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. Thanks Kishon -- 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 v6 00/11] omap: musb: Add device tree support
On Mon, Aug 6, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:49PM +0530, Kishon Vijay Abraham I wrote: This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c When you send your next series, can you please split the stuff based on their dependencies or at least note here what depends on what ? I mean, I cannot take the DT patches without an Acked-by Grant and Tony, but the drivers themselves I could take queue them since they're already in good shape ;-) Maybe just start the series with patches without dependencies on one another, and the rest of the series would be ones that need to go together, or something. That'll help me ;-) Ok Felipe. Thanks Kishon -- 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi Felipe,
On Mon, Aug 6, 2012 at 2:19 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Aug 03, 2012 at 08:01:44PM +0530, ABRAHAM, KISHON VIJAY wrote:
+ return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ clk_disable(phy-wkupclk);
weird. I would expect the wakeup clock to be enabled on suspend and
disabled on resume. Isn't this causing any unbalanced disable warnings ?
Even I was expecting the wakeup clock to be enabled on suspend but if
we have this enabled coreaon domain is never
gated and core does not hit low power state. btw Why do think this is
unbalanced?
because you never do a clk_enable() on probe(), so on your first
suspend, you will disable the clock without having enabled it before,
no? Unless pm_runtime forces a runtime_resume() when you call
pm_runtime_enable()...
+static int omap_usb2_runtime_resume(struct device *dev)
+{
+ u32 ret = 0;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ ret = clk_enable(phy-wkupclk);
+ if (ret 0)
+ dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
+
+ return ret;
+}
+
+static const struct dev_pm_ops omap_usb2_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend,
omap_usb2_runtime_resume,
+ NULL)
only runtime ? What about static suspend ? We need this to work also
after a traditional echo mem /sys/power/state ;-)
The static suspend case is handled by users of this phy using
set_suspend hooks.
I'm not sure if that's too wise, what if your user enabled USB, but
for whatever reason loaded only the phy driver and not musb or dwc3. It
will fail, right ?
The enabling and disabling of phy is solely governed by usb controller
driver (musb/dwc3). So if you dont have musb/dwc3 loaded, the phy will
be for sure disabled.
Thanks
Kishon
--
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 2/2] OMAP4: otg: phy: remove uggly mdelay(200)
Hi, On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol ruslan.bilo...@ti.com wrote: The original issue with powering on the PHY (and using 200 ms delay after this) is not related to internal processes in the PHY but is in the incorrect charger detection feature usage. Now when it is fixed, we can safely remove this uggly So is this 200ms delay related to incorrect charger detection? How is it now fixed without the delay? Thanks Kishon -- 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 1/2] OMAP4: otg: phy: fix charger detection
Hi,
On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol ruslan.bilo...@ti.com wrote:
Charger detection feature is not correctly used
and thus makes some regressions if OTG was used in
the host mode. Charger detection takes 500 ms so
if some device is attached to the host after 500 ms
it will be suddenly resetted.
This feature is enabled by default after reset/cold boot
so always affects PHY usage. So finally this was wrongly
interpreted as phy requires 200ms to start.
After fixing this we can safely remove uggly mdelay after
powering on the PHY.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..a13a37c 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -42,12 +42,16 @@
#defineSESSEND BIT(3)
#defineIDDIG BIT(4)
+#define CONTROL_USB2PHYCORE0x620
+#define USB2PHY_DISCHGDET BIT(30)
+
static struct clk *phyclk, *clk48m, *clk32k;
static void __iomem *ctrl_base;
static int usbotghs_control;
int omap4430_phy_init(struct device *dev)
{
+ u32 usb2phycore;
ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
if (!ctrl_base) {
pr_err(control module ioremap failed\n);
@@ -56,6 +60,11 @@ int omap4430_phy_init(struct device *dev)
/* Power down the phy */
__raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ /* Disable charger detection by default */
+ usb2phycore = omap4_ctrl_pad_readl(CONTROL_USB2PHYCORE);
+ usb2phycore |= USB2PHY_DISCHGDET;
+ omap4_ctrl_pad_writel(usb2phycore, CONTROL_USB2PHYCORE);
Maybe I failed to understand correctly but the $subject says it
*fixes* charger detection but the patch *disables* charger detection.
-Kishon
--
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 v2 1/2] drivers: bus: add a new driver for omap-ocp2scp
Hi,
On Fri, Aug 3, 2012 at 6:50 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Jul 18, 2012 at 12:00:38PM +0530, Kishon Vijay Abraham I wrote:
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.
Cc: Felipe Balbi ba...@ti.com
If you fix (or change my mind) on the comment below, you can add:
Acked-by: Felipe Balbi ba...@ti.com
Also, I wonder who should be the one to take this. Who will be queueing
patches on this directory to mainline ?
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/bus/Kconfig| 15 +++
drivers/bus/Makefile |5 +
drivers/bus/omap-ocp2scp.c | 98
6 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
create mode 100644 drivers/bus/Kconfig
create mode 100644 drivers/bus/Makefile
create mode 100644 drivers/bus/omap-ocp2scp.c
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
new file mode 100644
index 000..d2fe064
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -0,0 +1,10 @@
+* OMAP OCP2SCP - ocp interface to scp interface
+
+properties:
+- compatible : Should be ti,omap-ocp2scp
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ranges : the child address space are mapped 1:1 onto the parent address
space
+- ti,hwmods : must be ocp2scp_usb_phy
+
+Sub-nodes:
+All the devices connected to ocp2scp are described using sub-node to ocp2scp
diff --git a/drivers/Kconfig b/drivers/Kconfig
index bfc9186..4fe1e4c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -2,6 +2,8 @@ menu Device Drivers
source drivers/base/Kconfig
+source drivers/bus/Kconfig
+
source drivers/connector/Kconfig
source drivers/mtd/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 2ba29ff..cac3819 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -5,6 +5,8 @@
# Rewritten to use lists instead of if-statements.
#
+obj-y+= bus/
+
# GPIO must come after pinctrl as gpios may need to mux pins etc
obj-y+= pinctrl/
obj-y+= gpio/
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
new file mode 100644
index 000..6270415
--- /dev/null
+++ b/drivers/bus/Kconfig
@@ -0,0 +1,15 @@
+#
+# Bus Devices
+#
+
+menu Bus devices
+
+config OMAP_OCP2SCP
+ tristate OMAP OCP2SCP DRIVER
+ help
+ Driver to enable ocp2scp module which transforms ocp interface
+ protocol to scp protocol. In OMAP4, USB PHY is connected via
+ OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
+ OCP2SCP.
+
+endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
new file mode 100644
index 000..0ec50bc
--- /dev/null
+++ b/drivers/bus/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the bus drivers.
+#
+
+obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
new file mode 100644
index 000..8c3db3a
--- /dev/null
+++ b/drivers/bus/omap-ocp2scp.c
@@ -0,0 +1,98 @@
+/*
+ * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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/module.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
+
+static int ocp2scp_remove_devices(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
+static int __devinit omap_ocp2scp_probe(struct
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi,
On Fri, Aug 3, 2012 at 6:57 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Jul 30, 2012 at 02:39:50PM +0530, Kishon Vijay Abraham I wrote:
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 17 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 280
let's move this to drivers/usb/phy/. I'll prepare a patch moving all phy
drivers to that directory after the OTG state machine is ready ;-)
Ok.
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..52f503b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,17 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB)+= twl4030-usb.o
obj-$(CONFIG_TWL6030_USB)+= twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV) += nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..026cb3c
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,280 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy companion driver should call this API passing the phy_companion
+ * filled with set_vbus and start_srp to be used by usb phy.
+ *
+ * For use by phy companion driver
+ */
+void omap_usb2_set_comparator(struct phy_companion *comparator)
+{
+ struct omap_usb *phy;
+ struct usb_phy *x =
Re: [PATCH v6 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi, On Fri, Aug 3, 2012 at 6:58 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:52PM +0530, Kishon Vijay Abraham I wrote: All the PHY configuration other than VBUS, ID GND and OTG SRP are removed from twl6030. The phy configurations are taken care by the dedicated usb2 phy driver. So twl6030 is made as comparator driver for VBUS and ID detection. Writing to control module which is now handled in omap2430.c should be removed once a driver for control module is in place. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This looks good for the time being. Do you think it has any hard dependencies on your new phy drivers, or can I apply this without those other patches ?? It has a hard dependency on usb2phy driver. Thanks Kishon -- 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 v6 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi, On Fri, Aug 3, 2012 at 6:59 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Jul 30, 2012 at 02:39:53PM +0530, Kishon Vijay Abraham I wrote: The mailbox register for usb otg in omap is present in control module. On detection of any events VBUS or ID, this register should be written to send the notification to musb core. Till we have a separate control module driver to write to control module, omap2430 will handle the register writes to control module by itself. So a new address space to represent this control module register is added to usb_otg_hs. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com this should come before previous patch, right ? Otherwise we will try to ioremap a resource which isn't passed down to driver. No ? right. Will change the order in my next series. Thanks Kishon -- 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 v6 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Hi, On Fri, Aug 3, 2012 at 7:01 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:54PM +0530, Kishon Vijay Abraham I wrote: Add device tree support for twl6030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This looks great too. I can take this without any dependencies on the rest of the series, I believe. Right ?? I think it might not apply cleanly without [PATCH v6 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2. Thanks Kishon -- 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 v6 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Hi, On Fri, Aug 3, 2012 at 7:02 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:56PM +0530, Kishon Vijay Abraham I wrote: Add device tree support for twl4030 usb driver. Update the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I think this also doesn't have dependency on the rest of the series and I could take this upstream. Right ? right. Thanks Kishon -- 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 v6 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
Hi, On Fri, Aug 3, 2012 at 7:06 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:40:00PM +0530, Kishon Vijay Abraham I wrote: All the unnessary functions in omap-phy-internal is removed. These functionality are now handled by omap-usb2 phy driver. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Tony Lindgren t...@atomide.com Great stuff. I'll take this when we agree on the omap-usb2 phy driver. Sure. Thanks Kishon -- 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 v6 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi, On Fri, Aug 3, 2012 at 7:04 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 30, 2012 at 02:39:58PM +0530, Kishon Vijay Abraham I wrote: Added device tree support for omap musb driver and updated the Documentation with device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This looks good and I think I can take this without any dependencies again. Correct ? correct. Thanks Kishon -- 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi, On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote: On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote: + writel(~PHY_PD, phy-control_dev); + /* XXX: add proper documentation for this delay */ + mdelay(200); Do you need this to be busy? This might be called from interrupt context. This delay was initially added in omap_phy_internal.c and I just inherited it. Thanks Kishon -- 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 04/11] usb: otg: nop: add support for multiple tranceiver
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
Re: [PATCH v3 07/11] usb: otg: nop: add dt support
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 2e5e889..102e7d8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
The *#else* part is not needed as your *of_match_ptr* will take care of it.
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
Thanks
Kishon
--
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: [PATCHv6] arm/dts: omap4-sdp: Add keypad data
Hi,
On Fri, Jul 13, 2012 at 8:27 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with 3.5-rc6 kernel.
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
This patch[1] was initially posted as a series.
The first patch[2] of the series is taken into
dmitry's input tree.
So, posting this as a independent patch .
[1]: https://lkml.org/lkml/2012/6/8/239
[2]: https://lkml.org/lkml/2012/6/1/75
Changes since v5:
Few key mappings were missed, added linux, keymap
data for those key mappings.
arch/arm/boot/dts/omap4-sdp.dts | 70
+++
arch/arm/boot/dts/omap4.dtsi|5 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..53ded54 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,6 +70,76 @@
gpios = gpio5 11 0; /* 139 */
};
};
+
+ keypad@4a31c000 {
I think you should drop the address in node name since it does not
have a reg property.
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x0012
+ 0x00010013
+ 0x00020014
+ 0x00030066
+ 0x0004003f
+ 0x000500f0
+ 0x00060017
+ 0x0007002a
+ 0x0120
+ 0x01010021
+ 0x01020022
+ 0x010300e7
+ 0x01040040
+ 0x010500f0
+ 0x01060025
+ 0x0107001c
+ 0x022d
+ 0x0201002e
+ 0x0202002f
+ 0x0203006b
+ 0x02040041
+ 0x020500f0
+ 0x02060034
+ 0x0207003a
+ 0x032c
+ 0x0301004e
+ 0x03020030
+ 0x0303003b
+ 0x03040042
+ 0x030500f0
+ 0x03060018
+ 0x03070039
+ 0x0411
+ 0x04010015
+ 0x04020016
+ 0x0403003c
+ 0x04040073
+ 0x040500f0
+ 0x04060026
+ 0x04070069
+ 0x051f
+ 0x05010023
+ 0x05020024
+ 0x0503003d
+ 0x05040043
+ 0x05050072
+ 0x05060032
+ 0x0507006a
+ 0x0610
+ 0x0601001e
+ 0x06020031
+ 0x0603009e
+ 0x0604000e
+ 0x060500f0
+ 0x06060019
+ 0x06070067
+ 0x0794
+ 0x07010095
+ 0x070200ca
+ 0x070300cb
+ 0x0704003e
+ 0x070500f0
+ 0x07060160
+ 0x0707006c ;
+ linux,input-no-autorepeat;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..11b72d2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -273,4 +273,9 @@
ti,needs-special-reset;
};
};
+
+ keypad@4a31c000 {
same comment here.
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
Thanks
Kishon
--
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 v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
On Thu, Jul 19, 2012 at 6:51 PM, Gupta, Ajay Kumar ajay.gu...@ti.com wrote:
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board
data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ok.
Thanks
Kishon
--
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 v2 02/11] arm/dts: omap: Add omap-usb2 dt data
Hi,
On Tue, Jul 17, 2012 at 5:57 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 17-07-2012 12:10, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bda5df3..4d2dcc1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@0x4a0ad080 {
There should be no 0x prefix here.
Ok. Will fix it.
Thanks
Kishon
--
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 2/2] arm/dts: omap4: Add ocp2scp data
Hi,
On Tue, Jul 17, 2012 at 6:06 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 16-07-2012 18:13, Kishon Vijay Abraham I wrote:
Add ocp2scp data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..bda5df3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,13 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ocp2scp@4a0ad000 {
reg property is absent, so why do you give the node name an address
postfix?
When I was initially developing, I had reg property populated. Those
info is now obtained from *ti,hwmods*. I'll resend the patch removing
it.
Thanks
Kishon
--
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 1/2] drivers: bus: add a new driver for omap-ocp2scp
+Arnd Bergmann
On Mon, Jul 16, 2012 at 7:43 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.
Cc: Felipe Balbi ba...@ti.com
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/bus/Kconfig| 15 +++
drivers/bus/Makefile |5 +
drivers/bus/omap-ocp2scp.c | 98
6 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
create mode 100644 drivers/bus/Kconfig
create mode 100644 drivers/bus/Makefile
create mode 100644 drivers/bus/omap-ocp2scp.c
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
new file mode 100644
index 000..d2fe064
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -0,0 +1,10 @@
+* OMAP OCP2SCP - ocp interface to scp interface
+
+properties:
+- compatible : Should be ti,omap-ocp2scp
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ranges : the child address space are mapped 1:1 onto the parent address
space
+- ti,hwmods : must be ocp2scp_usb_phy
+
+Sub-nodes:
+All the devices connected to ocp2scp are described using sub-node to ocp2scp
diff --git a/drivers/Kconfig b/drivers/Kconfig
index bfc9186..4fe1e4c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -2,6 +2,8 @@ menu Device Drivers
source drivers/base/Kconfig
+source drivers/bus/Kconfig
+
source drivers/connector/Kconfig
source drivers/mtd/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 2ba29ff..cac3819 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -5,6 +5,8 @@
# Rewritten to use lists instead of if-statements.
#
+obj-y += bus/
+
# GPIO must come after pinctrl as gpios may need to mux pins etc
obj-y += pinctrl/
obj-y += gpio/
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
new file mode 100644
index 000..6270415
--- /dev/null
+++ b/drivers/bus/Kconfig
@@ -0,0 +1,15 @@
+#
+# Bus Devices
+#
+
+menu Bus devices
+
+config OMAP_OCP2SCP
+ tristate OMAP OCP2SCP DRIVER
+ help
+ Driver to enable ocp2scp module which transforms ocp interface
+ protocol to scp protocol. In OMAP4, USB PHY is connected via
+ OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
+ OCP2SCP.
+
+endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
new file mode 100644
index 000..0ec50bc
--- /dev/null
+++ b/drivers/bus/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the bus drivers.
+#
+
+obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
new file mode 100644
index 000..8c3db3a
--- /dev/null
+++ b/drivers/bus/omap-ocp2scp.c
@@ -0,0 +1,98 @@
+/*
+ * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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/module.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
+
+static int ocp2scp_remove_devices(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
+static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct device_node *np = pdev-dev.of_node;
+
+ if (np) {
+ ret = of_platform_populate(np, NULL, NULL, pdev-dev);
+ if (ret) {
+
Re: [PATCH] OMAP4: 4430sdp: OTG: increase max allowed output current
Hi,
On Thu, Jul 12, 2012 at 6:55 PM, Ruslan Bilovol ruslan.bilo...@ti.com wrote:
TWL6030/32 that is used on 4430sdp board can deliver up to 200mA
for OTG port power supply in the HOST mode.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e17284..10223f5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -429,7 +429,7 @@ static struct platform_device *sdp4430_devices[]
__initdata = {
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_OTG,
- .power = 100,
+ .power = 200,
};
Shouldn't this change be made for omap4 panda as well.
Thanks
Kishon
--
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 v2 2/3] usb: musb: dsps: add phy control logic to glue
Hi,
On Wed, Jul 11, 2012 at 3:59 PM, Damodar Santhapuri x0132...@ti.com wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver is available.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
Changes from v0:
- Used platform_get_resource() instead of
platform_get_resource_byname()
based on Kishon's comment.
arch/arm/mach-omap2/board-ti8168evm.c |1 -
arch/arm/mach-omap2/omap_phy_internal.c | 35
arch/arm/plat-omap/include/plat/usb.h |5 +-
drivers/usb/musb/musb_dsps.c| 87
+--
4 files changed, 73 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index d4c8392..0c7c098 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -26,7 +26,6 @@
#include plat/usb.h
static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..d80bb16 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
-
-void ti81xx_musb_phy_power(u8 on)
-{
- void __iomem *scm_base = NULL;
- u32 usbphycfg;
-
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
- if (!scm_base) {
- pr_err(system control module ioremap failed\n);
- return;
- }
-
- usbphycfg = __raw_readl(scm_base + USBCTRL0);
-
- if (on) {
- if (cpu_is_ti816x()) {
- usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
- usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
- }
- } else {
- if (cpu_is_ti816x())
- usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
- usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
-
- }
- __raw_writel(usbphycfg, scm_base + USBCTRL0);
-
- iounmap(scm_base);
-}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 548a4c8..c2aa4ae 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
-extern void ti81xx_musb_phy_power(u8 on);
/* AM35x */
/* USB 2.0 PHY Control */
@@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
#define CONF2_DATPOL (1 1)
/* TI81XX specific definitions */
-#define USBCTRL0 0x620
-#define USBSTAT0 0x624
+#define MUSB_USBSS_REV_816X0x9
+#define MUSB_USBSS_REV_814X0xb
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 494772f..72eda64 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -115,9 +115,46 @@ struct dsps_glue {
struct platform_device *musb; /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
+ u32 __iomem *usb_ctrl;
+ u8 usbss_rev;
};
/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
I think this function should be added in your transceiver driver. I
don't see glue as an appropriate place for this.
+{
+ u32 usbphycfg;
+
+ usbphycfg = __raw_readl(glue-usb_ctrl);
+
+ if (on) {
+ if (glue-usbss_rev ==
Re: [PATCH 2/3] usb: musb: dsps: add phy control logic to glue
Hi,
On Tue, Jul 10, 2012 at 11:35 AM, Gupta, Ajay Kumar ajay.gu...@ti.com wrote:
Hi,
On Mon, Jul 9, 2012 at 7:18 PM, Damodar Santhapuri x0132...@ti.com
wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver is available.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |1 -
arch/arm/mach-omap2/omap_phy_internal.c | 35
arch/arm/plat-omap/include/plat/usb.h |5 +-
drivers/usb/musb/musb_dsps.c| 88
+--
4 files changed, 74 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-
omap2/board-ti8168evm.c
index d4c8392..0c7c098 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -26,7 +26,6 @@
#include plat/usb.h
static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-
omap2/omap_phy_internal.c
index d52651a..d80bb16 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
-
-void ti81xx_musb_phy_power(u8 on)
-{
- void __iomem *scm_base = NULL;
- u32 usbphycfg;
-
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
- if (!scm_base) {
- pr_err(system control module ioremap failed\n);
- return;
- }
-
- usbphycfg = __raw_readl(scm_base + USBCTRL0);
-
- if (on) {
- if (cpu_is_ti816x()) {
- usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
- usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN |
USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL |
USBPHY_DMOPBUFCTL);
- }
- } else {
- if (cpu_is_ti816x())
- usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
- usbphycfg |= USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN;
-
- }
- __raw_writel(usbphycfg, scm_base + USBCTRL0);
-
- iounmap(scm_base);
-}
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-
omap/include/plat/usb.h
index 548a4c8..c2aa4ae 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
-extern void ti81xx_musb_phy_power(u8 on);
/* AM35x */
/* USB 2.0 PHY Control */
@@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
#define CONF2_DATPOL (1 1)
/* TI81XX specific definitions */
-#define USBCTRL0 0x620
-#define USBSTAT0 0x624
+#define MUSB_USBSS_REV_816X0x9
+#define MUSB_USBSS_REV_814X0xb
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 0)
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 494772f..f7271c3 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -115,9 +115,46 @@ struct dsps_glue {
struct platform_device *musb; /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register
offsets */
struct timer_list timer;/* otg_workaround timer */
+ u32 __iomem *usb_ctrl;
+ u8 usbss_rev;
};
/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system
control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver
for
%s/seperate/separate
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+{
+ u32 usbphycfg;
+
+ usbphycfg = __raw_readl(glue-usb_ctrl);
How about using readl instead of __raw_readl here and below?
+
+ if
Re: [PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Hi,
On Tue, Jul 10, 2012 at 11:28 AM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 18
drivers/usb/otg/twl6030-usb.c | 45
++--
2 files changed, 50 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified.
First
+ interrupt number is the otg interrupt number that raises ID interrupts
when
+ the controller has to act as host and the second interrupt number is
the
+ usb interrupt number that raises VBUS interrupts when the controller
has to
+ act as device
+ - regulator :supply-name can be vusb or ldousb
+ -supply-name-supply : phandle to the regulator device tree node
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10;
+ regulator = vusb;
+ vusb-supply =vusb;
This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?
The original code was something like
if (twl-features TWL6025_SUBCLASS)
regulator_name = ldousb;
else
regulator_name = vusb;
I wasn't sure how to handle this *TWL6025_SUBCLASS* stuff.
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#define comparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb
*twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev =pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev =pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev=pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ err = of_property_read_string(np,
regulator,twl-regulator);
+ if (err 0) {
+ dev_err(pdev-dev, unable to get regulator\n);
+ return err;
+ }
Isn't there a better way for the driver to know which supply to use instead
of DT passing the supply name?
The problem I see is this same driver is used for twl6030 and twl6025
and the regulator used is different for these two chips (And I think
twl6025 will also use the same dt file as twl6030 as I don't see a
different file for 6025).
Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi,
On Tue, Jul 10, 2012 at 11:16 AM, Rajendra Nayak rna...@ti.com wrote:
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg =0x4a0ad080 0x58;
Don;t you need a 'ti,hwmods' entry for this one?
I don't think it needs one as it has nothing more than this one
address space. (it doesn't have sysconfig, doesn't have any prcm
register..).
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,273 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
Copyright (C) 2012? Same for the couple of headers below.
Will fix it.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham Ikis...@ti.com
+ *
+ * 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.
+ *
+ */
+
+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+ struct omap_usb *phy;
+ struct usb_otg *otg;
+ struct resource *res;
+
+ phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ dev_err(pdev-dev, unable to allocate memory for USB2
PHY\n);
+ return -ENOMEM;
+ }
+
+ otg = devm_kzalloc(pdev-dev, sizeof(*otg), GFP_KERNEL);
+ if (!otg) {
+ dev_err(pdev-dev, unable to allocate memory for USB
OTG\n);
+ return -ENOMEM;
+ }
+
+ phy-dev=pdev-dev;
+
+ phy-phy.dev= phy-dev;
+ phy-phy.label = omap-usb2;
+ phy-phy.set_suspend= omap_usb2_suspend;
+ phy-phy.otg= otg;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+ phy-control_dev_conf = devm_request_and_ioremap(pdev-dev, res);
+ if (phy-control_dev_conf == NULL) {
+ dev_err(pdev-dev, Failed to obtain io memory\n);
+ return -ENXIO;
+ }
+
+ phy-is_suspended = 1;
+ omap_usb_phy_power(phy, 0);
+
+ otg-set_host = omap_usb_set_host;
+ otg-set_peripheral = omap_usb_set_peripheral;
+ otg-set_vbus = omap_usb_set_vbus;
+ otg-start_srp = omap_usb_start_srp;
+ otg-phy=phy-phy;
+
+ phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
Why not just use clk_get()? What does devm_clk_get() do?
It just associates the clk with the device. So whenever the the driver
gets detached, the devres will take care to do a clk_put() of the
clock.
+ if (IS_ERR(phy-wkupclk)) {
+ dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
+ return PTR_ERR(phy-wkupclk);
+ }
+ clk_prepare(phy-wkupclk);
Ideally clk_prepare() is an extension of clk_enable() and is expected
to be used that way. Not to be clubbed with clk_get(). Same with
clk_unprepare(). Do you do a clk_enable()/_disable() in interrupt/
atomic context?
Currently it is called from a work queue. But Felipe wanted to remove
those work_queue from omap2430 glue. Then this would be called from
atomic context.
A query for you here. If pm_runtime_get_sync() is called in interrupt
context, will runtime resume of that device will also be called in the
same context?
+
+ usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
+
+ platform_set_drvdata(pdev, phy);
+
+ pm_runtime_enable(phy-dev);
+
+ return 0;
+}
+
+static int __devexit omap_usb2_remove(struct platform_device *pdev)
+{
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ clk_unprepare(phy-wkupclk);
+ usb_remove_phy(phy-phy);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy =
Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi,
On Tue, Jul 10, 2012 at 11:33 AM, Venu Byravarasu
vbyravar...@nvidia.com wrote:
+
+#ifdef CONFIG_PM
Should it not be CONFIG_PM_SLEEP instead of just CONFIG_PM?
Why? I think we should have CONFIG_PM_SLEEP only when we have
*suspend*, *resume* hooks. But this driver has only *runtime_suspend*
and *runtime_resume* hooks.
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+static int __init usb2_omap_init(void)
+{
+ return platform_driver_register(omap_usb2_driver);
+}
+arch_initcall(usb2_omap_init);
+
+static void __exit usb2_omap_exit(void)
+{
+ platform_driver_unregister(omap_usb2_driver);
+}
+module_exit(usb2_omap_exit);
+
Do you really need arch_initcall here?
If not, then you can replace above two function calls with
module_platform_driver().
I indeed want it to be arch_initcall. When the module is built-in, I
want this module to loaded before twl6030-usb.c
Thanks
Kishon
--
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 v1 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Hi,
On Tue, Jul 10, 2012 at 11:32 AM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add device tree support for twl6030 usb driver.
twl4030?
My bad. Will fix it.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 +
drivers/usb/otg/twl4030-usb.c | 28
+++
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index f293271..2d069e4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -16,3 +16,22 @@ twl6030-usb {
regulator = vusb;
vusb-supply =vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified.
First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ -supply-name-supply : phandle to the regulator device tree node.
+supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
Are these standard usb phy modes or something specific to the twl4030
usb phy?
These are standard modes used to connect the phy to the controller. I
think it's used by other chips other than twl4030 (Something in
am35xx??).
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4;
+ vusb1v5-supply =vusb1v5;
+ vusb1v8-supply =vusb1v8;
+ vusb3v1-supply =vusb3v1;
+ usb_mode =1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..a4e7434 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without
pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev=pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,23 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#else
+#define twl4030_usb_id_table NULL
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = twl4030_usb_id_table,
use of_match_ptr().
Ok. Will change it that way.
Thanks
Kishon
--
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 v1 08/11] arm/dts: Add twl4030-usb data
Hi,
On Tue, Jul 10, 2012 at 11:43 AM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi
b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..66534a3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt =315;
};
+ vusb1v5: regulator@3 {
+ compatible = ti,twl4030-vusb1v5;
+ };
These @3, @4 are actually wrong since the node do
not have a 'reg' property in it. This was commented on
by David Brown on my original series which added this but
it somehow slipped through the cracks. I understand that
you would have looked up what existed in the file and
extended, but what already exists in the file needs to
be fixed up too. I'll send in a patch to fix those up.
Ok. i'll follow suit :-)
Thanks
Kishon
--
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 v1 10/11] arm/dts: omap: Add usb_otg and glue data
Hi,
On Tue, Jul 10, 2012 at 11:57 AM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type =0;
+ mode =3;
+ power =50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts
b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg =0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type =0;
+ mode =3;
+ power =50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..2f565d6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
this compatible doesn't seem right in omap3.dtsi. Same with
the below entry in omap4.dtsi.
See other IP blocks which are reused across OMAP2/3/4 on
how the compatible for those are handled.
Ok. So it should be like *ti,omap4-musb*, *ti,omap3-musb*?
Thanks
Kishon
--
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 v1 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
Hi,
On Tue, Jul 10, 2012 at 11:59 AM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbiba...@ti.com
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Acked-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138
---
arch/arm/mach-omap2/twl-common.c|5 -
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 0 insertions(+), 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#includeplat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
Just checking, but I hope your new driver handles this too.
You might not see any issues with it now, but not doing this could
gate OMAP hitting low power in idle.
I power down the phy during probe in omap-usb2 phy driver.
Thanks
Kishon
--
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 v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Hi,
On Tue, Jul 10, 2012 at 12:14 PM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 10 July 2012 11:58 AM, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Tue, Jul 10, 2012 at 11:28 AM, Rajendra Nayakrna...@ti.com wrote:
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 18
drivers/usb/otg/twl6030-usb.c | 45
++--
2 files changed, 50 insertions(+), 13 deletions(-)
create mode 100644
Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified.
First
+ interrupt number is the otg interrupt number that raises ID
interrupts
when
+ the controller has to act as host and the second interrupt number is
the
+ usb interrupt number that raises VBUS interrupts when the controller
has to
+ act as device
+ - regulator :supply-name can be vusb or ldousb
+ -supply-name-supply : phandle to the regulator device tree node
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10;
+ regulator = vusb;
+ vusb-supply =vusb;
This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?
The original code was something like
if (twl-features TWL6025_SUBCLASS)
regulator_name = ldousb;
else
regulator_name = vusb;
I wasn't sure how to handle this *TWL6025_SUBCLASS* stuff.
+};
diff --git a/drivers/usb/otg/twl6030-usb.c
b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#define comparator_to_twl(x) container_of((x), struct
twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1,
TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb
*twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev =pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev =pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev=pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ err = of_property_read_string(np,
regulator,twl-regulator);
+ if (err 0) {
+ dev_err(pdev-dev, unable to get
regulator\n);
+ return err;
+ }
Isn't there a better way for the driver to know which supply to use
instead
of DT passing the supply name?
The problem I see is this same driver
Re: [PATCH v3 4/7] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
+Ajay
On Thu, Jun 28, 2012 at 10:28 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Hello,
On Wed, Jun 27, 2012 at 10:05:00PM +0400, Konstantin Baydarov wrote:
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module
driver, they use
their own functions to acess scm registers.
- Parent SCM platform device IOMEM resources is used to get the base address
of SCM window.
- SCM Dependency was removed from Kconfig.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/usb/otg/Kconfig | 12 +++
drivers/usb/otg/Makefile | 1 +
drivers/usb/otg/omap4-usb-phy.c | 170
+
include/linux/usb/omap4_usb_phy.h | 53
4 files changed, 236 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/omap4-usb-phy.c
create mode 100644 include/linux/usb/omap4_usb_phy.h
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..0ed691b 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,18 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate Texas Instruments OMAP4+ USB pin control driver
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..60c8c83 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY) += omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV) += nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi_viewport.o
diff --git a/drivers/usb/otg/omap4-usb-phy.c
b/drivers/usb/otg/omap4-usb-phy.c
new file mode 100644
index 000..cbea2ea
--- /dev/null
+++ b/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,170 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ * Kishon Vijay Abraham I kis...@ti.com
+ * Eduardo Valentin eduardo.valen...@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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/usb/omap4_usb_phy.h
+
+void __iomem *omap_usb_phy_base;
+spinlock_t omap_usb_phy_lock;
+
+static int omap_usb_phy_readl(u32 reg, u32 *val)
+{
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ *val = __raw_readl(omap_usb_phy_base + reg);
+ return 0;
+}
+
+/*
+ * TODO: Get rid from omap_usb_phy_writel() return value -
+ * It's useless.
if you do that remember to keep a WARN_ON in case the base address is not set.
+ */
+static int omap_usb_phy_writel(u32 val, u32 reg)
+{
+ unsigned long flags;
+
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+
Re: [PATCH 2/3] usb: musb: dsps: add phy control logic to glue
Hi,
On Mon, Jul 9, 2012 at 7:18 PM, Damodar Santhapuri x0132...@ti.com wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver is available.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |1 -
arch/arm/mach-omap2/omap_phy_internal.c | 35
arch/arm/plat-omap/include/plat/usb.h |5 +-
drivers/usb/musb/musb_dsps.c| 88
+--
4 files changed, 74 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index d4c8392..0c7c098 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -26,7 +26,6 @@
#include plat/usb.h
static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..d80bb16 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
-
-void ti81xx_musb_phy_power(u8 on)
-{
- void __iomem *scm_base = NULL;
- u32 usbphycfg;
-
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
- if (!scm_base) {
- pr_err(system control module ioremap failed\n);
- return;
- }
-
- usbphycfg = __raw_readl(scm_base + USBCTRL0);
-
- if (on) {
- if (cpu_is_ti816x()) {
- usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
- usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
- }
- } else {
- if (cpu_is_ti816x())
- usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
- usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
-
- }
- __raw_writel(usbphycfg, scm_base + USBCTRL0);
-
- iounmap(scm_base);
-}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 548a4c8..c2aa4ae 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
-extern void ti81xx_musb_phy_power(u8 on);
/* AM35x */
/* USB 2.0 PHY Control */
@@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
#define CONF2_DATPOL (1 1)
/* TI81XX specific definitions */
-#define USBCTRL0 0x620
-#define USBSTAT0 0x624
+#define MUSB_USBSS_REV_816X0x9
+#define MUSB_USBSS_REV_814X0xb
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 494772f..f7271c3 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -115,9 +115,46 @@ struct dsps_glue {
struct platform_device *musb; /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
+ u32 __iomem *usb_ctrl;
+ u8 usbss_rev;
};
/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
%s/seperate/separate
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+{
+ u32 usbphycfg;
+
+ usbphycfg = __raw_readl(glue-usb_ctrl);
How about using readl instead of __raw_readl here and below?
+
+ if (on) {
+ if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ }
Re: [PATCH] omap: hwmod: add support to set dmadisable in hwmod framework
Hi, On Wed, Jul 4, 2012 at 4:46 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 9 May 2012, Kishon Vijay Abraham I wrote: The DMADISABLE bit is a semi-automatic bit present in sysconfig register of some modules. When the DMA must perform read/write accesses, the DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power management, software must set the DMADISABLE bit back to 1. In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the DMADISABLE bit (but the romcode/bootloader might not set it back to 1). In order for the kernel to start in a clean state, it is necessary for the kernel to set DMADISABLE bit back to 1 (irrespective of whether it's been set to 1 in romcode or bootloader). During _reset of the (hwmod)device, the DMADISABLE bit is set so that it does not prevent idling of the system. (NOTE: having DMADISABLE to 0, prevents the system to idle) DMADISABLE bit is present in usbotgss module of omap5. Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Thanks for the detailed comments and the kerneldoc. This one has been updated to apply and also to resolve some checkpatch warnings. Updated patch below. Thanks :-) -Kishon -- 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: [FYI/RFC] usb: musb: DMA doesn't work with nop PHYs
Hi, Couple of questions.. On Tue, Jul 3, 2012 at 4:08 AM, Mark A. Greer mgr...@animalcreek.com wrote: [The reason I'm sending this is that there is an issue but I probably won't be able to spend much time on it for a while. So, I'm sending it in case a) it helps someone else who bumps into it and b) someone else picks up and completes the fix.] Hello. In testing USB OTG Gadget on the am37x EVM with the mainline kernel I discovered that DMA doesn't work (but PIO does). When I tested the same kernel on the BeagleBoard-xM (BBxM), which has essentially the same SoC, it worked fine. They do have different OTG PHYs, though. The am37x EVM uses an ISP 1507 and the BBxM uses the PHY on the TPS65950 (twl4030). The different PHYs means that they use different drivers in drivers/usb/otg. The am37x EVM uses nop-usb-xceiv.c and the BBxM uses twl4030-usb.c. Where does the comparator (VBUS) exist in am37x? Who will be first interrupted when a cable is connected? Thanks Kishon -- 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 2/5] usb: musb: twl: use mailbox API to send VBUS or ID events
Hi Oleg,
On Tue, Jul 3, 2012 at 11:09 PM, Matcovschi, Oleg
oleg.matcovs...@ti.com wrote:
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] on
behalf of ABRAHAM, KISHON VIJAY
Sent: Friday, June 22, 2012 5:10 AM
To: gre...@linuxfoundation.org; ABRAHAM, KISHON VIJAY;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-...@vger.kernel.org; Balbi, Felipe
Subject: [PATCH v3 2/5] usb: musb: twl: use mailbox API to send VBUS or ID
events
The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events,
is replaced by a direct call to omap musb blue.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 94 +---
drivers/usb/otg/twl4030-usb.c | 46 ++--
drivers/usb/otg/twl6030-usb.c | 47 +---
include/linux/usb/musb-omap.h | 30 +
4 files changed, 133 insertions(+), 84 deletions(-)
create mode 100644 include/linux/usb/musb-omap.h
.
+enum omap_musb_vbus_id_status {
+ OMAP_MUSB_UNKNOWN = 0,
+ OMAP_MUSB_ID_GROUND,
+ OMAP_MUSB_ID_FLOAT,
+ OMAP_MUSB_VBUS_VALID,
+ OMAP_MUSB_VBUS_OFF,
+};
+
Why did you choose to introduce OMAP_MUSB specific VBUS, ID events?
IMHO, it makes more sense to introduce mailbox functionality only without
extra translation layer.
Same mailbox glue layer could be used for other PHY drivers, not just twl.
We've decided to make twl as a comparator driver since we have a
separate phy driver (not yet merged). Hence we dint want twl to use
usb_phy specific events. So if you have other PHY drivers, you can
still use the OMAP_MUSB specific events.
Thanks
Kishon
--
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: how to specify dma_mask and coherent_dma_mask in hwmod
Hi, On Wed, Jun 27, 2012 at 11:11 AM, N, Mugunthan V mugunthan...@ti.com wrote: -Original Message- From: N, Mugunthan V Sent: Thursday, June 07, 2012 9:52 PM To: 'linux-omap@vger.kernel.org' Cc: 'linux-arm-ker...@lists.infradead.org' Subject: how to specify dma_mask and coherent_dma_mask in hwmod Hi While converting platform device registry to Hwmod for CPSW Ethernet driver which is present in AM335X (OMAP2+), I am not finding a way to specify dma_mask and coherent_dma_mask. Is there a way to specify dma_mask and coherent_dma_mask in hwmod? Ping, any one has comment on this? Nope. You can specify dma_mask after creating the device as done in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/usb-musb.c;h=c4a576856661014ea3bec9acc70f80e32d62c33b;hb=HEAD Regards Kishon -- 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: [PATCHv11 3/6] i2c: omap: Do not initialise the completion everytime
Hi, On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: Use INIT_COMPLETION instead of init_completion in transfer. Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- - Add Felipe's reviewed-by tag drivers/i2c/busses/i2c-omap.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b9915bb..6d05f18 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -490,7 +490,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); - init_completion(dev-cmd_complete); + INIT_COMPLETION(dev-cmd_complete); dev-cmd_err = 0; w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ -999,6 +999,7 @@ omap_i2c_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, dev); + init_completion(dev-cmd_complete); It should be INIT_COMPLETION here too. Thanks Kishon -- 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 0/5] omap: add ocp2scp as a misc driver
Hi Kevin, On Tue, Jun 12, 2012 at 10:37 PM, Kevin Hilman khil...@ti.com wrote: ABRAHAM, KISHON VIJAY kis...@ti.com writes: Hi Kevin, Benoit, Paul, On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann a...@arndb.de wrote: On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I see. I'm not sure if with simple-bus we'll be able to do those. I have to check on that. How about making it compatible with both simple-bus and something that handles the pm_runtime requirements? I don't understand enough of what needs to be done for pm_runtime across a lot of devices, but I'd hope that it should be possible to do that in a generic way based on the device definition. Is there already exists a generic way for handling pm_runtime requirements (as simple as doing a pm_runtime_enable on a device). As you've discovered, the runtime PM core handles the parent/child relationships already. So the actual problem is we have ocp2scp as parent and usb2phy and usb3phy as the child device. ocp2scp has the sysconfig register and it can be controlled using module mode bit (both of this can be controlled by pm_runtime). Whenever usb controller(dwc3/musb) wants to enable a phy, it calls an exported API in usb2/usb3 phy to enable it. These API's have pm_runtime_get_sync on usb2/usb3 device which in-turn calls pm_runtime_get_sync of ocp2scp because of parent-child relationship (For this both usb2/usb3 phy and ocp2scp devices should have called pm_runtime_enable). All I'm trying is to find a place to have pm_runtime_enable for ocp2scp. Maybe I'm not following, but why can't it be in the driver? Arnd feels it is pointless to have a driver that only does creation of child (and pm_runtime_enable of the device). He feels it would be better to have a generic way to do a runtime_enable of a device with dt. (Just like how there is a generic way to create child devices by giving .compatible as simple-bus). Thanks Kishon -- 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 0/3] usb: musb: add new phy driver
Hi, On Tue, Jun 12, 2012 at 4:18 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 30, 2012 at 08:04:23PM +0530, Kishon Vijay Abraham I wrote: This series adds a new usb2 phy driver. The device for which is created by the ocp2scp driver. This also uses control module driver. This series converts twl6030 as a comparator driver (previously it was also the phy driver) and makes use of omap-usb2 as the phy driver. Instead of notification mechanism by power chip to omap glue to pass detection of any events, an export API has been added in omap glue. Both twl4030 and twl6030 will call to this API to pass any event. (twl6030 is used in omap4 and twl4030 is used in omap3). This series depends on: *[RFC PATCH 00/11] OMAP System Control Module* patch series However System Control Module driver has only dt support, so wouldn't be able to test this patch series. However I'll adapt omap usb2 phy driver and musb driver for dt and send it asap to the list. This series also depends on: *[PATCH v3 0/3] usb: multi-phy support* patch series *[RFC PATCH 0/5] omap: add ocp2scp as a misc driver* patch series Compile tested only. are we getting new version of this series ? Yes. I'm planning to send a new version with only dt support by next week. Thanks Kishon -- 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 0/5] omap: add ocp2scp as a misc driver
Hi Kevin, Benoit, Paul, On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann a...@arndb.de wrote: On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I see. I'm not sure if with simple-bus we'll be able to do those. I have to check on that. How about making it compatible with both simple-bus and something that handles the pm_runtime requirements? I don't understand enough of what needs to be done for pm_runtime across a lot of devices, but I'd hope that it should be possible to do that in a generic way based on the device definition. Is there already exists a generic way for handling pm_runtime requirements (as simple as doing a pm_runtime_enable on a device). So the actual problem is we have ocp2scp as parent and usb2phy and usb3phy as the child device. ocp2scp has the sysconfig register and it can be controlled using module mode bit (both of this can be controlled by pm_runtime). Whenever usb controller(dwc3/musb) wants to enable a phy, it calls an exported API in usb2/usb3 phy to enable it. These API's have pm_runtime_get_sync on usb2/usb3 device which in-turn calls pm_runtime_get_sync of ocp2scp because of parent-child relationship (For this both usb2/usb3 phy and ocp2scp devices should have called pm_runtime_enable). All I'm trying is to find a place to have pm_runtime_enable for ocp2scp. Thanks Kishon -- 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 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
Hi Benoit, On Wed, May 30, 2012 at 8:53 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Will you be sending a patch for *[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* also or I have to keep that as part of my series? Thanks Kishon -- 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 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
On Fri, Jun 1, 2012 at 6:54 PM, Cousson, Benoit b-cous...@ti.com wrote: On 6/1/2012 2:52 PM, ABRAHAM, KISHON VIJAY wrote: Hi Benoit, On Wed, May 30, 2012 at 8:53 PM, Cousson, Benoitb-cous...@ti.com wrote: On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Will you be sending a patch for *[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* also or I have to keep that as part of my series? Good point. In fact, I'm fixing both at the same time to avoid any bisect issue. Thanks :-) -Kishon -- 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 0/5] omap: add ocp2scp as a misc driver
Hi Arnd, On Thu, May 31, 2012 at 12:13 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 30 May 2012, Kishon Vijay Abraham I wrote: This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp to which phy drivers are connected. I'm planning to send phy drivers asap. Meanwhile I'd like to get some review comments for this series. I have also plans to send device tree adaptation of the ocp2scp driver. Developed on http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next If it has to be based on some other tree, please let me know. This must be the most pointless driver I've seen in a long time. It doesn't actually do anything at all, it just creates child devices from a static lookup table. Just put the devices you actually want into the device tree instead and have them automatically created. But shouldn't device tree support and non-device tree support co-exist till the non-device tree is completely knocked out of the kernel? Even then shouldn't there be a separate driver to extract the child nodes of ocp2scp and create a device (using of_platform_populate)? As far as I've seen, the devices are automatically created (by virtue of of_platform_populate() in mach-omap2/board-generic.c in omap case) only for the devices that is connected to the system bus. For other cases, the parent should be responsible for creating the child devices. Thanks Kishon -- 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 0/5] omap: add ocp2scp as a misc driver
Hi Arnd, On Thu, May 31, 2012 at 2:52 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: Just put the devices you actually want into the device tree instead and have them automatically created. But shouldn't device tree support and non-device tree support co-exist till the non-device tree is completely knocked out of the kernel? Even Well, it's a new driver, so there is no regression in supporting it only on DT-enabled boards. OMAP5 is DT-only anyway and OMAP4 only supports two boards that should both be working with the generic DT code already. then shouldn't there be a separate driver to extract the child nodes of ocp2scp and create a device (using of_platform_populate)? As far as I've seen, the devices are automatically created (by virtue of of_platform_populate() in mach-omap2/board-generic.c in omap case) only for the devices that is connected to the system bus. For other cases, the parent should be responsible for creating the child devices. I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I'm not sure if with simple-bus we'll be able to do those. I have to check on that. Thanks Kishon -- 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 RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Thanks Kishon -- 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 RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Hi Greg, On Fri, Mar 23, 2012 at 3:09 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Mar 23, 2012 at 03:04:04AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Read the version of that file in the 3.3 kernel release, it should explain what you are forgetting (hint, do you really want it applied to the 2.4 kernel tree?) I actually intended this patch to be back-ported to previous releases which will have the issue. I'm not sure if it is right? Thanks Kishon -- 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 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
Sergei,
Thanks for your comments.
On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence OTG_INTERFSEL is configured
to
ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or
USB_EVENT_VBUS notification.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Balaji T Kbalaj...@ti.com
AFAIK, full name is needed here.
is it not the prerogative of the person giving his signed-off by??
[sandesh.go...@ti.com: The interface selection has to be done before the
PHY
is activated and is not allowed to change when the PHY clock is already
running]
No signoff from him?
ok. will add his signoff.
---
drivers/usb/musb/omap2430.c | 50
+++---
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index fc9377c..724450b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,6 +228,7 @@ static inline void omap2430_low_level_init(struct musb
*musb)
static int musb_otg_notifications(struct notifier_block *nb,
unsigned long event, void *unused)
{
+ u32 val;
struct musb *musb = container_of(nb, struct musb, nb);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -240,11 +241,32 @@ static int musb_otg_notifications(struct
notifier_block *nb,
if (is_otg_enabled(musb)) {
if (musb-gadget_driver) {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs,
OTG_INTERFSEL);
+ if (data-interface_type ==
+
MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL,
val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
} else {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
@@ -255,6 +277,16 @@ static int musb_otg_notifications(struct
notifier_block *nb,
if (musb-gadget_driver)
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
break;
Why repeat the same sequence 3 times. Couldn't you factor it out into a
subroutine?
I thought it will be unnecessary to to add a subroutine just for a
single register modification.
Since you have pointed that out, I'll add a subroutine for it.
@@ -272,6 +304,11 @@ static int musb_otg_notifications(struct
notifier_block *nb,
otg_set_vbus(musb-xceiv-otg, 0);
}
usb_phy_shutdown(musb-xceiv);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ val |= ULPI_12PIN;
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
break;
default:
dev_dbg(musb-controller, ID float\n);
@@ -304,16 +341,11 @@ static int omap2430_musb_init(struct musb *musb)
goto err1;
}
+ /* Set OTG_INTERFSEL to ULPI for correct charger detection.
+ * This should be later set to UTMI.
+ */
l = musb_readl(musb-mregs, OTG_INTERFSEL);
-
- if (data-interface_type == MUSB_INTERFACE_UTMI) {
- /* OMAP4 uses Internal PHY GS70 which uses UTMI interface
*/
- l= ~ULPI_12PIN; /* Disable ULPI */
- l |= UTMI_8BIT; /*
Re: [PATCH] mfd: omap: cleanup: use macros to check for TLL mode
yes. I've mentioned it after the signed-off by section..
On Wed, Sep 14, 2011 at 8:11 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Wed, Sep 14, 2011 at 7:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
In one particular place the old form of checking for TLL mode is used.
This patch fixes the same by using macros to check for TLL mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
patch is created on top of runtime patches from keshava hsoted at
git://gitorious.org/~kmg/mirrors/kmg-usbhs-pm.git
branch:kmg-pm-1
drivers/mfd/omap-usb-host.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index e6f3b01..d43ca08 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -401,7 +401,7 @@ static void usbhs_omap_tll_init(struct device *dev, u8
tll_channel_count)
reg |= ohci_omap3_fslsmode(pdata-port_mode[i])
OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT;
reg |= OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS;
- } else if (pdata-port_mode[i] == OMAP_EHCI_PORT_MODE_TLL) {
+ } else if (is_ehci_tll_mode(pdata-port_mode[i])) {
/* Disable AutoIdle, BitStuffing and use SDR Mode */
reg = ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
--
1.7.0.4
is this rebased to my pm branch of runtime pm adaptations?
regards
keshava
--
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 2/5 v5] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Wed, Aug 17, 2011 at 5:13 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d7316b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,276 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
why do we need this terminating entry?
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk = l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk = usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters = omap34xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_ocp_if omap34xx_usbhs_ohci__l3_main_2 = {
+ .master = omap34xx_usbhs_ohci_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk =
Re: [PATCH v3 0/2] OMAP: omap_device: API to modify SYSCONFIG register
Paul, Benoit, Do you have any comments for this series? Regards Kishon On Mon, Jul 4, 2011 at 4:38 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain peripherals require autoidle bits to be disabled before performing some operations. This patch series provides APIs in omap_device layer and omap_hwmod layer to modify the SYSCONFIG register. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these APIs will support the same. For e.g McBSP 2 and 3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. McBSP also requires the SYSCONFIG to be in NOIDLE when ELEMENTSYNCH mode is selected for DMA operation. Created on top of linux OMAP master (linux-omap-2.6 :master) commit-id: d9be6df1331f8078618745298d38ed619729ec91 Tested on OMAP4430 and OMAP3430 SDP boards. Verified that this patch series does not break the OMAP1 build. V3: created one-one mapping between omap_device APIs and omap_hwmod APIs to modify the sysconfig register. V2: Mutex is replaced with spinlock. V1: * Creates 3 separate API's to change the idle mode to NOIDLE, SMARTIDLE and FORCEIDLE and one more API to change the idlemode to default value based on the hwmod flag. This change is done to align with the discussion on [3] * Added hwmod mutex in omap hwmod APIs that modifies SYSCONFIG register. * omap_hwmod_set_slave_idlemode() is not modified to take true/false kind-of argument since 3 states are associated with SIDLE bits (force, no and smart). These changes were made to align with Benoit's and Paul's comments for a similar patch written by Manjunath [1] for changing MSTANDBY bits. The discussions that happened for the RFC patch can be found at [2] [1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg39647.html [2]: https://patchwork.kernel.org/patch/134371/ [3]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg39615.html Kishon Vijay Abraham I (2): OMAP: omap_hwmod: API to modify AUTOIDLE and SMARTIDLE bits OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits arch/arm/mach-omap2/omap_hwmod.c | 93 ++ arch/arm/plat-omap/include/plat/omap_device.h | 6 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 11 ++ arch/arm/plat-omap/omap_device.c | 165 + 4 files changed, 275 insertions(+), 0 deletions(-) -- 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 10/12] omap: mcbsp: Move sidetone clock management to mach-omap2/mcbsp.c
On Fri, Jul 1, 2011 at 3:04 PM, Paul Walmsley p...@pwsan.com wrote: cc'ing Kishon On Fri, 1 Jul 2011, Cousson, Benoit wrote: On 7/1/2011 11:23 AM, Paul Walmsley wrote: On Fri, 1 Jul 2011, Jarkko Nikula wrote: Active sidetone requires that McBSP interface clock doesn't idle and there is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3 in OMAP34xx share their interface clock with McBSP sidetone module and that interface clock must be active when the sidetone is operating. Sidetone has its own autoidle bit which should keep the interface clock active but it is broken. Putting the McBSP core to no-idle mode when the sidetone is active is no good either since it results to higher power consumption when using the threshold based DMA transfers. In the hwmod code/data, we've got the OCPIF_SWSUP_IDLE flag that can be set on a struct omap_hwmod_ocp_if. I think this is probably what's needed here. The only problem is that we haven't linked that to the clock code to deny idle on the interface clock yet (see omap_hwmod.c:_setup()). Adding that code in, plus adding that OCPIF_SWSUP_IDLE flag to the McBSP2/3 data, seems like the right approach here. I guess we also will need some basic usecounting for denying idle in the clock code. Otherwise these direct register manipulations of clock registers, outside the clock code, could turn into a mess :-( AFAIR Kishon did submit some patches to expose this feature to the driver through omap_device API. The point is that other broken IP like SDMA of USB will require such feature. Didn't we pull them? I'll repost by early next week. You sent him some comments on March 1 but it looks like the series never got updated and reposted, at least not that I can find in my mail archive. Kishon? Anyway, those patches won't help in this case if the sidetone AUTOIDLE bit is broken - looks like the interface clock autoidle bit is what needs to change. - Paul -- 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: [HELP] Audio on BeagleBoard xM can't work
On Wed, Mar 16, 2011 at 9:09 AM, Bob Liu lliu...@gmail.com wrote: On Wed, Mar 16, 2011 at 12:21 AM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bob Liu Sent: Tuesday, March 15, 2011 3:27 PM To: Jarkko Nikula Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; l...@metafoo.de; p...@pwsan.com; peter.ujfal...@nokia.com Subject: Re: [HELP] Audio on BeagleBoard xM can't work On Tue, Mar 15, 2011 at 5:53 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Tue, 15 Mar 2011 11:12:17 +0800 Bob Liu lliu...@gmail.com wrote: It seems that the code in sound/soc/omap/omap-mcbsp.c uses the function cpu-is-omap343x() which fails and returns ENODEV. But I have enabled OMAP3430 support in System Type / TI OMAP2/3/4 Specific Features, why it still return ENODEV? (Attached my kernel config). And after I changed that check to cpu-is-omap34xx(), there was no error message but neither any audio output, I can't hear any sound. Is the DMA running after you change the cpu_is_omap34xx and try to play e.g. aplay /dev/urandom? If audio is running you should see DMA interrupt count increasing with grep DMA /proc/interrupts. Yes, DMA interrupt count increased after aplay /dev/urandom or some other audio file. Thanks If that is working then issue could be in codec side. I don't have a beagle at the moment to verify but IRCC something like ~10 TWL4030 ALSA controls must be adjusted in order to route audio from DAC to outputs at proper volume. I don't have HW with me right now, can you try the following? (Got the steps over phone from Abhilash) 1) run command alsamixer 2) Un-mute by pressing the key m 3) Play the audio using aplay If it doesn't work, you may want to check the options used by alsamixer. I will be able to try it myself tomorrow morning. Thanks for your reply. It seems pressing the key m has no effect during alsamixer and there are so many options I don't know how to adjust it. I've never tried playing audio in beagleboardxm but I've tried using 3430 SDP. You can try with the following settings. amixer cset name=HandsfreeR Switch 1 amixer cset name=HandsfreeR Mux 2 amixer cset name=HandsfreeL Switch 1 amixer cset name=HandsfreeL Mux 2 amixer cset name=DAC1 Analog Playback Switch 1 amixer cset name=DAC1 Analog Playback Volume 12 amixer cset name=DAC1 Digital Coarse Playback Volume 2 amixer cset name=DAC1 Digital Fine Playback Volume 50 amixer cset name=DAC2 Analog Playback Switch 1 amixer cset name=DAC2 Analog Playback Volume 12 amixer cset name=DAC2 Digital Coarse Playback Volume 2 amixer cset name=DAC2 Digital Fine Playback Volume 50 aplay -D plughw:0,0 -d 5 /mnt/mmc/beethoven.wav -Kishon -- Regards, --Bob -- 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 -- 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 v2 2/2] OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits
On Tue, Mar 1, 2011 at 4:47 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Kishon,
Sorry for this late reply.
I'm fine with this omap_device API which is well aligned with the discussion
we had. I just have few minor comments about the split omap_hwmod /
omap_device.
To summarize, you should not hack directly hwmod internal attributes from
the upper layer.
You should simply expose the same number of API at hwmod level instead of
relying on a single omap_hwmod_set_slave_idlemode with miscellaneous
parameters.
Should it then be like one-one mapping between omap_device APIs and
omap_hwmod APIs, or have a single omap_device API, that takes a additional
parameter and based on the parameter, call the appropriate omap_hwmod API?
On 1/31/2011 1:34 PM, ABRAHAM, KISHON VIJAY wrote:
Provide APIs to be used by the driver in order to modify AUTOIDLE
and SIDLE bits. These APIs in turn call hwmod APIs to modify the
SYSCONFIG register.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
---
arch/arm/plat-omap/include/plat/omap_device.h | 6 +
arch/arm/plat-omap/omap_device.c | 176
+
2 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..47ad0ab 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -110,6 +110,12 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od);
u32 omap_device_get_context_loss_count(struct platform_device *pdev);
/* Other */
+int omap_device_noidle(struct omap_device *od);
+int omap_device_smartidle(struct omap_device *od);
+int omap_device_forceidle(struct omap_device *od);
+int omap_device_default_idle(struct omap_device *od);
+int omap_device_enable_autoidle(struct omap_device *od);
+int omap_device_disable_autoidle(struct omap_device *od);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 57adb27..da8609a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -726,6 +726,182 @@ void __iomem *omap_device_get_rt_va(struct
omap_device *od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
}
+/**
+ * omap_device_noidle - set the device's slave idlemode to no idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to no idle.
+ * Intended to be used by drivers that have some erratum that requires
direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in
invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int omap_device_noidle(struct omap_device *od)
+{
+ int retval = 0, i;
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
+ WARN(1, omap_device: %s.%d: %s() called from invalid
state
+ %d\n, od-pdev.name, od-pdev.id, __func__,
+ od-_state);
+ return -EINVAL;
+ }
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ retval |= omap_hwmod_set_slave_idlemode(od-hwmods[i],
+ HWMOD_IDLEMODE_NO);
+
+ return retval;
+}
+
+
+/**
+ * omap_device_smartidle - set the device's slave idlemode to smart idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to smart idle.
+ * Intended to be used by drivers that have some erratum that requires
direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in
invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int omap_device_smartidle(struct omap_device *od)
+{
+ int retval = 0, i;
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
+ WARN(1, omap_device: %s.%d: %s() called from invalid
state
+ %d\n, od-pdev.name, od-pdev.id, __func__,
+ od-_state);
+ return -EINVAL;
+ }
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ retval |= omap_hwmod_set_slave_idlemode(od-hwmods[i],
+ HWMOD_IDLEMODE_SMART);
+
+ return retval;
+}
+
+
+/**
+ * omap_device_forceidle - set the device's slave idlemode to force idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to force idle.
+ * Intended to be used by drivers that have some erratum that requires
direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in
invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int
Re: [PATCH v3 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
On Thu, Feb 24, 2011 at 11:51 AM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote: On Thu, Feb 24, 2011 at 3:04 AM, Tony Lindgren t...@atomide.com wrote: * ABRAHAM, KISHON VIJAY kis...@ti.com [110223 02:11]: Created on top of linux OMAP master (linux-omap-2.6 :master) Does not look like that's the case. This does not seem to compile because of .name usage in omap_hwmod_addr_space. Also contains omap_device idle calls that we don't have merged either. McBSP hwmod and runtime patches depends on http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 to be compiled. Will you be merging this patch series? No yet. Please rebase on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 and make sure each patch compiles. I couldn't find that commit id on omap-for-linus :-(. Anyways, I did compile test applying my current patch series on top of HEAD (df7ffd317d36d36095c26bb57b3dd405274048e5) + API to modify SYSCONFIG patch series. Ok. I'll rebase on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 and send a new version. Regards Kishon 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: [PATCH v2 0/2] OMAP: omap_device: API to modify SYSCONFIG register
Hi Kevin, Paul, Benoit, Do you have any comments for this patch series? This series is necessary for McBSP hwmod and PM runtime patch series to be merged. Regards Kishon On Tue, Feb 15, 2011 at 12:08 PM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote: Kevin, Paul, Benoit, Do you have any comments for this patch series? -Kishon On Mon, Jan 31, 2011 at 6:04 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain peripherals require autoidle bits to be disabled before performing some operations. This patch series provides APIs in omap_device layer to modify the SYSCONFIG register. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these APIs will support the same. For e.g McBSP 2 and 3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. McBSP also requires the SYSCONFIG to be in NOIDLE when ELEMENTSYNCH mode is selected for DMA operation. Created on top of linux OMAP master (linux-omap-2.6 :master) Tested on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. V2: Mutex is replaced with spinlock. V1: * Creates 3 separate API's to change the idle mode to NOIDLE, SMARTIDLE and FORCEIDLE and one more API to change the idlemode to default value based on the hwmod flag. This change is done to align with the discussion on [3] * Added hwmod mutex in omap hwmod APIs that modifies SYSCONFIG register. * omap_hwmod_set_slave_idlemode() is not modified to take true/false kind-of argument since 3 states are associated with SIDLE bits (force, no and smart). These changes were made to align with Benoit's and Paul's comments for a similar patch written by Manjunath [1] for changing MSTANDBY bits. The discussions that happened for the RFC patch can be found at [2] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39647.html [2]: https://patchwork.kernel.org/patch/134371/ [3]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html Kishon Vijay Abraham I (2): OMAP: hwmod: API to handle autoidle mode OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits arch/arm/mach-omap2/omap_hwmod.c | 36 + arch/arm/plat-omap/include/plat/omap_device.h | 6 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/omap_device.c | 176 + 4 files changed, 219 insertions(+), 0 deletions(-) -- 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 v4 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
Thanks Tony. On Fri, Feb 25, 2011 at 12:41 AM, Tony Lindgren t...@atomide.com wrote: * Kishon Vijay Abraham I kis...@ti.com [110224 01:50]: Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs. Thanks, applied and pushed to devel-mcbsp branch for the upcoming merge window. 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: [PATCH v3 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
On Tue, Feb 22, 2011 at 1:01 PM, Peter Ujfalusi peter.ujfal...@nokia.com wrote: On 02/18/11 16:22, ext Kishon Vijay Abraham I wrote: Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs. Created on top of linux OMAP master (linux-omap-2.6 :master) Did digital loopback testing on OMAP4430, OMAP3430, OMAP2430 and OMAP 1710 SDP boards. Tested audio on 3430 SDP board (by me) and N810 (by Jarkko Nikula). Tested PM with audio and verified the patch series does not cause regression. PM testing comprises of suspend/resume between consecutive audio playback. Support for suspend/resume in the middle of audio playback will be done by audio guys on top of this patch series. Patch series requires the following patch to be present http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 I don't see further issues with this series. Since my ack is already in place on the patches, the only thing I can say is: Good work, thank you! Hi Tony, Will you be merging this patch series? -Kishon -- Péter -- 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 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
On Thu, Feb 24, 2011 at 3:04 AM, Tony Lindgren t...@atomide.com wrote: * ABRAHAM, KISHON VIJAY kis...@ti.com [110223 02:11]: Created on top of linux OMAP master (linux-omap-2.6 :master) Does not look like that's the case. This does not seem to compile because of .name usage in omap_hwmod_addr_space. Also contains omap_device idle calls that we don't have merged either. McBSP hwmod and runtime patches depends on http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 to be compiled. Will you be merging this patch series? No yet. Please rebase on omap-for-linus at commit 7cab8713b1ed0dab08ad6458f92a40b7ff4be619 and make sure each patch compiles. I couldn't find that commit id on omap-for-linus :-(. Anyways, I did compile test applying my current patch series on top of HEAD (df7ffd317d36d36095c26bb57b3dd405274048e5) + API to modify SYSCONFIG patch series. Regards Kishon 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: [alsa-devel] [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
Hi, I'll send patch series in a short while. -Kishon On Fri, Feb 18, 2011 at 1:38 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Thu, 17 Feb 2011 15:41:40 -0800 Tony Lindgren t...@atomide.com wrote: Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data definition. I think it's easiest if this patch just removes that conditional compilation from struct omap_mcbsp_platform_data as it really doesn't save that much from non !OMAP3 builds. Thanks. Will fix it in the next version. Any news on updating this series? Note that you can now leave out the omap4 hwmod data as that has been merged to omap-for-linus. My impression from last round was that there is not that many changes required. Of course there must not have bisect issues like above, should not break OMAP1 (which I think was addressed already) but otherwise I think most of the issues were small. Kevin had concerns about PM testing but I would not put that much emphasis on that since the set should not make things any worse but should make possible to go forward with PM. -- Jarkko -- 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 v2 0/2] OMAP: omap_device: API to modify SYSCONFIG register
Kevin, Paul, Benoit, Do you have any comments for this patch series? -Kishon On Mon, Jan 31, 2011 at 6:04 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain peripherals require autoidle bits to be disabled before performing some operations. This patch series provides APIs in omap_device layer to modify the SYSCONFIG register. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these APIs will support the same. For e.g McBSP 2 and 3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. McBSP also requires the SYSCONFIG to be in NOIDLE when ELEMENTSYNCH mode is selected for DMA operation. Created on top of linux OMAP master (linux-omap-2.6 :master) Tested on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. V2: Mutex is replaced with spinlock. V1: * Creates 3 separate API's to change the idle mode to NOIDLE, SMARTIDLE and FORCEIDLE and one more API to change the idlemode to default value based on the hwmod flag. This change is done to align with the discussion on [3] * Added hwmod mutex in omap hwmod APIs that modifies SYSCONFIG register. * omap_hwmod_set_slave_idlemode() is not modified to take true/false kind-of argument since 3 states are associated with SIDLE bits (force, no and smart). These changes were made to align with Benoit's and Paul's comments for a similar patch written by Manjunath [1] for changing MSTANDBY bits. The discussions that happened for the RFC patch can be found at [2] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39647.html [2]: https://patchwork.kernel.org/patch/134371/ [3]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html Kishon Vijay Abraham I (2): OMAP: hwmod: API to handle autoidle mode OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits arch/arm/mach-omap2/omap_hwmod.c | 36 + arch/arm/plat-omap/include/plat/omap_device.h | 6 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/omap_device.c | 176 + 4 files changed, 219 insertions(+), 0 deletions(-) -- 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 v2 01/13] OMAP: hwmod: Add member 'name' to omap_hwmod_addr_space struct
On Sat, Feb 5, 2011 at 3:46 AM, Kevin Hilman khil...@ti.com wrote:
Cousson, Benoit b-cous...@ti.com writes:
On 2/4/2011 8:45 PM, Hilman, Kevin wrote:
Kishon Vijay Abraham Ikis...@ti.com writes:
Adds a structure member 'name' to 'omap_hwmod_addr_space' structure.
The drivers can use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name so that it need not rely on the order to get
the proper resource.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 709543a..7bd4900 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1898,6 +1898,7 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
os = oh-slaves[i];
for (j = 0; j os-addr_cnt; j++) {
+ (res + r)-name = (os-addr + j)-name;
(res + r)-start = (os-addr + j)-pa_start;
(res + r)-end = (os-addr + j)-pa_end;
(res + r)-flags = IORESOURCE_MEM;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 76f0274..85899a7 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -178,7 +178,8 @@ struct omap_hwmod_omap2_firewall {
#define ADDR_TYPE_RT (1 1)
/**
- * struct omap_hwmod_addr_space - MPU address space handled by the hwmod
+ * struct omap_hwmod_addr_space - address space handled by the hwmod
Any reason you modified the comment here?
The idea of that patch is to allow hwmod to provide address space
accessible from SDMA (though L3). Hence the suppression of the MPU.
In the future, we might even be able to provide the address for the
DSP or the IPU viewpoint
OK, this rationale is missing from the changelog, and seems very much
unrelated to $SUBJECT patch.
ok. Will change it in the next version.
Kevin
--
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: [PATCHv2 1/2] ads7846: OMAP3: Removal of warnings backtrace in bootup
On Thu, Feb 3, 2011 at 4:42 PM, Igor Grinberg grinb...@compulab.co.il wrote:
On 02/03/11 13:00, Poddar, Sourav wrote:
On Thu, Feb 3, 2011 at 3:47 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
if (pdata-get_pendown_state) {
ts-get_pendown_state = pdata-get_pendown_state;
ts-gpio_pendown = -1;
return 0;
}
Yes we can do so .I initialise it at a place where other variables
where initialised.
Also, why don't we use -EINVAL for the invalid gpio number instead of -1
constant?
I used -1 because conditional check done in probe ads7846_probe function
used this value.
err_free_gpio:
if (ts-gpio_pendown != -1)
gpio_free(ts-gpio_pendown);
Well I understand that and that's why in my proposal I used -1 also, but
I thought we can make it even better if we switch to -EINVAL
(though wanted to check if there are any reasonable objections)
and while you are at this, may be you are willing also to submit a patch for
this?
I guess instead of -EINVAL, -EIO should be initialized to
ts-gpio_pendown since that
would be more appropriate for gpio and as Balbi suggested it would
be better to use
gpio_is_valid() for checking this error condition.
-Kishon
--
Regards,
Igor.
--
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
