[PATCH V2] ARM: dts: AM33xx: Add RNG node
Add the AM33xx RNG module's device tree data.
Also add Documentation file describing the data
for the RNG module.
Signed-off-by: Lokesh Vutla
---
Changes since V1:
- Drop "status=disabled" entry in dt node, Since
RNG is present on all AM33xx platforms.
.../devicetree/bindings/hwrng/omap_rng.txt | 22
arch/arm/boot/dts/am33xx.dtsi |7 +++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000..6a62acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ RNG versions:
+ - "ti,omap2-rng" for OMAP2.
+ - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+ Only used for "ti,omap4-rng".
+
+Example:
+/* AM335x */
+rng: rng@4831 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x4831 0x2000>;
+ interrupts = <111>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..26ebe30 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,12 @@
#size-cells = <1>;
status = "disabled";
};
+
+ rng: rng@4831 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x4831 0x2000>;
+ interrupts = <111>;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: AM33xx: Add RNG node
On Tuesday 06 August 2013 11:47 PM, Russ Dill wrote:
> On Tue, Aug 6, 2013 at 1:33 AM, Lokesh Vutla wrote:
>> Add the generic AM33xx RNG module's device tree data and
>> enable it for the am335x-evm, am335x-evmsk, and am335x-bone
>> platforms. Also add Documentation file describing the data
>> for the RNG module.
>>
>> Signed-off-by: Lokesh Vutla
>> ---
>> .../devicetree/bindings/hwrng/omap_rng.txt | 22
>>
>> arch/arm/boot/dts/am335x-bone.dts |4
>> arch/arm/boot/dts/am335x-evm.dts |4
>> arch/arm/boot/dts/am335x-evmsk.dts |4
>> arch/arm/boot/dts/am33xx.dtsi |8 +++
>> 5 files changed, 42 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
>> b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
>> new file mode 100644
>> index 000..6a62acd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
>> @@ -0,0 +1,22 @@
>> +OMAP SoC HWRNG Module
>> +
>> +Required properties:
>> +
>> +- compatible : Should contain entries for this and backward compatible
>> + RNG versions:
>> + - "ti,omap2-rng" for OMAP2.
>> + - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
>> + Note that these two versions are incompatible.
>> +- ti,hwmods: Name of the hwmod associated with the RNG module
>> +- reg : Offset and length of the register set for the module
>> +- interrupts : the interrupt number for the RNG module.
>> + Only used for "ti,omap4-rng".
>> +
>> +Example:
>> +/* AM335x */
>> +rng: rng@4831 {
>> + compatible = "ti,omap4-rng";
>> + ti,hwmods = "rng";
>> + reg = <0x4831 0x2000>;
>> + interrupts = <111>;
>> +};
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>> b/arch/arm/boot/dts/am335x-bone.dts
>> index 444b4ed..46a3887 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -234,3 +234,7 @@
>> pinctrl-0 = <&davinci_mdio_default>;
>> pinctrl-1 = <&davinci_mdio_sleep>;
>> };
>> +
>> +&rng {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>> b/arch/arm/boot/dts/am335x-evm.dts
>> index 3aee1a4..ebfbebe1 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -488,3 +488,7 @@
>> ti,adc-channels = <4 5 6 7>;
>> };
>> };
>> +
>> +&rng {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
>> b/arch/arm/boot/dts/am335x-evmsk.dts
>> index 0c8ad17..6610a05 100644
>> --- a/arch/arm/boot/dts/am335x-evmsk.dts
>> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
>> @@ -402,3 +402,7 @@
>> phy_id = <&davinci_mdio>, <1>;
>> phy-mode = "rgmii-txid";
>> };
>> +
>> +&rng {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 38b446b..b1e6205 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -530,5 +530,13 @@
>> #size-cells = <1>;
>> status = "disabled";
>> };
>> +
>> + rng: rng@4831 {
>> + compatible = "ti,omap4-rng";
>> + ti,hwmods = "rng";
>> + reg = <0x4831 0x2000>;
>> + interrupts = <111>;
>> + status = "disabled";
>
> Is there any point in making this default to "disabled"? Are there any
> am335x platforms where the trng doesn't function?
Yes, you are correct. Just followed how aes and sha are done.
ll update and send a v2.
Thanks and regards,
Lokesh
>
>> + };
>> };
>> };
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 11:19:14AM +0100, Russell King - ARM Linux wrote: > On Tue, Aug 06, 2013 at 06:15:27PM +0800, Greg Kroah-Hartman wrote: > > On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: > > > What would it take to move all this into driver core? > > > > What specifically would you move into there? > > A variable to hold the streaming dma_mask, so that its in struct device > rather than having to be separate. Yes, we can keep the pointer in there > too, because that appears to convey meaning in the kernel today - whether > the device can do DMA or not. > > A NULL dma_mask pointer already means it can't and dma_set_mask() always > fails. A non-NULL dma_mask pointer means the driver can use > dma_set_mask() to set an appropriate mask. Ok, that sounds fine to me, for some reason I thought I said yes to this a long time ago, did no one ever send me a patch for it? thanks, greg k-h -- 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] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 01:27:35PM +0300, Pantelis Antoniou wrote: > Hi Greg, > > On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: > > > On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: > >> Hi Greg, > >> > >> On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: > >> > >>> On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: > Platform device removal uncovered a number of problems with > the way resources are handled in the core platform code. > > Resources now form child/parent linkages and this requires > proper linking of the resources. On top of that the OF core > directly creates it's own platform devices. Simplify things > by providing helper functions that manage the linking properly. > >>> > >>> Ugh, the OF core shouldn't be creating platform devices. Well, yes, I > >>> know it does that today, but ick, ick, ick. > >>> > >> > >> Yep, ick, ick, ick is the correct form. > >> > Two functions are provided: > > platform_device_link_resources(), which links all the > linkable resources (if not already linked). > > and platform_device_unlink_resources(), which unlinks all the > resources. > >>> > >>> Why would anyone need to call this? I'm getting the feeling that OF > >>> should just have it's own bus of devices to handle this type of mess. > >>> ACPI is going through the same rewrite for this same type of problem > >>> (they did things differently.) I suggest you work with the ACPI > >>> developers to so the same thing they are, to solve it correctly for > >>> everyone. > >>> > >> > >> It's the same problem really. Another bus type might not fly well. > >> The same device driver should be (in theory) be made to work unchanged > >> either on an OF/ACPI/Fex( :) ) setup. > > > > No, that's not quite true, a driver needs to know how to talk to the > > bus, as that is how it communicates to the hardware. It can be done for > > different types of busses (see the OHCI USB controller for one example > > of this), but a driver will have to know what type of bus it is on in > > order to work properly. > > > > In the case of OF & ACPI there is no 'bus'. The device is probably integrated > in the SoC's silicon, but there is absolutely no way to 'probe' for it's > existence; > you have to use a-priori knowledge of the SoC's topology in order to > configure it > (along with any per-board specific information if there is any kind of shared > resource configuration - i.e. pinmuxing or something else). Not all busses need to have the aiblity to "probe" for new devices, that's not a requirement at all. Some of them just "know" where the devices are at in the driver model, and create the devices for the bus just fine. So don't think that just because of that lack of probing, they should be on the "platform" bus at all. Platform is for the "oh crap, I have no way to bind this to anything else, make it a platform device then." > There are the 3 well known methods to do so in the Linux kernel right now: > > 1) Board files in which the configuration information is stored in the > per-board > platform file encoded in platform data structures. > > 2) OF, in which case the information is provided via the flat device tree blob > the bootloader provides. > > 3) ACPI in which case the information is provided via the firmware's ACPI > tables > (I'm not overly familiar with ACPI, so there might be some more nuance here). > > The device driver for all these cases is absolutely the same; the only place > where > it differs it's in the way it uses to retrieve that configuration information. Not at all, they all should be differing in how to talk to the hardware, right? Or even if not, it should be pretty trivial for all of them to have drivers that bind to a multiple of different types of busses just fine, no need to want to abuse the platform code because people feel lazy. > > What specifically would you move into there? > > > > Pretty much everything that's in the union of platform_device & whatever > acpi uses to hold it's configuration info. Specifically what is that? I've never had a problem with moving stuff into struct device that is common among different subsystems that can share the pointers, as that is exactly what the structure is there for. thanks, greg k-h -- 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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 03:37:13PM +0200, Alexander Holler wrote: > Am 06.08.2013 12:14, schrieb Greg Kroah-Hartman: > > >> What exactly is a platform device anyway? > > > > Originally it was a "something that wasn't connected to a bus, but just > > had memory-mapped i/o." Like the PS2 keyboard controller. > > > > Embedded systems got ahold of this and went to town, and made everything > > a platform device because they could, and no one was paying attention. > > > > Then OF came along and used it as well, and you know the rest... > > > > I think we need to get the ACPI and OF people, and me, in a room > > together at the kernel summit and not let us out until we have this all > > worked out. > > MFD uses platform devices too. Ugh, I've been avoiding looking at mfd for a long time now, and really don't want to start now... -- 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: dwc3-pci: Ensure system sleep PM ops are defined only when used
Hi Mark,
On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown wrote:
> From: Andy Green
>
> You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
> case these are unused.
>
> Signed-off-by: Andy Green
> Signed-off-by: Mark Brown
What about doing this instead?
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -191,7 +191,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_id_table) = {
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int dwc3_pci_suspend(struct device *dev)
{
struct pci_dev *pci = to_pci_dev(dev);
@@ -216,15 +216,10 @@ static int dwc3_pci_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_SLEEP */
-static const struct dev_pm_ops dwc3_pci_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(dwc3_pci_suspend, dwc3_pci_resume)
-};
-
-#define DEV_PM_OPS (&dwc3_pci_dev_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(dwc3_pci_dev_pm_ops, dwc3_pci_suspend,
+dwc3_pci_resume);
static struct pci_driver dwc3_pci_driver = {
.name = "dwc3-pci",
@@ -232,7 +227,7 @@ static struct pci_driver dwc3_pci_driver = {
.probe = dwc3_pci_probe,
.remove = dwc3_pci_remove,
.driver = {
- .pm = DEV_PM_OPS,
+ .pm = &dwc3_pci_dev_pm_ops,
},
};
--
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
v3.11-rc4: OMAP1/Amstrad Delta (E3) crash
Hi, I get the following on Amstrad Delta (E3) when booting unpatched v3.11-rc4. The kernel config is after the crash. Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.11.0-rc4-e3 (aaro@blackmetal) (gcc version 4.7.3 (GCC) ) #4 PREEMPT Wed Aug 7 02:03:27 EEST 2013 [0.00] bootconsole [earlycon0] enabled [0.00] OMAP1510 [0.00] revision 2 handled as 15xx id: bc058c9b93111a16 [ serial garbage here deleted ] [0.238868] Installing fiq handler from c001b110, length 0x164 [0.245750] Unable to handle kernel paging request at virtual address 1224 [0.254789] pgd = c0004000 [0.258589] [1224] *pgd=, *pte=11fff0cb01f1, *ppte=11fff00a [0.267385] Internal error: Oops: 81f [#1] PREEMPT ARM [0.273164] Modules linked in: [0.276778] CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0-rc4-e3 #4 [0.283888] task: c183 ti: c1832000 task.ti: c1832000 [0.290049] PC is at memcpy+0x30/0x29c [0.294381] LR is at 0xe58c8018 [0.298063] pc : []lr : []psr: 2053 [0.298063] sp : c1833dfc ip : e3a08002 fp : c1833e34 [0.310828] r10: c0361390 r9 : c0379548 r8 : e59ca014 [0.316715] r7 : 0a07 r6 : e1ddd00b r5 : e59cd000 r4 : e59cb004 [0.323999] r3 : e59fc150 r2 : 0124 r1 : c001b130 r0 : 1224 [0.331280] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [0.339577] Control: 317f Table: 10004000 DAC: 0017 [0.346017] Process swapper (pid: 1, stack limit = 0xc18321b8) [0.352556] Stack: (0xc1833dfc to 0xc1834000) [0.357530] 3de0: 1388 [0.366725] 3e00: 0164 c035f4cc c1832000 1224 1224 c001317c fefecb4c [0.375917] 3e20: c001b110 0164 c1833ea4 c1833e38 c0365d38 c0013164 c031bb5c [0.385108] 3e40: c01b1868 c01ad448 c038d298 c037aa14 0005 c1833e7c c1833e68 [0.394301] 3e60: c01b1b74 c01b17c4 0003 0004 c1833ea4 c1833e80 c01b1bb0 c01b1b5c [0.403490] 3e80: 0003 c037a9e0 fffece10 c037a9e0 fffece10 c1833ebc c1833ea8 [0.412686] 3ea0: c0365b14 c0365ca0 c037d988 0003 c1833ecc c1833ec0 c03613b4 c0365a50 [0.421881] 3ec0: c1833f4c c1833ed0 c000894c c03613a0 c1833efc c1833ee0 c1833f04 c1833ee8 [0.431080] 3ee0: c035f4e8 c015f78c c035f400 c0422214 c02b963c 0063 c1833f4c c1833f08 [0.440272] 3f00: c00394d0 c035f4dc 0003 0003 c035d288 c0317ffc [0.449468] 3f20: c1833f4c c04221c0 c037d988 0003 c03afc20 c0379560 c0379548 0063 [0.458661] 3f40: c1833f94 c1833f50 c035fbb8 c000884c 0003 0003 c035f4cc a682efcf [0.467853] 3f60: 2e985504 8a8ea3ae 9c36fd4b c02a0d04 [0.477042] 3f80: c1833fac c1833f98 c02a0d14 c035fad8 [0.486229] 3fa0: c1833fb0 c000f550 c02a0d14 [0.495412] 3fc0: [0.504601] 3fe0: 0013 e1e33c31 54a846fd [0.513698] Backtrace: [0.516818] [] (set_fiq_handler+0x0/0x6c) from [] (ams_delta_init_fiq+0xa8/0x160) [0.527111] r6:0164 r5:c001b110 r4: r3:fefecb4c [0.533724] [] (ams_delta_init_fiq+0x0/0x160) from [] (ams_delta_init+0xd4/0x114) [0.543992] r6: r5:fffece10 r4:c037a9e0 [0.549439] [] (ams_delta_init+0x0/0x114) from [] (customize_machine+0x24/0x30) [0.559519] r5:0003 r4:c037d988 [0.563800] [] (customize_machine+0x0/0x30) from [] (do_one_initcall+0x110/0x178) [0.574231] [] (do_one_initcall+0x0/0x178) from [] (kernel_init_freeable+0xf0/0x1ac) [0.584993] [] (kernel_init_freeable+0x0/0x1ac) from [] (kernel_init+0x10/0xec) [0.595263] [] (kernel_init+0x0/0xec) from [] (ret_from_fork+0x14/0x24) [0.604609] r4: r3: [0.608826] Code: e92d01e0 ba03 e8b151f8 e2522020 (e8a051f8) [0.617082] ---[ end trace 016c1c3c0008 ]--- [0.623128] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.11.0-rc4 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_FIQ=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_NEED_MACH_MEMORY_H=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # #
[PATCHv3 5/8] ARM: dts: OMAP5: Add mailbox dt node
Add the mailbox device DT node for OMAP5 SoC.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..a08f1ca 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -505,6 +505,17 @@
dma-names = "tx", "rx";
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = ;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <3>;
+ ti,mbox-num-fifos = <8>;
+ ti,mbox-names = "mbox-ipu", "mbox-dsp";
+ ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+ };
+
timer1: timer@4ae18000 {
compatible = "ti,omap5430-timer";
reg = <0x4ae18000 0x80>;
--
1.8.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 8/8] ARM: dts: AM33xx: Add mailbox node
The mailbox DT node data has been added for AM33xx device, with
information added currently for communicating with WkupM3
processor. The usr_id value in the DT node reflects the value
used for MPU like the rest of the SoCs. The driver logic will
be adjusted to account for the WkupM3 usr_id within the code.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..413dfa56 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -249,6 +249,17 @@
status = "disabled";
};
+ mailbox: mailbox@480C8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480C8000 0x200>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <8>;
+ ti,mbox-names = "wkup_m3";
+ ti,mbox-data = <0 0 0 0>;
+ };
+
timer1: timer@44e31000 {
compatible = "ti,am335x-timer-1ms";
reg = <0x44e31000 0x400>;
--
1.8.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/8] mailbox/omap: add code to support the wkupm3 operations
The WkupM3 mailbox used for triggering PM operations such as suspend
and resume on AM33x/AM43x is special in that the M3 processor cannot
access the mailbox registers. However, an interrupt is needed to be
sent to request the M3 to perform a desired PM operation. This patch
adds the support for this special mailbox through separate ops for
this mailbox. These ops are designed to have the WkupM3's Rx interrupt
programmed within the driver, during transmission of a message. The
message is immediately read back and the internal mailbox interrupt
acknowledged as well to avoid triggering any spurious interrupts to
the M3.
Signed-off-by: Suman Anna
---
drivers/mailbox/mailbox-omap2.c | 87 -
1 file changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index fef18f4..00ac2a2 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -36,6 +36,8 @@
#define MAILBOX_IRQ_NEWMSG(m) (1 << (2 * (m)))
#define MAILBOX_IRQ_NOTFULL(m) (1 << (2 * (m) + 1))
+#define AM33X_MBOX_WKUPM3_USR 3
+
#define MBOX_REG_SIZE 0x120
#define OMAP4_MBOX_REG_SIZE0x130
@@ -179,6 +181,57 @@ static int omap2_mbox_is_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
+static void wkupm3_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ struct omap_mbox2_priv *p = mbox->priv;
+ u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+ unsigned long irqenable = ((irq == IRQ_RX) ?
+ OMAP4_MAILBOX_IRQENABLE(AM33X_MBOX_WKUPM3_USR) : p->irqenable);
+
+ l = mbox_read_reg(mbox->parent, irqenable);
+ l |= bit;
+ mbox_write_reg(mbox->parent, l, irqenable);
+}
+
+static void wkupm3_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t
irq)
+{
+ struct omap_mbox2_priv *p = mbox->priv;
+ u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+ unsigned long irqdisable = ((irq == IRQ_RX) ?
+ OMAP4_MAILBOX_IRQENABLE_CLR(AM33X_MBOX_WKUPM3_USR) : p->irqdisable);
+
+ mbox_write_reg(mbox->parent, bit, irqdisable);
+}
+
+static void wkupm3_mbox_ack_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ struct omap_mbox2_priv *p = mbox->priv;
+ u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+ unsigned long irqstatus = ((irq == IRQ_RX) ?
+ OMAP4_MAILBOX_IRQSTATUS(AM33X_MBOX_WKUPM3_USR) : p->irqstatus);
+
+ mbox_write_reg(mbox->parent, bit, irqstatus);
+
+ /* Flush posted write for irq status to avoid spurious interrupts */
+ mbox_read_reg(mbox->parent, irqstatus);
+}
+
+static int wkupm3_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ struct omap_mbox2_priv *p = mbox->priv;
+ u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+ u32 enable, status;
+
+ /* WkupM3 mailbox does not use a receive queue */
+ if (irq == IRQ_RX)
+ return 0;
+
+ enable = mbox_read_reg(mbox->parent, p->irqenable);
+ status = mbox_read_reg(mbox->parent, p->irqstatus);
+
+ return (int)(enable & status & bit);
+}
+
static void omap2_mbox_save_ctx(struct omap_mbox *mbox)
{
int i;
@@ -215,6 +268,20 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
}
}
+static void wkupm3_mbox_send_data(struct omap_mbox *mbox, mbox_msg_t msg)
+{
+ mbox_msg_t rmsg;
+
+ /* enable the mbox Rx interrupt for WkupM3 only briefly */
+ wkupm3_mbox_enable_irq(mbox, IRQ_RX);
+ omap2_mbox_fifo_write(mbox, msg);
+ wkupm3_mbox_disable_irq(mbox, IRQ_RX);
+
+ /* read back the message and ack the interrupt on behalf of WkupM3 */
+ rmsg = omap2_mbox_fifo_read(mbox);
+ wkupm3_mbox_ack_irq(mbox, IRQ_RX);
+}
+
static struct omap_mbox_ops omap2_mbox_ops = {
.startup= omap2_mbox_startup,
.shutdown = omap2_mbox_shutdown,
@@ -230,6 +297,21 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
};
+static struct omap_mbox_ops wkupm3_mbox_ops = {
+ .startup= omap2_mbox_startup,
+ .shutdown = omap2_mbox_shutdown,
+ .fifo_read = omap2_mbox_fifo_read,
+ .fifo_write = wkupm3_mbox_send_data,
+ .fifo_empty = omap2_mbox_fifo_empty,
+ .poll_for_space = omap2_mbox_poll_for_space,
+ .enable_irq = wkupm3_mbox_enable_irq,
+ .disable_irq= wkupm3_mbox_disable_irq,
+ .ack_irq= wkupm3_mbox_ack_irq,
+ .is_irq = wkupm3_mbox_is_irq,
+ .save_ctx = omap2_mbox_save_ctx,
+ .restore_ctx= omap2_mbox_restore_ctx,
+};
+
static const struct of_device_id omap_mailbox_of_match[] = {
{
.compatible = "ti,omap2-mailbox",
@@ -387,7 +469,10 @@ static int omap
[PATCHv3 6/8] mailbox/omap: remove omap_mbox_type_t from mailbox ops
The type definition omap_mbox_type_t used for distinguishing
OMAP1 from OMAP2+ mailboxes does not really belong to the
ops, and has been cleaned up.
Signed-off-by: Loic Pallardy
Signed-off-by: Suman Anna
---
drivers/mailbox/mailbox-omap1.c | 27 ---
drivers/mailbox/mailbox-omap2.c | 11 +--
drivers/mailbox/omap-mailbox.c | 26 --
drivers/mailbox/omap-mbox.h | 7 +--
4 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 5e38ffc..0f874e0 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "omap-mbox.h"
@@ -37,6 +38,7 @@ struct omap_mbox1_fifo {
struct omap_mbox1_priv {
struct omap_mbox1_fifo tx_fifo;
struct omap_mbox1_fifo rx_fifo;
+ bool empty_flag;
};
static inline int mbox_read_reg(size_t ofs)
@@ -59,6 +61,7 @@ static mbox_msg_t omap1_mbox_fifo_read(struct omap_mbox *mbox)
msg = mbox_read_reg(fifo->data);
msg |= ((mbox_msg_t) mbox_read_reg(fifo->cmd)) << 16;
+ (struct omap_mbox1_priv *)(mbox->priv)->empty_flag = false;
return msg;
}
@@ -74,7 +77,9 @@ omap1_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
static int omap1_mbox_fifo_empty(struct omap_mbox *mbox)
{
- return 0;
+ struct omap_mbox1_priv *priv = (struct omap_mbox1_priv *)mbox->priv;
+
+ return priv->empty_flag ? 0 : 1;
}
static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
@@ -85,6 +90,18 @@ static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
return mbox_read_reg(fifo->flag);
}
+static int omap1_mbox_poll_for_space(struct omap_mbox *mbox)
+{
+ int i = 1000;
+
+ while (omap1_mbox_fifo_full(mbox)) {
+ if (--i == 0)
+ return -1;
+ udelay(1);
+ }
+ return 0;
+}
+
/* irq */
static void
omap1_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
@@ -103,17 +120,21 @@ omap1_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
static int
omap1_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
+ struct omap_mbox1_priv *priv = (struct omap_mbox1_priv *)mbox->priv;
+
if (irq == IRQ_TX)
return 0;
+ if (irq == IRQ_RX)
+ priv->empty_flag = true;
+
return 1;
}
static struct omap_mbox_ops omap1_mbox_ops = {
- .type = OMAP_MBOX_TYPE1,
.fifo_read = omap1_mbox_fifo_read,
.fifo_write = omap1_mbox_fifo_write,
.fifo_empty = omap1_mbox_fifo_empty,
- .fifo_full = omap1_mbox_fifo_full,
+ .poll_for_space = omap1_mbox_poll_for_space,
.enable_irq = omap1_mbox_enable_irq,
.disable_irq= omap1_mbox_disable_irq,
.is_irq = omap1_mbox_is_irq,
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 759f72c..fef18f4 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -124,6 +124,14 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
return mbox_read_reg(mbox->parent, fifo->fifo_stat);
}
+static int omap2_mbox_poll_for_space(struct omap_mbox *mbox)
+{
+ if (omap2_mbox_fifo_full(mbox))
+ return -1;
+
+ return 0;
+}
+
/* Mailbox IRQ handle functions */
static void omap2_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
@@ -208,13 +216,12 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
}
static struct omap_mbox_ops omap2_mbox_ops = {
- .type = OMAP_MBOX_TYPE2,
.startup= omap2_mbox_startup,
.shutdown = omap2_mbox_shutdown,
.fifo_read = omap2_mbox_fifo_read,
.fifo_write = omap2_mbox_fifo_write,
.fifo_empty = omap2_mbox_fifo_empty,
- .fifo_full = omap2_mbox_fifo_full,
+ .poll_for_space = omap2_mbox_poll_for_space,
.enable_irq = omap2_mbox_enable_irq,
.disable_irq= omap2_mbox_disable_irq,
.ack_irq= omap2_mbox_ack_irq,
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 25a2da7..8329c8a 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -52,9 +51,9 @@ static inline int mbox_fifo_empty(struct omap_mbox *mbox)
{
return mbox->ops->fifo_empty(mbox);
}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
+static inline int mbox_poll_for_space(struct omap_mbox *mbox)
{
- return mbox->ops->fifo_full(mbox);
+ return mbox->ops->poll_for_space(mbox);
}
/* Mailbox IRQ handle functions */
@@ -71,20 +70,6 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message s
[PATCHv3 0/8] omap mailbox dt
Hi, This is an updated series for adding the device tree support to the OMAP mailbox driver. The series is based on 3.11-rc4 and now includes the support for AM335 WkupM3 mailbox. The support for WkupM3 mailbox is essential for achieving the PM Suspend on AM335 devices, and this series is a dependency for the AM335 suspend/resume series [1]. The AM335 support patches required the mailbox DT patches posted previously, so I have refreshed all of them together. Tested this on Beagle-XM, Panda4 and OMAP5 uEVM (with out-of-tree clock patches). v3: - Includes 3 new patches on top of the unchanged patches in v2. - Patches 7 and 8 adds the driver support and DT node for AM335. - Patch6 is a minor cleanup patch removing omap_mbox_type_t from mbox ops. v2: - Removed the #ti,mbox-data-cells from DT bindings and node data - Includes 2 new patches that adds the data for OMAP5. http://marc.info/?l=linux-omap&m=137452880325361&w=2 v1: http://marc.info/?l=linux-omap&m=137159523405468&w=2 [1] http://marc.info/?l=linux-omap&m=137581142013093&w=2 Suman Anna (8): mailbox/omap: add a parent structure common to all mboxes mailbox/omap: add support for parsing dt devices ARM: dts: OMAP2+: Add mailbox nodes ARM: OMAP5: hwmod data: Add mailbox data ARM: dts: OMAP5: Add mailbox dt node mailbox/omap: remove omap_mbox_type_t from mailbox ops mailbox/omap: add code to support the wkupm3 operations ARM: dts: AM33xx: Add mailbox node .../devicetree/bindings/mailbox/omap-mailbox.txt | 43 +++ arch/arm/boot/dts/am33xx.dtsi | 11 + arch/arm/boot/dts/omap2420.dtsi| 12 + arch/arm/boot/dts/omap2430.dtsi| 11 + arch/arm/boot/dts/omap3.dtsi | 11 + arch/arm/boot/dts/omap4.dtsi | 11 + arch/arm/boot/dts/omap5.dtsi | 11 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 42 +++ drivers/mailbox/mailbox-omap1.c| 54 +++- drivers/mailbox/mailbox-omap2.c| 315 + drivers/mailbox/omap-mailbox.c | 58 ++-- drivers/mailbox/omap-mbox.h| 17 +- 13 files changed, 490 insertions(+), 108 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt -- 1.8.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/8] mailbox/omap: add support for parsing dt devices
Logic has been added to the OMAP2+ mailbox code to
parse the mailbox dt nodes and construct the different
mailboxes associated with the instance. The design is
based on gathering the same information that was being
passed previously through the platform data, except for
the interrupt type configuration information.
Signed-off-by: Suman Anna
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 43 +++
drivers/mailbox/mailbox-omap2.c| 130 ++---
2 files changed, 158 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000..8ffb08a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,43 @@
+OMAP2+ Mailbox Driver
+
+Required properties:
+- compatible: Should be one of the following,
+ "ti,omap2-mailbox" for
+ OMAP2420, OMAP2430, OMAP3430, OMAP3630 SoCs
+ "ti,omap4-mailbox" for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the mailbox register address range (base
address
+ and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device
+ can interrupt
+- ti,mbox-num-fifos: Number of h/w fifos within the mailbox device
+- ti,mbox-names: Array of the names of the mailboxes
+- ti,mbox-data:Mailbox descriptor data private to each
mailbox. The 4
+ cells represent the following data,
+ Cell #1 (tx_id) - mailbox fifo id used for
+ transmitting messages
+ Cell #2 (rx_id) - mailbox fifo id on which messages
+ are received
+ Cell #3 (irq_id) - irq identifier index number to use
+ from the interrupts data
+ Cell #4 (usr_id) - mailbox user id for identifying the
+ interrupt into the MPU interrupt
+ controller.
+
+Example:
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = ;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <3>;
+ ti,mbox-num-fifos = <8>;
+ ti,mbox-names = "mbox-ipu", "mbox-dsp";
+ ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+};
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 6c0687c..759f72c 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -222,6 +223,21 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
};
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = "ti,omap2-mailbox",
+ .data = (void *) MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = "ti,omap4-mailbox",
+ .data = (void *) MBOX_INTR_CFG_TYPE2,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -229,47 +245,127 @@ static int omap2_mbox_probe(struct platform_device *pdev)
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox2_priv *priv, *privblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
- struct omap_mbox_dev_info *info;
struct omap_mbox_device *mdev;
- int i;
-
- if (!pdata || !pdata->info_cnt || !pdata->info) {
+ struct omap_mbox_dev_info *info, *of_info = NULL;
+ struct device_node *node = pdev->dev.of_node;
+ int i, j;
+ u32 info_count = 0, intr_type = 0;
+ u32 num_users = 0, num_fifos = 0;
+ u32 dlen, dsize = 4;
+ u32 *tmp;
+ const __be32 *mbox_data;
+
+ if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
}
+ if (node) {
+ intr_type = (u32)of_match_device(omap_mailbox_of_match,
+
[PATCHv3 1/8] mailbox/omap: add a parent structure common to all mboxes
A new structure, omap_mbox_device, is added to contain
the global variables pertinent to a mailbox h/w IP block.
This enables the support for having multiple instances of
the same h/w IP block in the SoC. The startup sequence for
each mailbox is also simplified along the way, removing the
usage of single global configuration variables for all h/w
instances.
Reviewed-by: Russ Dill
Signed-off-by: Suman Anna
---
drivers/mailbox/mailbox-omap1.c | 27 +---
drivers/mailbox/mailbox-omap2.c | 95 +
drivers/mailbox/omap-mailbox.c | 32 ++
drivers/mailbox/omap-mbox.h | 10 +
4 files changed, 102 insertions(+), 62 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 9001b76..5e38ffc 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -26,7 +26,7 @@
#define MAILBOX_DSP2ARM1_Flag 0x1c
#define MAILBOX_DSP2ARM2_Flag 0x20
-static void __iomem *mbox_base;
+static struct omap_mbox_device omap1_mbox_device;
struct omap_mbox1_fifo {
unsigned long cmd;
@@ -41,12 +41,12 @@ struct omap_mbox1_priv {
static inline int mbox_read_reg(size_t ofs)
{
- return __raw_readw(mbox_base + ofs);
+ return __raw_readw(omap1_mbox_device.mbox_base + ofs);
}
static inline void mbox_write_reg(u32 val, size_t ofs)
{
- __raw_writew(val, mbox_base + ofs);
+ __raw_writew(val, omap1_mbox_device.mbox_base + ofs);
}
/* msg */
@@ -139,6 +139,7 @@ static struct omap_mbox mbox_dsp_info = {
.name = "dsp",
.ops= &omap1_mbox_ops,
.priv = &omap1_mbox_dsp_priv,
+ .parent = &omap1_mbox_device,
};
static struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
@@ -148,6 +149,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
struct resource *mem;
int ret;
struct omap_mbox **list;
+ struct omap_mbox_device *mdev = &omap1_mbox_device;
list = omap1_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
@@ -156,13 +158,18 @@ static int omap1_mbox_probe(struct platform_device *pdev)
if (!mem)
return -ENOENT;
- mbox_base = ioremap(mem->start, resource_size(mem));
- if (!mbox_base)
+ mdev->mbox_base = ioremap(mem->start, resource_size(mem));
+ if (!mdev->mbox_base)
return -ENOMEM;
+ mutex_init(&mdev->cfg_lock);
+ mdev->dev = &pdev->dev;
+ mdev->mboxes = omap1_mboxes;
+ mdev->num_users = 2;
+ mdev->num_fifos = 4;
ret = omap_mbox_register(&pdev->dev, list);
if (ret) {
- iounmap(mbox_base);
+ iounmap(mdev->mbox_base);
return ret;
}
@@ -171,8 +178,14 @@ static int omap1_mbox_probe(struct platform_device *pdev)
static int omap1_mbox_remove(struct platform_device *pdev)
{
+ struct omap_mbox_device *mdev = &omap1_mbox_device;
+
omap_mbox_unregister();
- iounmap(mbox_base);
+ iounmap(mdev->mbox_base);
+ mdev->mbox_base = NULL;
+ mdev->mboxes = NULL;
+ mdev->dev = NULL;
+
return 0;
}
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index eba380d..6c0687c 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -42,8 +42,6 @@
#define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32))
#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
-static void __iomem *mbox_base;
-
struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
@@ -62,34 +60,38 @@ struct omap_mbox2_priv {
u32 intr_type;
};
-static inline unsigned int mbox_read_reg(size_t ofs)
+static inline
+unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
- return __raw_readl(mbox_base + ofs);
+ return __raw_readl(mdev->mbox_base + ofs);
}
-static inline void mbox_write_reg(u32 val, size_t ofs)
+static inline
+void mbox_write_reg(struct omap_mbox_device *mdev, u32 val, size_t ofs)
{
- __raw_writel(val, mbox_base + ofs);
+ __raw_writel(val, mdev->mbox_base + ofs);
}
/* Mailbox H/W preparations */
static int omap2_mbox_startup(struct omap_mbox *mbox)
{
- u32 l;
-
- pm_runtime_enable(mbox->dev->parent);
- pm_runtime_get_sync(mbox->dev->parent);
+ pm_runtime_get_sync(mbox->parent->dev);
- l = mbox_read_reg(MAILBOX_REVISION);
- pr_debug("omap mailbox rev %d.%d\n", (l & 0xf0) >> 4, (l & 0x0f));
+ /*
+* just print the raw revision register, the format is not
+* uniform across all SoCs
+*/
+ if (!mbox->use_count) {
+ u32 l = mbox_read_reg(mbox->parent, MAILBOX_REVISION);
+ pr_debug("omap mailbox rev 0x%x\n", l);
+ }
return 0;
}
static void omap2_mbox_shutdown(struct omap_mbox *mbo
[PATCHv3 4/8] ARM: OMAP5: hwmod data: Add mailbox data
Add the hwmod data for the mailbox IP in OMAP5 SoC.
This is needed to be able to enable the OMAP mailbox
support for OMAP5.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..e4f85da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -741,6 +741,39 @@ static struct omap_hwmod omap54xx_kbd_hwmod = {
};
/*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors using a
+ * queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc = &omap54xx_mailbox_sysc,
+};
+
+/* mailbox */
+static struct omap_hwmod omap54xx_mailbox_hwmod = {
+ .name = "mailbox",
+ .class = &omap54xx_mailbox_hwmod_class,
+ .clkdm_name = "l4cfg_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L4CFG_MAILBOX_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L4CFG_MAILBOX_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'mcbsp' class
* multi channel buffered serial port controller
*/
@@ -1807,6 +1840,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_wkup__kbd = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> mailbox */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mailbox = {
+ .master = &omap54xx_l4_cfg_hwmod,
+ .slave = &omap54xx_mailbox_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_abe -> mcbsp1 */
static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcbsp1 = {
.master = &omap54xx_l4_abe_hwmod,
@@ -2107,6 +2148,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
&omap54xx_l4_per__i2c4,
&omap54xx_l4_per__i2c5,
&omap54xx_l4_wkup__kbd,
+ &omap54xx_l4_cfg__mailbox,
&omap54xx_l4_abe__mcbsp1,
&omap54xx_l4_abe__mcbsp2,
&omap54xx_l4_abe__mcbsp3,
--
1.8.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/8] ARM: dts: OMAP2+: Add mailbox nodes
The mailbox DT node data has been added for OMAP2420,
OMAP2430, OMAP3430/OMAP3630, OMAP44xx devices. Data
for OMAP5 and other SoCs will be added separately.
The mailbox static device initialization logic is also
adjusted for a DT boot.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap2420.dtsi | 12
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap3.dtsi| 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/mach-omap2/devices.c | 2 +-
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..43081e9 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,18 @@
dma-names = "tx", "rx";
};
+ mailbox: mailbox@48094000 {
+ compatible = "ti,omap2-mailbox";
+ reg = <0x48094000 0x200>;
+ interrupts = <26>, /* DSP Interrupt */
+<34>; /* IVA Interrupt */
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <6>;
+ ti,mbox-names = "dsp", "iva";
+ ti,mbox-data = <0 1 0 0>, <2 3 1 3>;
+ };
+
timer1: timer@48028000 {
compatible = "ti,omap2420-timer";
reg = <0x48028000 0x400>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..55c4236 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,17 @@
dma-names = "tx", "rx";
};
+ mailbox: mailbox@48094000 {
+ compatible = "ti,omap2-mailbox";
+ reg = <0x48094000 0x200>;
+ interrupts = <26>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <6>;
+ ti,mbox-names = "dsp";
+ ti,mbox-data = <0 1 0 0>;
+ };
+
timer1: timer@49018000 {
compatible = "ti,omap2420-timer";
reg = <0x49018000 0x400>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..7278656 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -386,6 +386,17 @@
dma-names = "tx", "rx";
};
+ mailbox: mailbox@48094000 {
+ compatible = "ti,omap2-mailbox";
+ reg = <0x48094000 0x200>;
+ interrupts = <26>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <2>;
+ ti,mbox-num-fifos = <2>;
+ ti,mbox-names = "dsp";
+ ti,mbox-data = <0 1 0 0>;
+ };
+
timer1: timer@48318000 {
compatible = "ti,omap3430-timer";
reg = <0x48318000 0x400>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..66f11a3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -523,6 +523,17 @@
};
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = ;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <3>;
+ ti,mbox-num-fifos = <8>;
+ ti,mbox-names = "mbox-ipu", "mbox-dsp";
+ ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+ };
+
timer1: timer@4a318000 {
compatible = "ti,omap3430-timer";
reg = <0x4a318000 0x80>;
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..0afdf6f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -562,10 +562,10 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
- omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
omap_init_dmic();
+ omap_init_mbox();
omap_init_mcpdm();
omap_init_mcspi();
omap_init_sham();
--
1.8.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
Re: [PATCH 3/3] ARM: dts: AM33xx: Add RNG node
On Tue, Aug 6, 2013 at 1:33 AM, Lokesh Vutla wrote:
> Add the generic AM33xx RNG module's device tree data and
> enable it for the am335x-evm, am335x-evmsk, and am335x-bone
> platforms. Also add Documentation file describing the data
> for the RNG module.
>
> Signed-off-by: Lokesh Vutla
> ---
> .../devicetree/bindings/hwrng/omap_rng.txt | 22
>
> arch/arm/boot/dts/am335x-bone.dts |4
> arch/arm/boot/dts/am335x-evm.dts |4
> arch/arm/boot/dts/am335x-evmsk.dts |4
> arch/arm/boot/dts/am33xx.dtsi |8 +++
> 5 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
>
> diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
> b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
> new file mode 100644
> index 000..6a62acd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
> @@ -0,0 +1,22 @@
> +OMAP SoC HWRNG Module
> +
> +Required properties:
> +
> +- compatible : Should contain entries for this and backward compatible
> + RNG versions:
> + - "ti,omap2-rng" for OMAP2.
> + - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
> + Note that these two versions are incompatible.
> +- ti,hwmods: Name of the hwmod associated with the RNG module
> +- reg : Offset and length of the register set for the module
> +- interrupts : the interrupt number for the RNG module.
> + Only used for "ti,omap4-rng".
> +
> +Example:
> +/* AM335x */
> +rng: rng@4831 {
> + compatible = "ti,omap4-rng";
> + ti,hwmods = "rng";
> + reg = <0x4831 0x2000>;
> + interrupts = <111>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index 444b4ed..46a3887 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -234,3 +234,7 @@
> pinctrl-0 = <&davinci_mdio_default>;
> pinctrl-1 = <&davinci_mdio_sleep>;
> };
> +
> +&rng {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 3aee1a4..ebfbebe1 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -488,3 +488,7 @@
> ti,adc-channels = <4 5 6 7>;
> };
> };
> +
> +&rng {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index 0c8ad17..6610a05 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -402,3 +402,7 @@
> phy_id = <&davinci_mdio>, <1>;
> phy-mode = "rgmii-txid";
> };
> +
> +&rng {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 38b446b..b1e6205 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -530,5 +530,13 @@
> #size-cells = <1>;
> status = "disabled";
> };
> +
> + rng: rng@4831 {
> + compatible = "ti,omap4-rng";
> + ti,hwmods = "rng";
> + reg = <0x4831 0x2000>;
> + interrupts = <111>;
> + status = "disabled";
Is there any point in making this default to "disabled"? Are there any
am335x platforms where the trng doesn't function?
> + };
> };
> };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 16:15 +0100, Pawel Moll wrote: > On Tue, 2013-08-06 at 14:46 +0100, Ivan T. Ivanov wrote: > > > > + reg = <0xf920 0xcd00>; > > > > + interrupts = <0 131 0>; > > > > + interrupt-names = "irq"; > > > > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>; > > > > + tx-fifo-resize; > > > > + }; > > > > + }; > > > > > > And now I'm really confused... Maybe it's just lack of documentation... > > > > > > How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"? > > > > Not sure from where you get this "qcom,dwc-usb3", but now I think > > that "qcom,dwc-usb3" should be enough for compatible. > > The other patch introduces "qcom,dwc3-usb3" compatible value... Oh, of course. Intention was that "qcom,dwc-usb3" will handle SS-PHY, while "qcom,dwc-usb2" will handle HS-PHY. Probably it will better if I rename them to "qcom,dwc-ssphy" and "qcom,dwc-hsphy". Regards, Ivan > > Paweł -- 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
[PATCHv3 1/9] memory: emif: Move EMIF register defines to include/linux/
OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach Cc: Santosh Shilimkar Cc: Benoit Cousson Cc: Aneesh V --- drivers/memory/emif.h | 543 + include/linux/ti_emif.h | 558 +++ 2 files changed, 559 insertions(+), 542 deletions(-) create mode 100644 include/linux/ti_emif.h diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h index bfe08ba..8214f07 100644 --- a/drivers/memory/emif.h +++ b/drivers/memory/emif.h @@ -12,548 +12,7 @@ #ifndef __EMIF_H #define __EMIF_H -/* - * Maximum number of different frequencies supported by EMIF driver - * Determines the number of entries in the pointer array for register - * cache - */ -#define EMIF_MAX_NUM_FREQUENCIES 6 - -/* State of the core voltage */ -#define DDR_VOLTAGE_STABLE 0 -#define DDR_VOLTAGE_RAMPING1 - -/* Defines for timing De-rating */ -#define EMIF_NORMAL_TIMINGS0 -#define EMIF_DERATED_TIMINGS 1 - -/* Length of the forced read idle period in terms of cycles */ -#define EMIF_READ_IDLE_LEN_VAL 5 - -/* - * forced read idle interval to be used when voltage - * is changed as part of DVFS/DPS - 1ms - */ -#define READ_IDLE_INTERVAL_DVFS(1*100) - -/* - * Forced read idle interval to be used when voltage is stable - * 50us - or maximum value will do - */ -#define READ_IDLE_INTERVAL_NORMAL (50*100) - -/* DLL calibration interval when voltage is NOT stable - 1us */ -#define DLL_CALIB_INTERVAL_DVFS(1*100) - -#define DLL_CALIB_ACK_WAIT_VAL 5 - -/* Interval between ZQCS commands - hw team recommended value */ -#define EMIF_ZQCS_INTERVAL_US (50*1000) -/* Enable ZQ Calibration on exiting Self-refresh */ -#define ZQ_SFEXITEN_ENABLE 1 -/* - * ZQ Calibration simultaneously on both chip-selects: - * Needs one calibration resistor per CS - */ -#defineZQ_DUALCALEN_DISABLE0 -#defineZQ_DUALCALEN_ENABLE 1 - -#define T_ZQCS_DEFAULT_NS 90 -#define T_ZQCL_DEFAULT_NS 360 -#define T_ZQINIT_DEFAULT_NS1000 - -/* DPD_EN */ -#define DPD_DISABLE0 -#define DPD_ENABLE 1 - -/* - * Default values for the low-power entry to be used if not provided by user. - * OMAP4/5 has a hw bug(i735) due to which this value can not be less than 512 - * Timeout values are in DDR clock 'cycles' and frequency threshold in Hz - */ -#define EMIF_LP_MODE_TIMEOUT_PERFORMANCE 2048 -#define EMIF_LP_MODE_TIMEOUT_POWER 512 -#define EMIF_LP_MODE_FREQ_THRESHOLD4 - -/* DDR_PHY_CTRL_1 values for EMIF4D - ATTILA PHY combination */ -#define EMIF_DDR_PHY_CTRL_1_BASE_VAL_ATTILAPHY 0x049FF000 -#define EMIF_DLL_SLAVE_DLY_CTRL_400_MHZ_ATTILAPHY 0x41 -#define EMIF_DLL_SLAVE_DLY_CTRL_200_MHZ_ATTILAPHY 0x80 -#define EMIF_DLL_SLAVE_DLY_CTRL_100_MHZ_AND_LESS_ATTILAPHY 0xFF - -/* DDR_PHY_CTRL_1 values for EMIF4D5 INTELLIPHY combination */ -#define EMIF_DDR_PHY_CTRL_1_BASE_VAL_INTELLIPHY0x0E084200 -#define EMIF_PHY_TOTAL_READ_LATENCY_INTELLIPHY_PS 1 - -/* TEMP_ALERT_CONFIG - corresponding to temp gradient 5 C/s */ -#define TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS360 - -#define EMIF_T_CSTA3 -#define EMIF_T_PDLL_UL 128 - -/* External PHY control registers magic values */ -#define EMIF_EXT_PHY_CTRL_1_VAL0x04020080 -#define EMIF_EXT_PHY_CTRL_5_VAL0x04010040 -#define EMIF_EXT_PHY_CTRL_6_VAL0x01004010 -#define EMIF_EXT_PHY_CTRL_7_VAL0x1004 -#define EMIF_EXT_PHY_CTRL_8_VAL0x04010040 -#define EMIF_EXT_PHY_CTRL_9_VAL0x01004010 -#define EMIF_EXT_PHY_CTRL_10_VAL 0x1004 -#define EMIF_EXT_PHY_CTRL_11_VAL 0x -#define EMIF_EXT_PHY_CTRL_12_VAL 0x0
[PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Vaibhav Bedia
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate resume process. As part of the boot
process, the assembly code is copied over to OCMCRAM using
the OMAP SRAM code.
AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care of the
clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep.
The IPC mechanism between MPU and WKUP_M3 uses a mailbox
sub-module and 8 IPC registers in the Control module. MPU
uses the assigned Mailbox for issuing an interrupt to
WKUP_M3 which then goes and checks the IPC registers for
the payload. WKUP_M3 has the ability to trigger on interrupt
to MPU by executing the "sev" instruction.
In the current implementation when the suspend process
is initiated MPU interrupts the WKUP_M3 to let it know about
the intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM. The assembly code puts the PLLs in bypass, puts the
external RAM in self-refresh mode and then finally execute the
WFI instruction. Execution of the WFI instruction triggers another
interrupt to the WKUP_M3 which then continues wiht the power down
sequence wherein the clockdomain and powerdomain transition takes
place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt
lines for the wakeup sources. WFI execution on WKUP_M3 causes the
hardware to disable the main oscillator of the SoC.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
The low level code in OCMC relocks the PLLs, enables access
to external RAM and then jumps to the cpu_resume code of
the kernel to finish the resume process.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
Cc: Tony Lingren
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm33xx.c | 474 +
arch/arm/mach-omap2/pm33xx.h | 77 +++
arch/arm/mach-omap2/wkup_m3.c | 183
3 files changed, 734 insertions(+)
create mode 100644 arch/arm/mach-omap2/pm33xx.c
create mode 100644 arch/arm/mach-omap2/pm33xx.h
create mode 100644 arch/arm/mach-omap2/wkup_m3.c
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
new file mode 100644
index 000..d291c76
--- /dev/null
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -0,0 +1,474 @@
+/*
+ * AM33XX Power Management Routines
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "pm.h"
+#include "cm33xx.h"
+#include "pm33xx.h"
+#include "control.h"
+#include "common.h"
+#include "clockdomain.h"
+#include "powerdomain.h"
+#include "omap_hwmod.h"
+#include "omap_device.h"
+#include "soc.h"
+#include "sram.h"
+
+static void __iomem *am33xx_emif_base;
+static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
+static struct clockdomain *gfx_l4ls_clkdm;
+
+struct wakeup_src wakeups[] = {
+ {.irq_nr = 35, .src = "USB0_PHY"},
+ {.irq_nr = 36, .src = "USB1_PHY"},
+ {.irq_nr = 40, .src = "I2C0"},
+ {.irq_nr = 41, .src = "RTC Timer"},
+ {.irq_nr = 42, .src = "RTC Alarm"},
+ {.irq_nr = 43, .src = "Timer0"},
+ {.irq_nr = 44, .src = "Timer1"},
+ {.irq_nr = 45, .src = "UART"},
+ {.irq_nr = 46, .src = "GPIO0"},
+ {.irq_nr = 48, .src = "MPU_WAKE"},
+ {.irq_nr = 49, .s
[PATCHv3 5/9] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
From: Vaibhav Bedia
In preparation for suspend-resume support for AM33XX, add
the assembly file with the code which is copied to internal
memory (OCMC RAM) during bootup and runs from there.
As part of the low power entry (DeepSleep0 mode in AM33XX TRM),
the code running from OCMC RAM does the following
1. Stores the EMIF configuration
2. Puts external memory in self-refresh
3. Disables EMIF clock
4. Executes WFI after writing to MPU_CLKCTRL register.
If no interrupts have come, WFI execution on MPU gets registered
as an interrupt with the WKUP-M3. WKUP-M3 takes care of disabling
some clocks which MPU should not (L3, L4, OCMC RAM etc) and takes
care of clockdomain and powerdomain transitions as part of the
DeepSleep0 mode entry.
In case a late interrupt comes in, WFI ends up as a NOP and MPU
continues execution from internal memory. The 'abort path' code
undoes whatever was done as part of the low power entry and indicates
a suspend failure by passing a non-zero value to the cpu_resume routine.
The 'resume path' code is similar to the 'abort path' with the key
difference of MMU being enabled in the 'abort path' but being
disabled in the 'resume path' due to MPU getting powered off.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
Cc: Santosh Shilimkar
Cc: Kevin Hilman
---
arch/arm/mach-omap2/sleep33xx.S | 350 +++
1 file changed, 350 insertions(+)
create mode 100644 arch/arm/mach-omap2/sleep33xx.S
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
new file mode 100644
index 000..834c7d4
--- /dev/null
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -0,0 +1,350 @@
+/*
+ * Low level suspend code for AM33XX SoCs
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cm33xx.h"
+#include "pm33xx.h"
+#include "prm33xx.h"
+
+ .text
+ .align 3
+
+/*
+ * This routine is executed from internal RAM and expects some
+ * parameters to be passed in r0 _strictly_ in following order:
+ * 1) emif_addr_virt - ioremapped EMIF address
+ * 2) mem_type - 2 -> DDR2, 3-> DDR3
+ * 3) dram_sync_word - uncached word in SDRAM
+ *
+ * The code loads these values taking r0 value as reference to
+ * the array in registers starting from r0, i.e emif_addr_virt
+ * goes to r1, mem_type goes to r2 and and so on. These are
+ * then saved into memory locations before proceeding with the
+ * sleep sequence and hence registers r0, r1 etc can still be
+ * used in the rest of the sleep code.
+ */
+
+ENTRY(am33xx_do_wfi)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ ldm r0, {r1-r3} @ gather values passed
+
+ /* Save the values passed */
+ str r1, emif_addr_virt
+ str r2, mem_type
+ str r3, dram_sync_word
+
+ /*
+* Flush all data from the L1 data cache before disabling
+* SCTLR.C bit.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ /*
+* Clear the SCTLR.C bit to prevent further data cache
+* allocation. Clearing SCTLR.C would make all the data accesses
+* strongly ordered and would not hit the cache.
+*/
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+* Invalidate L1 data cache. Even though only invalidate is
+* necessary exported flush API is used here. Doing clean
+* on already clean cache would be almost NOP.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ ldr r0, emif_addr_virt
+ /* Save EMIF configuration */
+ ldr r1, [r0, #EMIF_SDRAM_CONFIG]
+ str r1, emif_sdcfg_val
+ ldr r1, [r0, #EMIF_SDRAM_REFRESH_CONTROL]
+ str r1, emif_ref_ctrl_val
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_1]
+ str r1, emif_timing1_val
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_2]
+ str r1, emif_timing2_val
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_3]
+ str r1, emif_timing3_val
+ ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL]
+ str r1, emif_pmcr_val
+ ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW]
+ str r1, emif_pmcr_shdw_val
+ ldr r1, [r0, #EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG]
+ str r1, emif_zqcfg_val
+ ldr r1, [r0, #EMIF_DDR_PHY_CTRL_1]
+
[PATCHv3 9/9] ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds
From: Vaibhav Bedia
With all the requisite changes in place we can now
enable the basic PM support for AM335x. This patch
updates the various OMAP files to enable suspend-resume
on AM335x.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/Kconfig |7 +--
arch/arm/mach-omap2/Makefile|2 ++
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h| 10 ++
arch/arm/mach-omap2/io.c|5 +
arch/arm/mach-omap2/pm.c|3 ++-
arch/arm/mach-omap2/pm.h|5 +
arch/arm/mach-omap2/sram.c | 10 +-
arch/arm/mach-omap2/sram.h |2 ++
9 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3eed000..ef3fe40 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -67,11 +67,14 @@ config SOC_OMAP5
config SOC_AM33XX
bool "AM33XX support"
depends on ARCH_MULTI_V7
- select ARCH_OMAP2PLUS
+ default y
select ARM_CPU_SUSPEND if PM
+ select COMMON_CLK
select CPU_V7
+ select MAILBOX if PM
select MULTI_IRQ_HANDLER
- select COMMON_CLK
+ select OMAP_MBOX_FWK if PM
+ select OMAP2PLUS_MBOX if PM
config SOC_AM43XX
bool "TI AM43x"
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..eb3a47a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_AM33XX) += pm33xx.o sleep33xx.o wkup_m3.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
@@ -94,6 +95,7 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
endif
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index aed750c..3f2d6a7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -159,6 +159,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened
Device Tree)")
.reserve= am33xx_reserve,
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
+ .init_late = am33xx_init_late,
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 6b8ef74..80bf0da 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -69,6 +69,15 @@ static inline int omap4_pm_init(void)
}
#endif
+#if defined(CONFIG_PM) && defined(CONFIG_SOC_AM33XX)
+int am33xx_pm_init(void);
+#else
+static inline int am33xx_pm_init(void)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_OMAP_MUX
int omap_mux_late_init(void);
#else
@@ -107,6 +116,7 @@ void omap2430_init_late(void);
void omap3430_init_late(void);
void omap35xx_init_late(void);
void omap3630_init_late(void);
+void am33xx_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
int omap2_common_pm_late_init(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3ad7543..63516e5 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -584,6 +584,11 @@ void __init am33xx_init_early(void)
omap_hwmod_init_postsetup();
omap_clk_init = am33xx_clk_init;
}
+
+void __init am33xx_init_late(void)
+{
+ am33xx_pm_init();
+}
#endif
#ifdef CONFIG_SOC_AM43XX
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e742118..f8bd883 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -305,7 +305,8 @@ int __init omap2_common_pm_late_init(void)
}
#ifdef CONFIG_SUSPEND
- suspend_set_ops(&omap_pm_ops);
+ if (!soc_is_am33xx())
+ suspend_set_ops(&omap_pm_ops);
#endif
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7bdd22a..5122bb6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -82,6 +82,11 @@ extern unsigned int omap3_do_wfi_sz;
/* ... and its pointer from SRAM after copy */
extern void (*omap3_do_wfi_sram)(void);
+/* am33xx_do_wfi function pointer and size, for copy to SRAM */
+extern void am33xx_do_wfi(void);
+extern unsigned int am33xx_do_wfi_sz;
+extern unsigned int am33xx_resume_offset;
+
/* save_secure_ram_context function pointer an
[PATCHv3 4/9] ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec
From: Vaibhav Bedia
SDRAM controller on AM33XX requires that a modification of certain
bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
AM335x-Rev H) is followed by a dummy read access to SDRAM. This
scenario arises when entering a low power state like DeepSleep.
To ensure that the read is not from a cached region we reserve
some memory during bootup using the arm_memblock_steal() API.
A subsequent patch will pass along the location of the reserved
memory location to the AM335x suspend handler which modifies the
PWR_MGMT_CTRL register in the EMIF.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/common.c| 28
arch/arm/mach-omap2/common.h|4
arch/arm/mach-omap2/io.c|1 +
4 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index be5d005..aed750c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -156,7 +156,7 @@ static const char *am33xx_boards_compat[] __initdata = {
};
DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
- .reserve= omap_reserve,
+ .reserve= am33xx_reserve,
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
.init_irq = omap_intc_of_init,
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9e..756586f 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include "common.h"
#include "omap-secure.h"
@@ -34,3 +36,29 @@ void __init omap_reserve(void)
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
}
+
+static phys_addr_t am33xx_paddr;
+static u32 am33xx_size;
+
+/* Steal one page physical memory for uncached read DeepSleep */
+void __init am33xx_reserve(void)
+{
+ am33xx_size = ALIGN(PAGE_SIZE, SZ_1M);
+ am33xx_paddr = arm_memblock_steal(am33xx_size, SZ_1M);
+}
+
+void __iomem *am33xx_dram_sync;
+
+void __init am33xx_dram_sync_init(void)
+{
+ struct map_desc dram_io_desc[1];
+
+ dram_io_desc[0].virtual = __phys_to_virt(am33xx_paddr);
+ dram_io_desc[0].pfn = __phys_to_pfn(am33xx_paddr);
+ dram_io_desc[0].length = am33xx_size;
+ dram_io_desc[0].type = MT_MEMORY_SO;
+
+ iotable_init(dram_io_desc, ARRAY_SIZE(dram_io_desc));
+
+ am33xx_dram_sync = (void __iomem *) dram_io_desc[0].virtual;
+}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dfcc182..6b8ef74 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -294,6 +294,10 @@ struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
extern void omap_reserve(void);
+extern void am33xx_reserve(void);
+extern void am33xx_dram_sync_init(void);
+extern void __iomem *am33xx_dram_sync;
+
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..3ad7543 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -322,6 +322,7 @@ void __init ti81xx_map_io(void)
void __init am33xx_map_io(void)
{
iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+ am33xx_dram_sync_init();
}
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/9] ARM: OMAP: DTB: Update IRQ data for WKUP_M3
From: Vaibhav Bedia Allow interrupt for wkup_m3 to be set from DT. Signed-off-by: Vaibhav Bedia Signed-off-by: Dave Gerlach Cc: Benoit Cousson --- arch/arm/boot/dts/am33xx.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 38b446b..05353bf 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -491,6 +491,7 @@ compatible = "ti,am3353-wkup-m3"; reg = <0x44d0 0x4000/* M3 UMEM */ 0x44d8 0x2000>; /* M3 DMEM */ + interrupts = <78>; ti,hwmods = "wkup_m3"; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/9] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
From: Vaibhav Bedia
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/timer.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b37e1fc..cce5d39 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -118,11 +118,43 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, "timer%d", clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ __omap_dm_timer_stop(&clkev, 1, clkev.rate);
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, "timer%d", clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_load_start(&clkev,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
static struct clock_event_device clockevent_gpt = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
+ .suspend= omap_clkevt_suspend,
+ .resume = omap_clkevt_resume,
};
static struct property device_disabled = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
From: Vaibhav Bedia
Interacting with WKUP-M3 requires some more control
module register writes. Add the register offsets and
APIs to write to these.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/control.c | 57 +
arch/arm/mach-omap2/control.h | 54 ++
2 files changed, 111 insertions(+)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 31e0dfe..934041a 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -605,3 +605,60 @@ int omap3_ctrl_save_padconf(void)
}
#endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
+
+#if defined(CONFIG_SOC_AM33XX) && defined(CONFIG_PM)
+void am33xx_txev_eoi(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ACK, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_txev_enable(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ENABLE, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+/*
+ * Invalidate M3 firmware version before hardreset.
+ * Write invalid version in lower 4 nibbles of parameter
+ * register (ipc_regs + 0x8).
+ */
+void am33xx_pm_version_clear(void)
+{
+ omap_ctrl_writel(0x, AM33XX_CONTROL_IPC_MSG_REG2);
+}
+
+int am33xx_pm_version_get(void)
+{
+ return omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG2) & M3_VERSION_MASK;
+}
+
+void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data)
+{
+ omap_ctrl_writel(data->resume_addr, AM33XX_CONTROL_IPC_MSG_REG0);
+ omap_ctrl_writel(data->sleep_mode, AM33XX_CONTROL_IPC_MSG_REG1);
+ omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2);
+ omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3);
+ omap_ctrl_writel(data->param3, AM33XX_CONTROL_IPC_MSG_REG4);
+}
+
+int am33xx_pm_status(void)
+{
+ int i;
+
+ i = omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG1);
+ i &= IPC_RESP_MASK;
+ i >>= __ffs(IPC_RESP_MASK);
+
+ return i;
+}
+
+int am33xx_pm_wake_src(void)
+{
+ int i;
+
+ i = omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG6);
+ i &= 0xff;
+
+ return i;
+}
+#endif /* CONFIG_SOC_AM33XX && CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f7d7c2e..9be587c 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -370,6 +370,22 @@
#define AM33XX_DEV_FEATURE 0x604
#define AM33XX_SGX_MASKBIT(29)
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI 0x1324
+
+#define AM33XX_M3_TXEV_ACK (0x1 << 0)
+#define AM33XX_M3_TXEV_ENABLE (0x0 << 0)
+
+/* AM33XX IPC message registers */
+#define AM33XX_CONTROL_IPC_MSG_REG00x1328
+#define AM33XX_CONTROL_IPC_MSG_REG10x132C
+#define AM33XX_CONTROL_IPC_MSG_REG20x1330
+#define AM33XX_CONTROL_IPC_MSG_REG30x1334
+#define AM33XX_CONTROL_IPC_MSG_REG40x1338
+#define AM33XX_CONTROL_IPC_MSG_REG50x133C
+#define AM33XX_CONTROL_IPC_MSG_REG60x1340
+#define AM33XX_CONTROL_IPC_MSG_REG70x1344
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
@@ -429,6 +445,44 @@ extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
extern void omap2_set_globals_control(void __iomem *ctrl,
void __iomem *ctrl_pad);
+struct am33xx_ipc_data {
+ u32 resume_addr;
+ u32 sleep_mode;
+ u32 param1;
+ u32 param2;
+ u32 param3;
+ u32 param4;
+ u32 param5;
+ u32 param6;
+};
+
+#define IPC_RESP_SHIFT 16
+#define IPC_RESP_MASK (0x << 16)
+
+#define M3_VERSION_SHIFT 0
+#define M3_VERSION_MASK(0x << 0)
+
+/*
+ * 9-4 = VTT GPIO PIN (6 Bits)
+ * 3 = VTT Status (1 Bit)
+ * 2-0 = Memory Type (2 Bits)
+*/
+#define MEM_TYPE_SHIFT (0x0)
+#define MEM_TYPE_MASK (0x7 << 0)
+#define VTT_STAT_SHIFT (0x3)
+#define VTT_STAT_MASK (0x1 << 3)
+#define VTT_GPIO_PIN_SHIFT (0x4)
+#define VTT_GPIO_PIN_MASK (0x2f << 4)
+
+extern void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data);
+extern void am33xx_txev_eoi(void);
+extern void am33xx_txev_enable(void);
+extern void am33xx_pm_version_clear(void);
+extern int am33xx_pm_version_get(void);
+extern void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data);
+extern int am33xx_pm_status(void);
+extern int am33xx_pm_wake_src(void);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi, This is the third version of the patch series for adding basic suspend-resume support for AM33XX, previously submitted by Vaibhav Bedia. This patchset is based on 3.11-rc4 and depends on a forthcoming patchset from Suman Anna that adds mailbox support for the wkup_m3. The patches at [1], [2], and [3] are required for the pm code to properly suspend and resume. The PM code uses the firmware interface and expects the userspace to load the WKUP_M3 binary before the suspend-resume functionality is made available. The binary file (and the source-code for WKUP_M3) can be obtained from the 'next2' branch at [4]. The WKUP_M3 binary can either be loaded post bootup via the sysfs entry './sys/devices/ocp.2/wkup_m3.4/firmware' or it can be included in the kernel image as part of the build process. Suspend to mem is tested on am335x-bone and am335x-evm. More details on AM335x suspend-resume are provided within the commit logs for each patch. Changes in v3: - Moved wkup_m3 code into separate driver - Split up ti_emif header move - Addressed clean-up comments - Removed mailbox patches - v2-v3 Discussion: http://marc.info/?l=linux-arm-kernel&m=135698501821090&w=4 Changes in v2: - Broke patches up to isolate assembly code and build hookup. - Moved control module code to separate module - v1->v2 Discussion: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129508.html Regards, Dave [1] http://marc.info/?l=linux-arm-kernel&m=137303736714638&w=4 [2] http://marc.info/?l=linux-omap&m=137303723114610&w=4 [3] http://marc.info/?l=linux-omap&m=137401384611934&w=4 [4] http://arago-project.org/git/projects/?p=am33x-cm3.git;a=shortlog;h=refs/heads/next2 Dave Gerlach (1): memory: emif: Move EMIF register defines to include/linux/ Vaibhav Bedia (8): ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs ARM: OMAP: DTB: Update IRQ data for WKUP_M3 ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec ARM: OMAP2+: AM33XX: Add assembly code for PM operations ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device ARM: OMAP: omap_device: Add APIs to enable and idle hwmods ARM: OMAP2+: AM33XX: Basic suspend resume support ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds arch/arm/boot/dts/am33xx.dtsi |1 + arch/arm/mach-omap2/Kconfig |7 +- arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/board-generic.c |3 +- arch/arm/mach-omap2/common.c| 28 ++ arch/arm/mach-omap2/common.h| 14 + arch/arm/mach-omap2/control.c | 57 arch/arm/mach-omap2/control.h | 54 arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_device.c |8 + arch/arm/mach-omap2/omap_device.h |2 + arch/arm/mach-omap2/pm.c|3 +- arch/arm/mach-omap2/pm.h|5 + arch/arm/mach-omap2/pm33xx.c| 474 + arch/arm/mach-omap2/pm33xx.h| 77 + arch/arm/mach-omap2/sleep33xx.S | 350 ++ arch/arm/mach-omap2/sram.c | 10 +- arch/arm/mach-omap2/sram.h |2 + arch/arm/mach-omap2/timer.c | 32 ++ arch/arm/mach-omap2/wkup_m3.c | 183 drivers/memory/emif.h | 543 +- include/linux/ti_emif.h | 558 +++ 22 files changed, 1872 insertions(+), 547 deletions(-) create mode 100644 arch/arm/mach-omap2/pm33xx.c create mode 100644 arch/arm/mach-omap2/pm33xx.h create mode 100644 arch/arm/mach-omap2/sleep33xx.S create mode 100644 arch/arm/mach-omap2/wkup_m3.c create mode 100644 include/linux/ti_emif.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/9] ARM: OMAP: omap_device: Add APIs to enable and idle hwmods
From: Vaibhav Bedia
Needed to let the AM335x PM handle the IPs which need forced
standby transition during every suspend-resume cycle when
the corresponding driver is not compiled into the kernel.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/omap_device.c |8
arch/arm/mach-omap2/omap_device.h |2 ++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..8cf63f6 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -219,6 +219,10 @@ static int _omap_device_enable_hwmods(struct omap_device
*od)
return 0;
}
+int omap_device_enable_hwmods(struct omap_device *od)
+{
+ return _omap_device_enable_hwmods(od);
+}
/**
* _omap_device_idle_hwmods - call omap_hwmod_idle() on all hwmods
* @od: struct omap_device *od
@@ -236,6 +240,10 @@ static int _omap_device_idle_hwmods(struct omap_device *od)
return 0;
}
+int omap_device_idle_hwmods(struct omap_device *od)
+{
+ return _omap_device_idle_hwmods(od);
+}
/* Public functions for use by core code */
/**
diff --git a/arch/arm/mach-omap2/omap_device.h
b/arch/arm/mach-omap2/omap_device.h
index 17ca1ae..655ec35 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -87,6 +87,8 @@ struct device *omap_device_get_by_hwmod_name(const char
*oh_name);
/* OMAP PM interface */
int omap_device_get_context_loss_count(struct platform_device *pdev);
+int omap_device_enable_hwmods(struct omap_device *od);
+int omap_device_idle_hwmods(struct omap_device *od);
/* Other */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: rx51: change musb mode to OTG
Peripheral-only mode got broken in v3.11-rc1 because of unknown reasons.
Change the mode to OTG, in practice that should work equally well even
when/if the regression gets fixed.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/board-rx51.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index d2ea68e..773510556 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -85,7 +85,7 @@ static struct omap_board_mux board_mux[] __initdata = {
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_PERIPHERAL,
+ .mode = MUSB_OTG,
.power = 0,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: omap2: fix musb usage for n8x0
From: Daniel Mack
Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code still had references to it.
As the core now handles both dual role and host-only modes, we can just
pass MUSB_OTG as mode from board files.
Signed-off-by: Daniel Mack
Tested-by: Aaro Koskinen
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/board-n8x0.c | 4
arch/arm/mach-omap2/usb-musb.c | 5 +
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index f6eeb87..827d150 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data tusb_data = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
.set_power = tusb_set_power,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..bc89723 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
+
/* .clock is set dynamically */
.config = &musb_config,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP: fix USB regression on Nokia boards
Hi, USB subsystem changes broke the USB peripheral/gadget on N800, N810 and RX-51/N900 during the merge window. We need to fix this in board files. I tested all these with 3.11-rc4 + g_ether + ssh. Aaro Koskinen (1): ARM: OMAP: rx51: change musb mode to OTG Daniel Mack (1): ARM: omap2: fix musb usage for n8x0 arch/arm/mach-omap2/board-n8x0.c | 4 arch/arm/mach-omap2/board-rx51.c | 2 +- arch/arm/mach-omap2/usb-musb.c | 5 + 3 files changed, 2 insertions(+), 9 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3-pci: Ensure system sleep PM ops are defined only when used
From: Andy Green
You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
case these are unused.
Signed-off-by: Andy Green
Signed-off-by: Mark Brown
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 5d746e5..4902021 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -191,7 +191,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_id_table) = {
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
-#ifdef CONFIG_PM
+#ifdef CONFIG_SUSPEND
static int dwc3_pci_suspend(struct device *dev)
{
struct pci_dev *pci = to_pci_dev(dev);
--
1.8.4.rc1
--
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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 14:46 +0100, Ivan T. Ivanov wrote: > > > + reg = <0xf920 0xcd00>; > > > + interrupts = <0 131 0>; > > > + interrupt-names = "irq"; > > > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>; > > > + tx-fifo-resize; > > > + }; > > > + }; > > > > And now I'm really confused... Maybe it's just lack of documentation... > > > > How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"? > > Not sure from where you get this "qcom,dwc-usb3", but now I think > that "qcom,dwc-usb3" should be enough for compatible. The other patch introduces "qcom,dwc3-usb3" compatible value... Paweł -- 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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi, On Tue, 2013-08-06 at 15:07 +0100, Mark Rutland wrote: > On Tue, Aug 06, 2013 at 12:53:11PM +0100, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > What does the "glue layer" do? Is it an actual piece of hardware, or > just some platform-specific code? > It is hardware layer around Synopsys DesignWare USB3 core. The term 'glue layer' is what is used in TI OMAP's and Samsung Exynos drivers implementations. > > > > Signed-off-by: Ivan T. Ivanov > > --- > > .../devicetree/bindings/usb/msm-ssusb.txt | 39 + > > drivers/usb/dwc3/Kconfig |8 + > > drivers/usb/dwc3/Makefile |1 + > > drivers/usb/dwc3/dwc3-msm.c| 175 > > > > 4 files changed, 223 insertions(+) > > create mode 100644 drivers/usb/dwc3/dwc3-msm.c > > > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > index 550b496..313ae0d 100644 > > --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > @@ -22,6 +22,23 @@ Required "supply-name" examples are: > > "v1p8" : 1.8v supply for SS-PHY > > "vddcx" : vdd supply for SS-PHY digital circuit operation > > > > +Required properties : > > +- compatible : should be "qcom,dwc-usb3-msm" > > +- reg : offset and length of the register set in the memory map > > + offset and length of the TCSR register for routing USB > > + signals to either picoPHY0 or picoPHY1. > > +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, > > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>; > > Similarly to my comment on patch 1, these need to be described better. Sure, will fix this. Thanks, Ivan > > Thanks, > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi,
On Tue, 2013-08-06 at 15:03 +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> > drivers/usb/phy/Kconfig| 11 +
> > drivers/usb/phy/Makefile |2 +
> > drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> > drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
> >
> > 5 files changed, 793 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 000..550b496
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,49 @@
> > +MSM SuperSpeed USB3.0 SoC controllers
> > +
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb2";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
>
> Huh? That doesn't describe what these are. These would be better
> explained with a reference to clock-names and a basic description as to
> what the input's called, what it drives, etc, as you've done done for
> the *-supply properties.
Ok, I will fix this.
>
> > +- clock-names: "xo", "sleep_a_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
> > +
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb3";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
>
> Similarly, this doesn't describe what the clocks are.
Understood.
>
> > +- clock-names: "xo", "ref_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
> > +
> > +Example device nodes:
> > +
> > + dwc3_usb2: phy@f92f8800 {
> > + compatible = "qcom,dwc3-usb2";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a_clk";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
> > +
> > + dwc3_usb3: phy@f92f8830 {
> > + compatible = "qcom,dwc3-usb3";
> > + reg = <0xf92f8830 0x30>;
> > +
> > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "xo", "ref_clk";
> > +
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + };
>
>
> Those regster banks look suspiciously close. Are these the same IP
> block? Can they ever appear separately?
>
They are part of the wrapper Qualcomm logic around Synopsys USB3 core.
In this sense they are part of the one IP, I believe. Manage them from
separate drivers simplify code.
> Do the drivers not trample each other when messing with shared clocks
> and regulators?
>
Regulators and clocks have reference counting, right?, so this should
be safe. Even if they are part of the one driver, clocks and regulators
could be switched off only if both PHY's do not use them.
Thanks,
Ivan
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reg: USB: ehci-omap: Suspend the controller during idle.
Hi, On 08/06/2013 03:55 PM, Bharathraj Nagaraju wrote: > Dear All, > > We are working on omap4470 based device,kernel-3.0.31 is running on this. > In our device modem is connected to OMAP4470 using USB EHCI. > > In our current kernel code, clocks are enabled when ports get connected > and disabled during disconnect.Due to this current consumption is more in > idle use case. > > I have tried to put the host in smart idle/standby mode,due to erratas > around Host doesn't allow us > use smart idle/standby capabilities. > > 1) i571: USB host EHCI may stall when entering smart-standby mode > 2) i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock > > we are thinking to implement USB EHCI runtime suspend/resume feature. > > In kernel-3.0.31 architecture the usbcore driver is parent of ehci and ohci > drivers. > The ehci and ohci drivers call the pm_runtime_get_sync and > pm_runtime_put_sync of parent device usbhs core. > > From the ehci-omap driver what i can see only partial implementation of > runtime PM. > what i mean is that runtime PM methods are used only during the normal > suspend path > and when nothing is connected to ports(modem disconnected in our case). > > I am thinking to change the ehci driver code, could claver enough to use > runtime PM > to disable the hardware when modem is connected and the system is in idle > state. > > Kindly guide me how can i go about this. > > Let me know if you need further clarification from me on this. > > Thanks for spending your valuable time ...:) The problem with OMAP EHCI controller is that it needs to rely on IO Daisy chain mechanism to wake up when it is suspended. Without that, we can't really put the controller in to runtime suspend, else we will not be able to detect a new device connect. IO daisy chaining is still not supported in mainline. One approach had been posted [1] and it works but it is still in transition. I've made some patches [2] which implement USB runtime suspend with remote wakeup working for OMAP3 beagle-xm board. This depends on [1]. It shouldn't be hard to get it working on OMAP4. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/101105 [2] http://article.gmane.org/gmane.linux.ports.arm.kernel/251250 cheers, -roger -- 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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, Aug 06, 2013 at 12:53:11PM +0100, Ivan T. Ivanov wrote: > From: "Ivan T. Ivanov" What does the "glue layer" do? Is it an actual piece of hardware, or just some platform-specific code? > > Signed-off-by: Ivan T. Ivanov > --- > .../devicetree/bindings/usb/msm-ssusb.txt | 39 + > drivers/usb/dwc3/Kconfig |8 + > drivers/usb/dwc3/Makefile |1 + > drivers/usb/dwc3/dwc3-msm.c| 175 > > 4 files changed, 223 insertions(+) > create mode 100644 drivers/usb/dwc3/dwc3-msm.c > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > index 550b496..313ae0d 100644 > --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > @@ -22,6 +22,23 @@ Required "supply-name" examples are: > "v1p8" : 1.8v supply for SS-PHY > "vddcx" : vdd supply for SS-PHY digital circuit operation > > +Required properties : > +- compatible : should be "qcom,dwc-usb3-msm" > +- reg : offset and length of the register set in the memory map > + offset and length of the TCSR register for routing USB > + signals to either picoPHY0 or picoPHY1. > +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, <&usb30_sleep_cxc>, > <&usb30_mock_utmi_cxc>; Similarly to my comment on patch 1, these need to be described better. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 1/2] drivers: spi: Add qspi flash controller
On Sunday 04 August 2013 02:28 PM, Sourav Poddar wrote:
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
Test details:
-
Tested this on dra7 board.
Test1: Ran mtd_stesstest for 4 iterations.
- All iterations went through without failure.
Test2: Use mtd utilities:
- flash_erase to erase the flash device
- nanddump to read data back.
- nandwrite to write to the data flash.
diff between the write and read data shows zero.
Signed-off-by: Sourav Poddar
---
v8->v9
- fix return value
- fix error check
Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 +
drivers/spi/Kconfig |8 +
drivers/spi/Makefile |1 +
drivers/spi/spi-ti-qspi.c | 591 +
4 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
create mode 100644 drivers/spi/spi-ti-qspi.c
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
new file mode 100644
index 000..398ef59
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -0,0 +1,22 @@
+TI QSPI controller.
+
+Required properties:
+- compatible : should be "ti,dra7xxx-qspi".
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods: Name of the hwmod associated to the QSPI
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+qspi: qspi@4b30 {
+ compatible = "ti,dra7xxx-qspi";
+ reg =<0x4b30 0x100>;
+ #address-cells =<1>;
+ #size-cells =<0>;
+ spi-max-frequency =<2500>;
+ ti,hwmods = "qspi";
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..1c4e758 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,14 @@ config SPI_OMAP24XX
SPI master controller for OMAP24XX and later Multichannel SPI
(McSPI) modules.
+config SPI_TI_QSPI
+ tristate "DRA7xxx QSPI controller support"
+ depends on ARCH_OMAP2PLUS || COMPILE_TEST
+ help
+ QSPI master controller for DRA7xxx used for flash devices.
+ This device supports single, dual and quad read support, while
+ it only supports single write mode.
+
config SPI_OMAP_100K
tristate "OMAP SPI 100K"
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..a174030 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K) += spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX)+= spi-omap2-mcspi.o
+obj-$(CONFIG_SPI_TI_QSPI) += spi-ti-qspi.o
obj-$(CONFIG_SPI_ORION) += spi-orion.o
obj-$(CONFIG_SPI_PL022) += spi-pl022.o
obj-$(CONFIG_SPI_PPC4xx) += spi-ppc4xx.o
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..4328ae2
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
@@ -0,0 +1,591 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sourav Poddar
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GPLv2.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct ti_qspi_regs {
+ u32 clkctrl;
+};
+
+struct ti_qspi {
+ struct completion transfer_complete;
+
+ /* IRQ synchronization */
+ spinlock_t lock;
+
+ /* list synchronization */
+ struct mutexlist_lock;
+
+ struct spi_master *master;
+ void __iomem*base;
+ struct clk *fclk;
+ struct device *dev;
+
+ struct ti_qspi_regs ctx_reg;
+
Re: [RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> Signed-off-by: Ivan T. Ivanov
> ---
> .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> drivers/usb/phy/Kconfig| 11 +
> drivers/usb/phy/Makefile |2 +
> drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
>
> 5 files changed, 793 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> new file mode 100644
> index 000..550b496
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> @@ -0,0 +1,49 @@
> +MSM SuperSpeed USB3.0 SoC controllers
> +
> +Required properities :
> +- compatible sould be "qcom,dwc3-usb2";
> +- reg : offset and length of the register set in the memory map
> +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
Huh? That doesn't describe what these are. These would be better
explained with a reference to clock-names and a basic description as to
what the input's called, what it drives, etc, as you've done done for
the *-supply properties.
> +- clock-names: "xo", "sleep_a_clk";
> +-supply: phandle to the regulator device tree node
> +Required "supply-name" examples are:
> + "v1p8" : 1.8v supply for HSPHY
> + "v3p3" : 3.3v supply for HSPHY
> + "vbus" : vbus supply for host mode
> + "vddcx" : vdd supply for HS-PHY digital circuit operation
> +
> +Required properities :
> +- compatible sould be "qcom,dwc3-usb3";
> +- reg : offset and length of the register set in the memory map
> +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
Similarly, this doesn't describe what the clocks are.
> +- clock-names: "xo", "ref_clk";
> +-supply: phandle to the regulator device tree node
> +Required "supply-name" examples are:
> + "v1p8" : 1.8v supply for SS-PHY
> + "vddcx" : vdd supply for SS-PHY digital circuit operation
> +
> +Example device nodes:
> +
> + dwc3_usb2: phy@f92f8800 {
> + compatible = "qcom,dwc3-usb2";
> + reg = <0xf92f8800 0x30>;
> +
> + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> + clock-names = "xo", "sleep_a_clk";
> +
> + vbus-supply = <&supply>;
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + v3p3-supply = <&supply>;
> + };
> +
> + dwc3_usb3: phy@f92f8830 {
> + compatible = "qcom,dwc3-usb3";
> + reg = <0xf92f8830 0x30>;
> +
> + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> + clock-names = "xo", "ref_clk";
> +
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + };
Those regster banks look suspiciously close. Are these the same IP
block? Can they ever appear separately?
Do the drivers not trample each other when messing with shared clocks
and regulators?
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reg: USB: ehci-omap: Suspend the controller during idle.
On Tue, Aug 06, 2013 at 06:25:32PM +0530, Bharathraj Nagaraju wrote: > Dear All, > > We are working on omap4470 based device,kernel-3.0.31 is running on this. Have you tried the 3.10 kernel for this? I think you might find that this already is resolved there, as lots of pm USB work has happened in the past 2+ years since 3.0 was released. thanks, greg k-h -- 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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 13:21 +0100, Pawel Moll wrote:
> On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
>
> The same comment as for the RFC 1/2 here...
Will fix this.
>
> > .../devicetree/bindings/usb/msm-ssusb.txt | 39 +
> > drivers/usb/dwc3/Kconfig |8 +
> > drivers/usb/dwc3/Makefile |1 +
> > drivers/usb/dwc3/dwc3-msm.c| 175
> >
> > 4 files changed, 223 insertions(+)
> > create mode 100644 drivers/usb/dwc3/dwc3-msm.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > index 550b496..313ae0d 100644
> > --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -22,6 +22,23 @@ Required "supply-name" examples are:
> > "v1p8" : 1.8v supply for SS-PHY
> > "vddcx" : vdd supply for SS-PHY digital circuit operation
> >
> > +Required properties :
> > +- compatible : should be "qcom,dwc-usb3-msm"
> > +- reg : offset and length of the register set in the memory map
> > + offset and length of the TCSR register for routing USB
> > + signals to either picoPHY0 or picoPHY1.
> > +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > +- clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> > +
> > +Optional properties :
> > +- gdsc-supply : phandle to the globally distributed switch controller
> > + regulator node to the USB controller.
> > +
> > +Sub nodes:
> > +- Sub node for "DWC3- USB3 controller".
> > + This sub node is required property for device node. The properties of
> > this subnode
> > + are specified in dwc3.txt.
>
> Ah, this answers one of my questions - DWC3 comes from Synopsys.
Yes, sorry.
>
> > Example device nodes:
> >
> > dwc3_usb2: phy@f92f8800 {
> > @@ -47,3 +64,25 @@ Example device nodes:
> > vddcx-supply = <&supply>;
> > v1p8-supply = <&supply>;
> > };
> > +
> > + usb@fd4ab000 {
> > + compatible = "qcom,dwc-usb3-msm";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0xfd4ab000 0x4>;
> > +
> > + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> > +
> > + gdsc-supply = <&supply>;
> > + ranges;
> > +
> > + dwc3@f920 {
> > + compatible = "snps,dwc3";
>
> Note that the Documentation/devicetree/bindings/usb/dwc3.txt is
> mentioning "synopsys,dwc3" (which is clearly in opposition to the
> vendor-prefixes.txt file) and this compatible value is used in the
> drivers/usb/dwc3/core.c and omap5.dtsi. Unless it has been already fixed
> recently, could you take care of that?
Yes, it is fixed already. Patch is in linux-next
"usb: dwc3: core: switch to snps,dwc3"
>
> > + reg = <0xf920 0xcd00>;
> > + interrupts = <0 131 0>;
> > + interrupt-names = "irq";
> > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
> > + tx-fifo-resize;
> > + };
> > + };
>
> And now I'm really confused... Maybe it's just lack of documentation...
>
> How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"?
Not sure from where you get this "qcom,dwc-usb3", but now I think
that "qcom,dwc-usb3" should be enough for compatible.
Thanks,
Ivan
>
> Paweł
--
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 5/5] arm: omap: Proper cleanups for omap_device
Am 06.08.2013 12:14, schrieb Greg Kroah-Hartman: >> What exactly is a platform device anyway? > > Originally it was a "something that wasn't connected to a bus, but just > had memory-mapped i/o." Like the PS2 keyboard controller. > > Embedded systems got ahold of this and went to town, and made everything > a platform device because they could, and no one was paying attention. > > Then OF came along and used it as well, and you know the rest... > > I think we need to get the ACPI and OF people, and me, in a room > together at the kernel summit and not let us out until we have this all > worked out. MFD uses platform devices too. Regards, Alexander Holler -- 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 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi,
On Tue, 2013-08-06 at 13:12 +0100, Pawel Moll wrote:
> On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
>
> I am sure that the information in the subject is more than enough for
> you, but would you care to give some more background for the commit log?
> Where can we find such controllers? What is DWC3 core? Is it
> Qualcomm-specific block, or does it come from one of the IP providers
> like Synopsys or Cadence?
>
You are right, I have to add more info here. DesignWare USB Core could
also be found in TI OMAP's and Samasung SoC's, at least. And it is
IP from Synopsys. Usually SoC vendors wrap it with additional logic,
which provides required clocks and power supplies.
> > .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> > drivers/usb/phy/Kconfig| 11 +
> > drivers/usb/phy/Makefile |2 +
> > drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> > drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
> >
> > 5 files changed, 793 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 000..550b496
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,49 @@
> > +MSM SuperSpeed USB3.0 SoC controllers
>
> I understand that the device always come in doublets? As in: are nodes
> for both USB2 and 3 always required?
The core dwc3 driver expects 2 USB PHY interfaces, so both nodes
are mandatory.
>
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb2";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
> > +- clock-names: "xo", "sleep_a_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
>
> So required or examples? ;-)
It should be Required, will fix this.
>
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
> >
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb3";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
> > +- clock-names: "xo", "ref_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
> > +
> > +Example device nodes:
> > +
> > + dwc3_usb2: phy@f92f8800 {
> > + compatible = "qcom,dwc3-usb2";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a_clk";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
> > +
> > + dwc3_usb3: phy@f92f8830 {
> > + compatible = "qcom,dwc3-usb3";
> > + reg = <0xf92f8830 0x30>;
> > +
> > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "xo", "ref_clk";
> > +
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + };
>
> Note that I had a look at the bindings only - I don't feel competent to
> review the drivers/usb part of the patch...
Sure, thank you.
Ivan
>
> Thanks!
>
> Pawel
--
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/7] usb: phy: omap: Add new PHY types and remove omap_control_usb3_phy_power()
On 08/06/2013 02:45 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
>> TYPE2 meaning has changed. It is now a USB2 phy with Power down bit in
>> control_dev_conf register.
>>
>> Introduce TYPE3 and TYPE4 PHY. TYPE3 is USB3 phy with DPLL and individual
>> TX/RX power control. TYPE4 is USB2 phy with power aux register.
>>
>> Update DT binding information to reflect these changes.
>>
>> Also get rid of omap_control_usb3_phy_power(). Just one function
>> i.e. omap_control_usb_phy_power() will now take care of all PHY types.
>>
>> Signed-off-by: Roger Quadros
>
> Tested-by: Kishon Vijay Abraham I
> but one minor comment below.
>> ---
>> Documentation/devicetree/bindings/usb/omap-usb.txt | 23 ++--
>> drivers/usb/phy/phy-omap-control.c | 129
>> +++-
>> drivers/usb/phy/phy-omap-usb2.c|4 +
>> drivers/usb/phy/phy-omap-usb3.c|6 +-
>> include/linux/usb/omap_control_usb.h | 18 ++--
>> 5 files changed, 100 insertions(+), 80 deletions(-)
>>
> .
> .
>
> .
> .
>
>> +omap_control_usb_phy_power(phy->control_dev, 0);
>> usb_add_phy_dev(&phy->phy);
>>
>> platform_set_drvdata(pdev, phy);
>> diff --git a/include/linux/usb/omap_control_usb.h
>> b/include/linux/usb/omap_control_usb.h
>> index 27b5b8c..7f027d3 100644
>> --- a/include/linux/usb/omap_control_usb.h
>> +++ b/include/linux/usb/omap_control_usb.h
>> @@ -22,9 +22,9 @@
>
>> struct omap_control_usb {
>> struct device *dev;
>>
>> -u32 __iomem *dev_conf;
>> u32 __iomem *otghs_control;
>> -u32 __iomem *phy_power;
>> +u32 __iomem *power;
>> +u32 __iomem *power_aux;
>>
>> struct clk *sys_clk;
>>
> you can remove omap_control_usb_platform_data from here.
>
OK.
cheers,
-roger
--
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/7] usb: musb: omap2430: Don't use omap_get_control_dev()
On 08/06/2013 02:51 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
>> omap_get_control_dev() is being deprecated as it doesn't support
>> multiple instances. As control device is present only from OMAP4
>> onwards which supports DT only, we use phandles to get the
>> reference to the control device.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/musb/omap2430.c | 22 ++
>> 1 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index ebb46ec..1db9588 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -38,6 +38,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "musb_core.h"
>> #include "omap2430.h"
>> @@ -547,12 +548,25 @@ static int omap2430_probe(struct platform_device *pdev)
>> }
>>
>> if (pdata->has_mailbox) {
>
> I think you can remove this this check all together. Mailbox is present only
> from OMAP4 so it can be dt only.
>
OK.
cheers,
-roger
--
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
Reg: USB: ehci-omap: Suspend the controller during idle.
Dear All,
We are working on omap4470 based device,kernel-3.0.31 is running on this.
In our device modem is connected to OMAP4470 using USB EHCI.
In our current kernel code, clocks are enabled when ports get connected
and disabled during disconnect.Due to this current consumption is more in
idle use case.
I have tried to put the host in smart idle/standby mode,due to erratas around
Host doesn't allow us
use smart idle/standby capabilities.
1) i571: USB host EHCI may stall when entering smart-standby mode
2) i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
we are thinking to implement USB EHCI runtime suspend/resume feature.
In kernel-3.0.31 architecture the usbcore driver is parent of ehci and ohci
drivers.
The ehci and ohci drivers call the pm_runtime_get_sync and
pm_runtime_put_sync of parent device usbhs core.
From the ehci-omap driver what i can see only partial implementation of
runtime PM.
what i mean is that runtime PM methods are used only during the normal
suspend path
and when nothing is connected to ports(modem disconnected in our case).
I am thinking to change the ehci driver code, could claver enough to use
runtime PM
to disable the hardware when modem is connected and the system is in idle
state.
Kindly guide me how can i go about this.
Let me know if you need further clarification from me on this.
Thanks for spending your valuable time ...:)
Cheers
Bharath
SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary
or legally privileged information. In case you are not the original intended
Recipient of the message, you must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message and you are requested to
delete it and inform the sender. Any views expressed in this message are those
of the individual sender unless otherwise stated. Nothing contained in this
message shall be construed as an offer or acceptance of any offer by Sasken
Communication Technologies Limited ("Sasken") unless sent with that express
intent and with due authority of Sasken. Sasken has taken enough precautions to
prevent the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> Signed-off-by: Ivan T. Ivanov
The same comment as for the RFC 1/2 here...
> .../devicetree/bindings/usb/msm-ssusb.txt | 39 +
> drivers/usb/dwc3/Kconfig |8 +
> drivers/usb/dwc3/Makefile |1 +
> drivers/usb/dwc3/dwc3-msm.c| 175
>
> 4 files changed, 223 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-msm.c
>
> diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> index 550b496..313ae0d 100644
> --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> @@ -22,6 +22,23 @@ Required "supply-name" examples are:
> "v1p8" : 1.8v supply for SS-PHY
> "vddcx" : vdd supply for SS-PHY digital circuit operation
>
> +Required properties :
> +- compatible : should be "qcom,dwc-usb3-msm"
> +- reg : offset and length of the register set in the memory map
> + offset and length of the TCSR register for routing USB
> + signals to either picoPHY0 or picoPHY1.
> +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, <&usb30_sleep_cxc>,
> <&usb30_mock_utmi_cxc>;
> +- clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> +
> +Optional properties :
> +- gdsc-supply : phandle to the globally distributed switch controller
> + regulator node to the USB controller.
> +
> +Sub nodes:
> +- Sub node for "DWC3- USB3 controller".
> + This sub node is required property for device node. The properties of this
> subnode
> + are specified in dwc3.txt.
Ah, this answers one of my questions - DWC3 comes from Synopsys.
> Example device nodes:
>
> dwc3_usb2: phy@f92f8800 {
> @@ -47,3 +64,25 @@ Example device nodes:
> vddcx-supply = <&supply>;
> v1p8-supply = <&supply>;
> };
> +
> + usb@fd4ab000 {
> + compatible = "qcom,dwc-usb3-msm";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xfd4ab000 0x4>;
> +
> + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> + clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> +
> + gdsc-supply = <&supply>;
> + ranges;
> +
> + dwc3@f920 {
> + compatible = "snps,dwc3";
Note that the Documentation/devicetree/bindings/usb/dwc3.txt is
mentioning "synopsys,dwc3" (which is clearly in opposition to the
vendor-prefixes.txt file) and this compatible value is used in the
drivers/usb/dwc3/core.c and omap5.dtsi. Unless it has been already fixed
recently, could you take care of that?
> + reg = <0xf920 0xcd00>;
> + interrupts = <0 131 0>;
> + interrupt-names = "irq";
> + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
> + tx-fifo-resize;
> + };
> + };
And now I'm really confused... Maybe it's just lack of documentation...
How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"?
Paweł
--
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 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> Signed-off-by: Ivan T. Ivanov
I am sure that the information in the subject is more than enough for
you, but would you care to give some more background for the commit log?
Where can we find such controllers? What is DWC3 core? Is it
Qualcomm-specific block, or does it come from one of the IP providers
like Synopsys or Cadence?
> .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> drivers/usb/phy/Kconfig| 11 +
> drivers/usb/phy/Makefile |2 +
> drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
>
> 5 files changed, 793 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> new file mode 100644
> index 000..550b496
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> @@ -0,0 +1,49 @@
> +MSM SuperSpeed USB3.0 SoC controllers
I understand that the device always come in doublets? As in: are nodes
for both USB2 and 3 always required?
> +Required properities :
> +- compatible sould be "qcom,dwc3-usb2";
> +- reg : offset and length of the register set in the memory map
> +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
> +- clock-names: "xo", "sleep_a_clk";
> +-supply: phandle to the regulator device tree node
> +Required "supply-name" examples are:
So required or examples? ;-)
> + "v1p8" : 1.8v supply for HSPHY
> + "v3p3" : 3.3v supply for HSPHY
> + "vbus" : vbus supply for host mode
> + "vddcx" : vdd supply for HS-PHY digital circuit operation
>
> +Required properities :
> +- compatible sould be "qcom,dwc3-usb3";
> +- reg : offset and length of the register set in the memory map
> +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
> +- clock-names: "xo", "ref_clk";
> +-supply: phandle to the regulator device tree node
> +Required "supply-name" examples are:
> + "v1p8" : 1.8v supply for SS-PHY
> + "vddcx" : vdd supply for SS-PHY digital circuit operation
> +
> +Example device nodes:
> +
> + dwc3_usb2: phy@f92f8800 {
> + compatible = "qcom,dwc3-usb2";
> + reg = <0xf92f8800 0x30>;
> +
> + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> + clock-names = "xo", "sleep_a_clk";
> +
> + vbus-supply = <&supply>;
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + v3p3-supply = <&supply>;
> + };
> +
> + dwc3_usb3: phy@f92f8830 {
> + compatible = "qcom,dwc3-usb3";
> + reg = <0xf92f8830 0x30>;
> +
> + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> + clock-names = "xo", "ref_clk";
> +
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + };
Note that I had a look at the bindings only - I don't feel competent to
review the drivers/usb part of the patch...
Thanks!
Pawel
--
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 7/9] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On 08/06/2013 11:11 AM, Rajendra Nayak wrote:
Hi Grygorii,
On Monday 05 August 2013 05:14 PM, Grygorii Strashko wrote:
On 08/04/2013 07:27 PM, Rajendra Nayak wrote:
From: R Sricharan
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.
Since DRA7 is a platform supported only using DT, the cpu detection
is based on the compatibles passed from DT blobs as suggested here
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187712.html
Suggested-by: Felipe Balbi
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
Acked-by: Santosh Shilimkar
---
arch/arm/mach-omap1/include/mach/soc.h |1 +
arch/arm/mach-omap2/id.c |4 ++--
arch/arm/mach-omap2/soc.h | 17 +
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/soc.h
b/arch/arm/mach-omap1/include/mach/soc.h
index 6cf9c1c..612bd1c 100644
--- a/arch/arm/mach-omap1/include/mach/soc.h
+++ b/arch/arm/mach-omap1/include/mach/soc.h
@@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
#define cpu_is_omap34xx()0
#define cpu_is_omap44xx()0
#define soc_is_omap54xx()0
+#define soc_is_dra7xx()0
#define soc_is_am33xx()0
#define cpu_class_is_omap1()1
#define cpu_class_is_omap2()0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..0289adc 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,7 +61,7 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
-} else if (soc_is_omap54xx()) {
+} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
val &= OMAP5_DEVICETYPE_MASK;
val >>= 6;
@@ -116,7 +116,7 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
-if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..4588df1 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -8,6 +8,7 @@
* Written by Tony Lindgren
*
* Added OMAP4/5 specific defines - Santosh
Shilimkar
+ * Added DRA7xxx specific defines - Sricharan R
*
* 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
@@ -35,6 +36,7 @@
#ifndef __ASSEMBLY__
#include
+#include
/*
* Test if multicore OMAP support is needed
@@ -105,6 +107,15 @@
# endif
#endif
+#ifdef CONFIG_SOC_DRA7XX
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME DRA7XX
+# endif
+#endif
+
/*
* Omap device type i.e. EMU/HS/TST/GP/BAD
*/
@@ -233,6 +244,7 @@ IS_AM_SUBCLASS(437x, 0x437)
#define cpu_is_omap447x()0
#define soc_is_omap54xx()0
#define soc_is_omap543x()0
+#define soc_is_dra7xx()0
#if defined(MULTI_OMAP2)
# if defined(CONFIG_ARCH_OMAP2)
@@ -379,6 +391,11 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x()is_omap543x()
#endif
+#if defined(CONFIG_SOC_DRA7XX)
+#undef soc_is_dra7xx
+#define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
Wouldn't that be too expensive to call of_machine_is_compatible every
time for DRA7 detection?
Ideally these soc checks should happen only once at init (see PATCH 8/9 in the
series for instance) so there should not be a 'every time' penalty.
Ok, Agreed then.
regards,
Rajendra
May be static variable can be used to store DRA7 presence status,
smth. like this:
static inline int is_dra7xx(void)
{
static int is_dra7 = -1;
if (is_dra7 < 0)
is_dra7 = of_machine_is_compatible("ti,dra7");
return !!is_dra7;
}
(it's just an idea, not verified)
+#endif
+
/* Various silicon revisions for omap2 */
#define OMAP242X_CLASS0x24200024
#define OMAP2420_REV_ES1_0OMAP242X_CLASS
Regards,
-grygorii
--
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
[RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
drivers/usb/phy/Kconfig| 11 +
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
5 files changed, 793 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..550b496
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,49 @@
+MSM SuperSpeed USB3.0 SoC controllers
+
+Required properities :
+- compatible sould be "qcom,dwc3-usb2";
+- reg : offset and length of the register set in the memory map
+- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
+- clock-names: "xo", "sleep_a_clk";
+-supply: phandle to the regulator device tree node
+Required "supply-name" examples are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+Required properities :
+- compatible sould be "qcom,dwc3-usb3";
+- reg : offset and length of the register set in the memory map
+- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
+- clock-names: "xo", "ref_clk";
+-supply: phandle to the regulator device tree node
+Required "supply-name" examples are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+Example device nodes:
+
+ dwc3_usb2: phy@f92f8800 {
+ compatible = "qcom,dwc3-usb2";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a_clk";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_usb3: phy@f92f8830 {
+ compatible = "qcom,dwc3-usb3";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref_clk";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5443958..40e83b5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -202,6 +202,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 98730ca..53355ec 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-usb2.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-usb3.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-usb2.c
b/drivers/usb/phy/phy-msm-dwc3-usb2.c
new file mode 100644
index 000..174c72c
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-usb2.c
@@ -0,0 +1,342 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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
+
[RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 39 +
drivers/usb/dwc3/Kconfig |8 +
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c| 175
4 files changed, 223 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
index 550b496..313ae0d 100644
--- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -22,6 +22,23 @@ Required "supply-name" examples are:
"v1p8" : 1.8v supply for SS-PHY
"vddcx" : vdd supply for SS-PHY digital circuit operation
+Required properties :
+- compatible : should be "qcom,dwc-usb3-msm"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, <&usb30_sleep_cxc>,
<&usb30_mock_utmi_cxc>;
+- clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+Sub nodes:
+- Sub node for "DWC3- USB3 controller".
+ This sub node is required property for device node. The properties of this
subnode
+ are specified in dwc3.txt.
+
Example device nodes:
dwc3_usb2: phy@f92f8800 {
@@ -47,3 +64,25 @@ Example device nodes:
vddcx-supply = <&supply>;
v1p8-supply = <&supply>;
};
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc-usb3-msm";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
<&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+ gdsc-supply = <&supply>;
+ ranges;
+
+ dwc3@f920 {
+ compatible = "snps,dwc3";
+ reg = <0xf920 0xcd00>;
+ interrupts = <0 131 0>;
+ interrupt-names = "irq";
+ usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
+ tx-fifo-resize;
+ };
+ };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 3e225d5..e2032c4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -70,6 +70,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+#undef CONFIG_REGULATOR
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_msm {
+ struct device *dev;
+ void __iomem*base;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+
[RFC 0/2] DWC3 USB support for Qualcomm platform
From: "Ivan T. Ivanov" Hi, These patches add basic support for USB3.0 controllers found on MSM platforms. First patch add 2 USB PHY drivers and second one add support for Qualcomm wrapper IP over DWC3 controller. Patches are just skeletons, no power management. DWC3 IP in MSM also support OTG but right now I am not sure how to add support for it. Probably OTG have to be instantiated from core dwc3 driver, but usually PHY drivers are those which create OTG instance. Generated on top of Felipe 'testing' branch. Regards, Ivan Ivan T. Ivanov (2): usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 88 + drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 175 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 + drivers/usb/phy/phy-msm-dwc3-usb3.c| 389 8 files changed, 1016 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: phy: omap: get rid of omap_get_control_dev()
On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros
Tested-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linux/usb/omap_control_usb.h |5 -
2 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index cf93c5a..015eeef 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -25,26 +25,6 @@
#include
#include
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
- if (!control_usb)
- return ERR_PTR(-ENODEV);
-
- return control_usb->dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
/**
* omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
@@ -187,11 +167,19 @@ void omap_control_usb_set_mode(struct device *dev,
{
struct omap_control_usb *ctrl_usb;
- if (IS_ERR(dev) || control_usb->type != OMAP_CTRL_DEV_TYPE1)
+ if (IS_ERR(dev) || !dev)
return;
ctrl_usb = dev_get_drvdata(dev);
+ if (!ctrl_usb) {
+ dev_err(dev, "Invalid control usb device\n");
+ return;
+ }
+
+ if (ctrl_usb->type != OMAP_CTRL_DEV_TYPE1)
+ return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -214,6 +202,7 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
struct device_node *np = pdev->dev.of_node;
struct omap_control_usb_platform_data *pdata =
dev_get_platdata(&pdev->dev);
+ struct omap_control_usb *control_usb;
control_usb = devm_kzalloc(&pdev->dev, sizeof(*control_usb),
GFP_KERNEL);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 7f027d3..8b48584 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -67,15 +67,10 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev(void)
-{
- return ERR_PTR(-ENODEV);
-}
static inline void omap_control_usb_phy_power(struct device *dev, int on)
{
--
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/7] usb: phy: omap-usb2: Don't use omap_get_control_dev()
On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
Tested-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-omap-usb2.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 376b367..77e0cf4 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -124,6 +125,8 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
if (!node)
return -ENODEV;
@@ -148,11 +151,18 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg = otg;
phy->phy.type= USB_PHY_TYPE_USB2;
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
return -ENODEV;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -ENODEV;
+ }
+
+ phy->control_dev = &control_pdev->dev;
phy->is_suspended= 1;
omap_control_usb_phy_power(phy->control_dev, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] usb: musb: omap2430: Don't use omap_get_control_dev()
Hi,
On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Signed-off-by: Roger Quadros
---
drivers/usb/musb/omap2430.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..1db9588 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
#include "omap2430.h"
@@ -547,12 +548,25 @@ static int omap2430_probe(struct platform_device *pdev)
}
if (pdata->has_mailbox) {
I think you can remove this this check all together. Mailbox is present
only from OMAP4 so it can be dt only.
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 3/7] usb: phy: omap-usb3: Don't use omap_get_control_dev()
On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
Tested-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-omap-usb3.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..bad032e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#define PLL_STATUS 0x0004
#define PLL_GO 0x0008
@@ -198,6 +199,12 @@ static int omap_usb3_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
struct resource *res;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -ENODEV;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
return -ENODEV;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -ENODEV;
+ }
+
+ phy->control_dev = &control_pdev->dev;
omap_control_usb_phy_power(phy->control_dev, 0);
usb_add_phy_dev(&phy->phy);
--
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/7] usb: phy: omap: Add new PHY types and remove omap_control_usb3_phy_power()
Hi,
On Thursday 01 August 2013 07:35 PM, Roger Quadros wrote:
TYPE2 meaning has changed. It is now a USB2 phy with Power down bit in
control_dev_conf register.
Introduce TYPE3 and TYPE4 PHY. TYPE3 is USB3 phy with DPLL and individual
TX/RX power control. TYPE4 is USB2 phy with power aux register.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros
Tested-by: Kishon Vijay Abraham I
but one minor comment below.
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 23 ++--
drivers/usb/phy/phy-omap-control.c | 129 +++-
drivers/usb/phy/phy-omap-usb2.c|4 +
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 18 ++--
5 files changed, 100 insertions(+), 80 deletions(-)
.
.
.
.
+ omap_control_usb_phy_power(phy->control_dev, 0);
usb_add_phy_dev(&phy->phy);
platform_set_drvdata(pdev, phy);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..7f027d3 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -22,9 +22,9 @@
struct omap_control_usb {
struct device *dev;
- u32 __iomem *dev_conf;
u32 __iomem *otghs_control;
- u32 __iomem *phy_power;
+ u32 __iomem *power;
+ u32 __iomem *power_aux;
struct clk *sys_clk;
you can remove omap_control_usb_platform_data from 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 1/5] pdev: Fix platform device resource linking
Hi Greg, On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: > On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: >> Hi Greg, >> >> On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: >> >>> On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. >>> >>> Ugh, the OF core shouldn't be creating platform devices. Well, yes, I >>> know it does that today, but ick, ick, ick. >>> >> >> Yep, ick, ick, ick is the correct form. >> Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. >>> >>> Why would anyone need to call this? I'm getting the feeling that OF >>> should just have it's own bus of devices to handle this type of mess. >>> ACPI is going through the same rewrite for this same type of problem >>> (they did things differently.) I suggest you work with the ACPI >>> developers to so the same thing they are, to solve it correctly for >>> everyone. >>> >> >> It's the same problem really. Another bus type might not fly well. >> The same device driver should be (in theory) be made to work unchanged >> either on an OF/ACPI/Fex( :) ) setup. > > No, that's not quite true, a driver needs to know how to talk to the > bus, as that is how it communicates to the hardware. It can be done for > different types of busses (see the OHCI USB controller for one example > of this), but a driver will have to know what type of bus it is on in > order to work properly. > In the case of OF & ACPI there is no 'bus'. The device is probably integrated in the SoC's silicon, but there is absolutely no way to 'probe' for it's existence; you have to use a-priori knowledge of the SoC's topology in order to configure it (along with any per-board specific information if there is any kind of shared resource configuration - i.e. pinmuxing or something else). There are the 3 well known methods to do so in the Linux kernel right now: 1) Board files in which the configuration information is stored in the per-board platform file encoded in platform data structures. 2) OF, in which case the information is provided via the flat device tree blob the bootloader provides. 3) ACPI in which case the information is provided via the firmware's ACPI tables (I'm not overly familiar with ACPI, so there might be some more nuance here). The device driver for all these cases is absolutely the same; the only place where it differs it's in the way it uses to retrieve that configuration information. The board file method is pretty much no-go due to the need to support multiple boards from a single kernel; that leaves OF and ACPI. >From what I can tell what ACPI supports is a very small subset of what OF can >support right now; that is both number of device drivers, as well as what you can do with device driver functionality (see things like gpios etc, how much easier is to use with OF). Since we're in the let's make a wish stage, what I wish for is a board-file & ACPI translator stage to OF data, and depreciating everything else gradually. That would kill platform_device and ACPI specific data and move everything to a common device structure supporting OF for configuration. >> What would it take to move all this into driver core? > > What specifically would you move into there? > Pretty much everything that's in the union of platform_device & whatever acpi uses to hold it's configuration info. > thanks, > > greg k-h Regards -- Pantelis -- 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] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 06:15:27PM +0800, Greg Kroah-Hartman wrote: > On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: > > What would it take to move all this into driver core? > > What specifically would you move into there? A variable to hold the streaming dma_mask, so that its in struct device rather than having to be separate. Yes, we can keep the pointer in there too, because that appears to convey meaning in the kernel today - whether the device can do DMA or not. A NULL dma_mask pointer already means it can't and dma_set_mask() always fails. A non-NULL dma_mask pointer means the driver can use dma_set_mask() to set an appropriate mask. -- 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] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: > Hi Greg, > > On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: > > > On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: > >> Platform device removal uncovered a number of problems with > >> the way resources are handled in the core platform code. > >> > >> Resources now form child/parent linkages and this requires > >> proper linking of the resources. On top of that the OF core > >> directly creates it's own platform devices. Simplify things > >> by providing helper functions that manage the linking properly. > > > > Ugh, the OF core shouldn't be creating platform devices. Well, yes, I > > know it does that today, but ick, ick, ick. > > > > Yep, ick, ick, ick is the correct form. > > >> Two functions are provided: > >> > >> platform_device_link_resources(), which links all the > >> linkable resources (if not already linked). > >> > >> and platform_device_unlink_resources(), which unlinks all the > >> resources. > > > > Why would anyone need to call this? I'm getting the feeling that OF > > should just have it's own bus of devices to handle this type of mess. > > ACPI is going through the same rewrite for this same type of problem > > (they did things differently.) I suggest you work with the ACPI > > developers to so the same thing they are, to solve it correctly for > > everyone. > > > > It's the same problem really. Another bus type might not fly well. > The same device driver should be (in theory) be made to work unchanged > either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. > What would it take to move all this into driver core? What specifically would you move into there? thanks, greg k-h -- 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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 12:37:25PM +0300, Pantelis Antoniou wrote: > > I don't like this at all, sorry. > > > > Don't shoot the messenger please... > > This is all about fixing a crash without messing too many things. I understand, it's not your fault at all. > > And I was waiting for the day when people started to finally remove > > platform devices from the system, I always thought it would never work > > properly. Good luck with this, I think you have a lot of work ahead of > > yourself... > > > > I know. > > Platform device removal is the wild-wild west... > > If I had to make a wish, would be to kill platform_device completely and > integrate all it's functionality in the the vanilla device. YES > What exactly is a platform device anyway? Originally it was a "something that wasn't connected to a bus, but just had memory-mapped i/o." Like the PS2 keyboard controller. Embedded systems got ahold of this and went to town, and made everything a platform device because they could, and no one was paying attention. Then OF came along and used it as well, and you know the rest... I think we need to get the ACPI and OF people, and me, in a room together at the kernel summit and not let us out until we have this all worked out. thanks, greg k-h -- 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] pdev: Fix platform device resource linking
Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: > On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: >> Platform device removal uncovered a number of problems with >> the way resources are handled in the core platform code. >> >> Resources now form child/parent linkages and this requires >> proper linking of the resources. On top of that the OF core >> directly creates it's own platform devices. Simplify things >> by providing helper functions that manage the linking properly. > > Ugh, the OF core shouldn't be creating platform devices. Well, yes, I > know it does that today, but ick, ick, ick. > Yep, ick, ick, ick is the correct form. >> Two functions are provided: >> >> platform_device_link_resources(), which links all the >> linkable resources (if not already linked). >> >> and platform_device_unlink_resources(), which unlinks all the >> resources. > > Why would anyone need to call this? I'm getting the feeling that OF > should just have it's own bus of devices to handle this type of mess. > ACPI is going through the same rewrite for this same type of problem > (they did things differently.) I suggest you work with the ACPI > developers to so the same thing they are, to solve it correctly for > everyone. > It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. What would it take to move all this into driver core? > thanks, > > greg k-h Regards -- Pantelis -- 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 5/5] arm: omap: Proper cleanups for omap_device
Hi Greg,
On Aug 6, 2013, at 12:33 PM, Greg Kroah-Hartman wrote:
> On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
>> Removing any omap device always resulted in a crash; turns out
>> BUS_NOTIFY_DEL_DEVICE is not the last notifier event sent in the
>> course of removing the device, the correct event is
>> BUS_NOTIFY_UNBOUND_DRIVER, which still is not the right place to
>> perform the cleanup. A device callback handles that properly, as
>> well as making sure the hwmods of the device are shutdown.
>>
>> Signed-off-by: Pantelis Antoniou
>> ---
>> arch/arm/mach-omap2/omap_device.c | 34 --
>> 1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_device.c
>> b/arch/arm/mach-omap2/omap_device.c
>> index f33b40c..6dec521 100644
>> --- a/arch/arm/mach-omap2/omap_device.c
>> +++ b/arch/arm/mach-omap2/omap_device.c
>> @@ -178,6 +178,32 @@ odbfd_exit:
>> return ret;
>> }
>>
>> +static void _omap_device_cleanup(struct device *dev)
>> +{
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct omap_device *od;
>> +struct omap_hwmod *oh;
>> +int i;
>> +
>> +od = pdev->archdata.od;
>> +if (!od)
>> +return;
>> +
>> +for (i = 0; i < od->hwmods_cnt; i++) {
>> +
>> +oh = od->hwmods[i];
>> +
>> +/* shutdown hwmods */
>> +omap_hwmod_shutdown(oh);
>> +
>> +/* we don't remove clocks cause there's no API to do so */
>> +/* no harm done, since they will not be created next time */
>> +}
>> +
>> +/* cleanup the structure now */
>> +omap_device_delete(od);
>> +}
>> +
>> static int _omap_device_notifier_call(struct notifier_block *nb,
>>unsigned long event, void *dev)
>> {
>> @@ -185,9 +211,13 @@ static int _omap_device_notifier_call(struct
>> notifier_block *nb,
>> struct omap_device *od;
>>
>> switch (event) {
>> -case BUS_NOTIFY_DEL_DEVICE:
>> +case BUS_NOTIFY_UNBOUND_DRIVER:
>> +/* NOTIFY_DEL_DEVICE is not the right call...
>> + * we use a callback here, to make sure no-one is going to
>> + * try to use the omap_device data after they're deleted
>> + */
>> if (pdev->archdata.od)
>> -omap_device_delete(pdev->archdata.od);
>> +device_schedule_callback(dev, _omap_device_cleanup);
>
> Really? This is one sign that you are totally using the driver core
> incorrectly. You shouldn't have to rely on notifier callbacks to handle
> device removals, your bus code should do that for you directly.
>
> I don't like this at all, sorry.
>
Don't shoot the messenger please...
This is all about fixing a crash without messing too many things.
> And I was waiting for the day when people started to finally remove
> platform devices from the system, I always thought it would never work
> properly. Good luck with this, I think you have a lot of work ahead of
> yourself...
>
I know.
Platform device removal is the wild-wild west...
If I had to make a wish, would be to kill platform_device completely and
integrate all it's functionality in the the vanilla device.
What exactly is a platform device anyway?
> greg k-h
Regards
-- Pantelis
--
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] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: > Platform device removal uncovered a number of problems with > the way resources are handled in the core platform code. > > Resources now form child/parent linkages and this requires > proper linking of the resources. On top of that the OF core > directly creates it's own platform devices. Simplify things > by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. > Two functions are provided: > > platform_device_link_resources(), which links all the > linkable resources (if not already linked). > > and platform_device_unlink_resources(), which unlinks all the > resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. thanks, greg k-h -- 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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
> Removing any omap device always resulted in a crash; turns out
> BUS_NOTIFY_DEL_DEVICE is not the last notifier event sent in the
> course of removing the device, the correct event is
> BUS_NOTIFY_UNBOUND_DRIVER, which still is not the right place to
> perform the cleanup. A device callback handles that properly, as
> well as making sure the hwmods of the device are shutdown.
>
> Signed-off-by: Pantelis Antoniou
> ---
> arch/arm/mach-omap2/omap_device.c | 34 --
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
> index f33b40c..6dec521 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,32 @@ odbfd_exit:
> return ret;
> }
>
> +static void _omap_device_cleanup(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_device *od;
> + struct omap_hwmod *oh;
> + int i;
> +
> + od = pdev->archdata.od;
> + if (!od)
> + return;
> +
> + for (i = 0; i < od->hwmods_cnt; i++) {
> +
> + oh = od->hwmods[i];
> +
> + /* shutdown hwmods */
> + omap_hwmod_shutdown(oh);
> +
> + /* we don't remove clocks cause there's no API to do so */
> + /* no harm done, since they will not be created next time */
> + }
> +
> + /* cleanup the structure now */
> + omap_device_delete(od);
> +}
> +
> static int _omap_device_notifier_call(struct notifier_block *nb,
> unsigned long event, void *dev)
> {
> @@ -185,9 +211,13 @@ static int _omap_device_notifier_call(struct
> notifier_block *nb,
> struct omap_device *od;
>
> switch (event) {
> - case BUS_NOTIFY_DEL_DEVICE:
> + case BUS_NOTIFY_UNBOUND_DRIVER:
> + /* NOTIFY_DEL_DEVICE is not the right call...
> + * we use a callback here, to make sure no-one is going to
> + * try to use the omap_device data after they're deleted
> + */
> if (pdev->archdata.od)
> - omap_device_delete(pdev->archdata.od);
> + device_schedule_callback(dev, _omap_device_cleanup);
Really? This is one sign that you are totally using the driver core
incorrectly. You shouldn't have to rely on notifier callbacks to handle
device removals, your bus code should do that for you directly.
I don't like this at all, sorry.
And I was waiting for the day when people started to finally remove
platform devices from the system, I always thought it would never work
properly. Good luck with this, I think you have a lot of work ahead of
yourself...
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: AM33xx: clock: Add RNG clock data
Add clock data for RNG module on AM33xx SoC.
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-omap2/cclock33xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ba6534d..865d30e 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -421,6 +421,10 @@ static struct clk aes0_fck;
DEFINE_STRUCT_CLK_HW_OMAP(aes0_fck, NULL);
DEFINE_STRUCT_CLK(aes0_fck, dpll_core_ck_parents, clk_ops_null);
+static struct clk rng_fck;
+DEFINE_STRUCT_CLK_HW_OMAP(rng_fck, NULL);
+DEFINE_STRUCT_CLK(rng_fck, dpll_core_ck_parents, clk_ops_null);
+
/*
* Modules clock nodes
*
@@ -966,6 +970,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "smartreflex1_fck", &smartreflex1_fck),
CLK(NULL, "sha0_fck", &sha0_fck),
CLK(NULL, "aes0_fck", &aes0_fck),
+ CLK(NULL, "rng_fck", &rng_fck),
CLK(NULL, "timer1_fck", &timer1_fck),
CLK(NULL, "timer2_fck", &timer2_fck),
CLK(NULL, "timer3_fck", &timer3_fck),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: AM33xx: Add RNG module data
This patch series adds HWMOD, CLOCK and DT data for RNG module. Lokesh Vutla (3): ARM: AM33XX: hwmod: Add rng module data ARM: AM33xx: Add rng clock data ARM: dts: AM33xx: Add RNG node .../devicetree/bindings/hwrng/omap_rng.txt | 22 arch/arm/boot/dts/am335x-bone.dts |4 +++ arch/arm/boot/dts/am335x-evm.dts |4 +++ arch/arm/boot/dts/am335x-evmsk.dts |4 +++ arch/arm/boot/dts/am33xx.dtsi |8 + arch/arm/mach-omap2/cclock33xx_data.c |5 +++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 35 7 files changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: AM33xx: hwmod: Add RNG module data
Add RNG hwmod data for AM33xx SoC.
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 35
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 28bbd56..6ff70aa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2455,6 +2455,40 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* rng */
+static struct omap_hwmod_class_sysconfig am33xx_rng_sysc = {
+ .rev_offs = 0x1fe0,
+ .sysc_offs = 0x1fe4,
+ .sysc_flags = SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE,
+ .idlemodes = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART,
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am33xx_rng_hwmod_class = {
+ .name = "rng",
+ .sysc = &am33xx_rng_sysc,
+};
+
+static struct omap_hwmod am33xx_rng_hwmod = {
+ .name = "rng",
+ .class = &am33xx_rng_hwmod_class,
+ .clkdm_name = "l4ls_clkdm",
+ .main_clk = "rng_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_RNG_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+struct omap_hwmod_ocp_if am33xx_l4_per__rng = {
+ .master = &am33xx_l4_ls_hwmod,
+ .slave = &am33xx_rng_hwmod,
+ .clk= "rng_fck",
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l3_main__emif,
&am33xx_mpu__l3_main,
@@ -2533,6 +2567,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
&am33xx_cpgmac0__mdio,
&am33xx_l3_main__sha0,
&am33xx_l3_main__aes0,
+ &am33xx_l4_per__rng,
NULL,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: AM33xx: Add RNG node
Add the generic AM33xx RNG module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms. Also add Documentation file describing the data
for the RNG module.
Signed-off-by: Lokesh Vutla
---
.../devicetree/bindings/hwrng/omap_rng.txt | 22
arch/arm/boot/dts/am335x-bone.dts |4
arch/arm/boot/dts/am335x-evm.dts |4
arch/arm/boot/dts/am335x-evmsk.dts |4
arch/arm/boot/dts/am33xx.dtsi |8 +++
5 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000..6a62acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ RNG versions:
+ - "ti,omap2-rng" for OMAP2.
+ - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+ Only used for "ti,omap4-rng".
+
+Example:
+/* AM335x */
+rng: rng@4831 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x4831 0x2000>;
+ interrupts = <111>;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..46a3887 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -234,3 +234,7 @@
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
};
+
+&rng {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..ebfbebe1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -488,3 +488,7 @@
ti,adc-channels = <4 5 6 7>;
};
};
+
+&rng {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..6610a05 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -402,3 +402,7 @@
phy_id = <&davinci_mdio>, <1>;
phy-mode = "rgmii-txid";
};
+
+&rng {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..b1e6205 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,13 @@
#size-cells = <1>;
status = "disabled";
};
+
+ rng: rng@4831 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x4831 0x2000>;
+ interrupts = <111>;
+ status = "disabled";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/9] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi Grygorii,
On Monday 05 August 2013 05:14 PM, Grygorii Strashko wrote:
> On 08/04/2013 07:27 PM, Rajendra Nayak wrote:
>> From: R Sricharan
>>
>> The DRA7xx is a high-performance, infotainment application device,
>> based on enhanced OMAP architecture integrated on a 28-nm technology.
>>
>> Since DRA7 is a platform supported only using DT, the cpu detection
>> is based on the compatibles passed from DT blobs as suggested here
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187712.html
>>
>> Suggested-by: Felipe Balbi
>> Signed-off-by: R Sricharan
>> Signed-off-by: Rajendra Nayak
>> Acked-by: Santosh Shilimkar
>> ---
>> arch/arm/mach-omap1/include/mach/soc.h |1 +
>> arch/arm/mach-omap2/id.c |4 ++--
>> arch/arm/mach-omap2/soc.h | 17 +
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap1/include/mach/soc.h
>> b/arch/arm/mach-omap1/include/mach/soc.h
>> index 6cf9c1c..612bd1c 100644
>> --- a/arch/arm/mach-omap1/include/mach/soc.h
>> +++ b/arch/arm/mach-omap1/include/mach/soc.h
>> @@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
>> #define cpu_is_omap34xx()0
>> #define cpu_is_omap44xx()0
>> #define soc_is_omap54xx()0
>> +#define soc_is_dra7xx()0
>> #define soc_is_am33xx()0
>> #define cpu_class_is_omap1()1
>> #define cpu_class_is_omap2()0
>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
>> index 2dc62a2..0289adc 100644
>> --- a/arch/arm/mach-omap2/id.c
>> +++ b/arch/arm/mach-omap2/id.c
>> @@ -61,7 +61,7 @@ int omap_type(void)
>> val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
>> } else if (cpu_is_omap44xx()) {
>> val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
>> -} else if (soc_is_omap54xx()) {
>> +} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
>> val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
>> val &= OMAP5_DEVICETYPE_MASK;
>> val >>= 6;
>> @@ -116,7 +116,7 @@ static u16 tap_prod_id;
>>
>> void omap_get_die_id(struct omap_die_id *odi)
>> {
>> -if (cpu_is_omap44xx() || soc_is_omap54xx()) {
>> +if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
>> odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
>> odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
>> odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
>> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
>> index 8c616e4..4588df1 100644
>> --- a/arch/arm/mach-omap2/soc.h
>> +++ b/arch/arm/mach-omap2/soc.h
>> @@ -8,6 +8,7 @@
>>* Written by Tony Lindgren
>>*
>>* Added OMAP4/5 specific defines - Santosh
>> Shilimkar
>> + * Added DRA7xxx specific defines - Sricharan R
>>*
>>* 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
>> @@ -35,6 +36,7 @@
>> #ifndef __ASSEMBLY__
>>
>> #include
>> +#include
>>
>> /*
>>* Test if multicore OMAP support is needed
>> @@ -105,6 +107,15 @@
>> # endif
>> #endif
>>
>> +#ifdef CONFIG_SOC_DRA7XX
>> +# ifdef OMAP_NAME
>> +# undef MULTI_OMAP2
>> +# define MULTI_OMAP2
>> +# else
>> +# define OMAP_NAME DRA7XX
>> +# endif
>> +#endif
>> +
>> /*
>>* Omap device type i.e. EMU/HS/TST/GP/BAD
>>*/
>> @@ -233,6 +244,7 @@ IS_AM_SUBCLASS(437x, 0x437)
>> #define cpu_is_omap447x()0
>> #define soc_is_omap54xx()0
>> #define soc_is_omap543x()0
>> +#define soc_is_dra7xx()0
>>
>> #if defined(MULTI_OMAP2)
>> # if defined(CONFIG_ARCH_OMAP2)
>> @@ -379,6 +391,11 @@ IS_OMAP_TYPE(3430, 0x3430)
>> # define soc_is_omap543x()is_omap543x()
>> #endif
>>
>> +#if defined(CONFIG_SOC_DRA7XX)
>> +#undef soc_is_dra7xx
>> +#define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
>
> Wouldn't that be too expensive to call of_machine_is_compatible every
> time for DRA7 detection?
Ideally these soc checks should happen only once at init (see PATCH 8/9 in the
series for instance) so there should not be a 'every time' penalty.
regards,
Rajendra
>
> May be static variable can be used to store DRA7 presence status,
> smth. like this:
>
> static inline int is_dra7xx(void)
> {
> static int is_dra7 = -1;
>
> if (is_dra7 < 0)
> is_dra7 = of_machine_is_compatible("ti,dra7");
>
> return !!is_dra7;
> }
>
> (it's just an idea, not verified)
>
>> +#endif
>> +
>> /* Various silicon revisions for omap2 */
>> #define OMAP242X_CLASS0x24200024
>> #define OMAP2420_REV_ES1_0OMAP242X_CLASS
>>
>
>
> Regards,
> -grygorii
--
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
