Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Benoit, On Fri, Aug 16, 2013 at 4:20 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 16/08/2013 14:04, Ruslan Bilovol wrote: Hi Benoit, On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 14/08/2013 10:35, Ruslan Bilovol wrote: Hello, There is no functional changes between v1 and v2 - just added the patch for omap4-var-som - Uri Yosef confirmed this board have the same connection of OMAP4-TWL6030 as SDP4430 board The series looks good to me, but it will be good to have a test for Panda and Variscite boards before merging it. Okay, so I just verified this patch series on PandaBoard ES2. Should I resubmit this series with fixed commit message? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol ruslan.bilo...@ti.com Date: Wed Aug 14 11:35:47 2013 +0300 ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file The OMAP4 SoC family uses specially-designed PMIC (power management IC) companion chip for power management needs: TWL6030/TWL6032. Therefore there is a typical connection of PMIC to OMAP4 so we can move it into separate .dtsi file and do not duplicate over board-specific files. Tested on OMAP4 SDP board and compile-tested for Panda board Just for archives: I've successfully tested it on PandaBoard ES2 last week as well. Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com Signed-off-by: Benoit Cousson bcous...@baylibre.com Just let me know if you are OK with the updated version. Yes, this version looks good to me. Thanks for picking it up! However I cannot verify the patch for Variscite board because I do not own any such board so you can drop that patch. But maybe Uri Yosef can verify it. Uri? It seems that Uri cannot test it right now, so I will have to drop that one. Okay, let's wait for Uri's verification. Best regards, Ruslan Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Tony, On Tuesday 13 August 2013 01:31 PM, Tony Lindgren wrote: Hi Paul Benoit, Does this series look OK to you guys to queue or ack? Can you please consider queuing this series for the coming merge window as we are getting closer to the merge window. If Paul or Benoit has any comments on this, we can have patches to fix it up on top of this as required or these patches be reverted in the worst case. Regards Afzal * Afzal Mohammed af...@ti.com [130802 06:42]: Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 691 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 13 files changed, 1198 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.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
Re: [PATCH v3 7/8] ARM: dts: omap4: update omap-control-usb nodes
Hi Benoit,
On 08/16/2013 05:30 PM, Benoit Cousson wrote:
Hi Roger,
Sorry I missed something in the previous revision :-(
no problem :)
On 16/08/2013 15:09, Roger Quadros wrote:
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of ti,type property.
You should add that you update the usb_otg_hs node accordingly as well.
OK.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a77dd0a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
-ctrl-module = omap_control_usb;
+ctrl-module = omap_control_usb2phy;
};
};
@@ -643,12 +643,16 @@
};
};
-omap_control_usb: omap-control-usb@4a002300 {
-compatible = ti,omap-control-usb;
-reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
-reg-names = control_dev_conf, otghs_control;
-ti,type = 1;
+omap_control_usb2phy: omap-control-usb@4a002300 {
+compatible = ti,usb2-control-usb;
+reg = 0x4a002300 0x4;
+reg-names = power;
+};
+
+omap_control_usbotg: omap-control-usb@4a00233c {
+compatible = ti,omap4-control-usb;
+reg = 0x4a00233c 0x4;
+reg-names = otghs_control;
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -661,7 +665,7 @@
multipoint = 1;
num-eps = 16;
ram-bits = 12;
-ti,has-mailbox;
+ctrl-module = omap_control_usbotg;
In omap-usb.txt, ti,has-mailbox is still marked as mandatory whereas the
ctrl-module is optional.
You should update the usb-otg-hs bindings as well.
Right, I removed it from the binding information, but missed the example.
BTW, why is that property not prefixed with ti,? Is ctrl-module really
meaningful for other arch?
The ctrl-module thing is TI specific, but otg_hs is used by other platforms,
maybe that's why
the ti, prefix was used.
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 v2 0/9] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi Felipe, On 08/16/2013 01:52 PM, Benoit Cousson wrote: Hi Roger, On 15/08/2013 12:18, Roger Quadros wrote: Hi, Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex. Instead, manage the RESET gpio line directly in the driver. This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12. *NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree. Patch 1 is available at repo git://github.com/rogerq/linux.git in branch phy-reset-common Patch 2 contains the phy-nop driver changes Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT. Patch 9 adds USB host support to omap3-beagle-xm using the new binding. Patches are based on v3.11-rc5. Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es v2: - Added RESET GPIO polarity feature - Changed to gpio_set_value_cansleep() cheers, -roger --- Roger Quadros (9): usb: phy: nop: Add gpio_reset to platform data usb: phy: nop: Don't use regulator framework for RESET line ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle-xm: Add USB Host support The 5 DTS patches looks good to me, and I can apply them, but you need to be sure that the driver will be merged for 3.12 as well. Could you please let us know if this series can make it to 3.12? Thanks. 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 v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On 08/19/2013 02:05 PM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? This patch will be included in 3.12-rc* after 3.12-rc1. and this patch is applied on extcon-linus branch. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? -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
[PATCH 0/6] simplify platform_get_resource_byname/devm_ioremap_resource
devm_ioremap_resource often uses the result of a call to
platform_get_resource_byname as its last argument. devm_ioremap_resource
does appropriate error handling on this argument, so error handling can be
removed from the call to platform_get_resource_byname.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l,f;
expression list es;
@@
(
res = f(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
|
- res = f(es);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = f(es);
e = devm_ioremap_resource(e1, res);
)
// /smpl
In practice, f is always platform_get_resource_byname (or
platform_get_resource, which was handled by a previous patch series). And
the call to platform_get_resource_byname always immediately precedes the
call to devm_ioremap_resource.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ASoC: omap: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
In the case of omap-dmic.c, the error-handling code of
devm_ioremap_resource is also corrected to include releasing the clock.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c |9 +++--
sound/soc/omap/omap-mcpdm.c |3 ---
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 4db1f8e..12e566b 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -480,15 +480,12 @@ static int asoc_dmic_probe(struct platform_device *pdev)
dmic-dma_data.filter_data = up_link;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
- if (!res) {
- dev_err(dmic-dev, invalid memory resource\n);
- ret = -ENODEV;
+ dmic-io_base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(dmic-io_base)) {
+ ret = PTR_ERR(dmic-io_base);
goto err_put_clk;
}
- dmic-io_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(dmic-io_base))
- return PTR_ERR(dmic-io_base);
ret = snd_soc_register_component(pdev-dev, omap_dmic_component,
omap_dmic_dai, 1);
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index a49dc52..90d2a7c 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -480,9 +480,6 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
mcpdm-dma_data[1].filter_data = up_link;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
- if (res == NULL)
- return -ENOMEM;
-
mcpdm-io_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(mcpdm-io_base))
return PTR_ERR(mcpdm-io_base);
--
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: [PATCHv5 01/31] CLK: clkdev: add support for looking up clocks from DT
Hey, (Sorry was out for a short vacation, thus late reply.) On 08/03/2013 10:04 PM, Tomasz Figa wrote: On Saturday 03 of August 2013 19:48:05 Russell King - ARM Linux wrote: On Sat, Aug 03, 2013 at 08:39:34PM +0200, Tomasz Figa wrote: Hi Russell, On Saturday 03 of August 2013 19:35:43 Russell King - ARM Linux wrote: On Sat, Aug 03, 2013 at 04:02:36PM +0200, Tomasz Figa wrote: + if (cl) + return cl; + + /* If clock was not found, attempt to look-up from DT */ + node = of_find_node_by_name(NULL, con_id); Why are we introducing the lookup by name brokenness to the yet (mostly) sane DT world? We already have a good way of binding things together in DT, which is using phandles. Not even saying that this (or something this patch relies on) breaks the ePAPR recommendation about node naming, which states that node names should not be used to convey platform-specific data, but instead should be as generic as possible to show what kind of hardware is represented by the node. Tell me this: many devices name their clock inputs. You can find these input names in data sheets and the like. These are the names defined by the hardware. What is wrong about using those names in DT? Yes, clock inputs. But this is about lookup by clock name, not clock input name, as far as I can tell from the patch, based on looking for a node with given name over the whole DT. con_id is supposed to be the clock input name when the clock API is used correctly. Right. Still, the code is looking for a node with the same name as the supposed input name, which seems strange to me, because clock input names are supposed to be defined in consumer's node, inside clock-names property. Remember that the second argument to clk_get() is the _clock_ _input_ _name_ on the _device_ passed in the first argument. It is not *ever* some random name of the clock producer unless someone's fscked up their use of this API (in which case they're the ones with the problem.) This is perfectly fine and this is how the generic common clock framework DT bindings work - clock-names property is a list of clock input names and clocks property contain specifiers of respective clocks. There seems to be a some pressure to do clk_get()-of_clk_get() conversions, and also to find ways to lookup clocks. I don't really see any need for this kind of conversion. clk_get() already handles lookup using DT correctly and from drivers perspective nothing changes. It seems to me that no one understands how DT handles clocks. Maybe that's where the problem is - lack of documentation about how DT clocks are handled. Hmm, there is pretty much of description and examples in Documentation/devicetree/bindings/clock/clock-bindings.txt For me it was enough to learn how DT based clock lookup works, but I'm quite used to DT, so I'm not a good test sample. Best regards, Tomasz I think based on these comments this patch needs to go away, I will have to find another way to map the devices in and to avoid supporting the legacy mappings (hwmod depends on this heavily atm, but Rajendra posted some patches to address this.) I'll see what I can do for next rev. I might implement some tweak inside the OMAP codebase for this. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 8/6/2013 11:19 PM, Dave Gerlach wrote: 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. can you share the working repo which has all these patches applied? Thanks Regards Gururaja 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-kernelm=135698501821090w=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-kernelm=137303736714638w=4 [2] http://marc.info/?l=linux-omapm=137303723114610w=4 [3] http://marc.info/?l=linux-omapm=137401384611934w=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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? What is the meaning of old value? previous value related to extcon-twl.txt? The extcon-twl.txt was included in 3.11 kernel and extcon-palmas.txt will be inclued in 3.12 kernel through char-misc repo of GregKH. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On Monday 19 August 2013 02:54 PM, Chanwoo Choi wrote: On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? What is the meaning of old value? previous value related to extcon-twl.txt? We were discussing on whether to have ti,palmas-usb or ti,twl6035-usb in compatible value in addition to ti,palmas-usb-vid. Stephen wanted the old values (ti,palmas-usb or ti,twl6035-usb) if it has been published in a release kernel. The extcon-twl.txt was included in 3.11 kernel Right. Since it's part of 3.11 kernel, I think we should retain the old compatible values. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Ruslan, On 19/08/2013 08:14, Ruslan Bilovol wrote: Hi Benoit, On Fri, Aug 16, 2013 at 4:20 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 16/08/2013 14:04, Ruslan Bilovol wrote: Hi Benoit, On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 14/08/2013 10:35, Ruslan Bilovol wrote: Hello, There is no functional changes between v1 and v2 - just added the patch for omap4-var-som - Uri Yosef confirmed this board have the same connection of OMAP4-TWL6030 as SDP4430 board The series looks good to me, but it will be good to have a test for Panda and Variscite boards before merging it. Okay, so I just verified this patch series on PandaBoard ES2. Should I resubmit this series with fixed commit message? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol ruslan.bilo...@ti.com Date: Wed Aug 14 11:35:47 2013 +0300 ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file The OMAP4 SoC family uses specially-designed PMIC (power management IC) companion chip for power management needs: TWL6030/TWL6032. Therefore there is a typical connection of PMIC to OMAP4 so we can move it into separate .dtsi file and do not duplicate over board-specific files. Tested on OMAP4 SDP board and compile-tested for Panda board Just for archives: I've successfully tested it on PandaBoard ES2 last week as well. Great, I'll update the changelog before pushing it. Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com Signed-off-by: Benoit Cousson bcous...@baylibre.com Just let me know if you are OK with the updated version. Yes, this version looks good to me. Thanks for picking it up! However I cannot verify the patch for Variscite board because I do not own any such board so you can drop that patch. But maybe Uri Yosef can verify it. Uri? It seems that Uri cannot test it right now, so I will have to drop that one. Okay, let's wait for Uri's verification. I'll keep it for 3.13. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
Hi Kishon, On 19/08/2013 11:29, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 02:54 PM, Chanwoo Choi wrote: On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt That file is not yet in 3.11. Only the twl is there. Is this one a rename of the twl one? Regards, Benoit PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? What is the meaning of old value? previous value related to extcon-twl.txt? We were discussing on whether to have ti,palmas-usb or ti,twl6035-usb in compatible value in addition to ti,palmas-usb-vid. Stephen wanted the old values (ti,palmas-usb or ti,twl6035-usb) if it has been published in a release kernel. The extcon-twl.txt was included in 3.11 kernel Right. Since it's part of 3.11 kernel, I think we should retain the old compatible values. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On Monday 19 August 2013 03:51 PM, Benoit Cousson wrote: Hi Kishon, On 19/08/2013 11:29, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 02:54 PM, Chanwoo Choi wrote: On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt That file is not yet in 3.11. Only the twl is there. Is this one a rename of the twl one? yes Benoit. This is the commit http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-nextid=80d644b297dc26c5126858555044edef76f4ffe8 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
[PATCH v4 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Add support for new device types and in the process rid of ti,type
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types Mailbox, USB2, USB3 and DRA7.
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 rog...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 29 ++--
drivers/usb/phy/phy-omap-control.c | 173
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
4 files changed, 137 insertions(+), 95 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..e24078f 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -73,22 +73,23 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be ti,omap-control-usb
+ - compatible: Should be one of
+ ti,omap4-control-usb - if it has otghs_control mailbox register as on OMAP4.
+ ti,usb2-control-usb - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ ti,usb3-control-usb - if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,dra7-control-usb - if it has both power down and power aux registers
+ e.g. USB2 PHY on DRA7 platform.
- reg : Address and length of the register set for the device. It contains
- the address of control_dev_conf and otghs_control or phy_power_usb
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in reg.
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
- phy power.
+ the address of otghs_control for omap4-control-usb or power register
+ for other types. For dra7-control-usb, it must also contain power_aux
+ register.
+ - reg-names: should be otghs_control for omap4-control-usb and power for
+ other types. For dra7-control-usb type it must also contain power_aux.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 7f446c4..4c4c85c 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/of.h
+#include linux/of_device.h
#include linux/err.h
#include linux/io.h
#include linux/clk.h
@@ -46,61 +47,76 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
- u32 val;
+ u32 val, val_aux;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb-type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
return;
+ }
- rate = clk_get_rate(control_usb-sys_clk);
- rate = rate/100;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, %s: invalid control usb device\n, __func__);
+ return;
+ }
- val = readl(control_usb-phy_power);
+ if (control_usb-type == OMAP_CTRL_TYPE_OMAP4)
+ return;
- if (on) {
- val = ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
-
[PATCH v4 8/8] ARM: dts: omap5: update omap-control-usb node
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of ti,type property.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..7cda18b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,12 +626,16 @@
hw-caps-temp-alert;
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a002370 0x4;
- reg-names = control_dev_conf, phy_power_usb;
- ti,type = 2;
+ omap_control_usb2phy: omap-control-usb@4a002300 {
+ compatible = ti,usb2-control-usb;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb3phy: omap-control-usb@0x4a002370 {
+ compatible = ti,usb3-control-usb;
+ reg = 0x4a002370 0x4;
+ reg-names = power;
};
omap_dwc3@4a02 {
@@ -661,7 +665,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
usb3_phy: usb3phy@4a084400 {
@@ -670,7 +674,7 @@
0x4a084800 0x64,
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb3phy;
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
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 rog...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..981313e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
#definePLL_STATUS 0x0004
#definePLL_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 -EINVAL;
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);
- return -ENODEV;
+ control_node = of_parse_phandle(node, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device phandle\n);
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ return -EINVAL;
+ }
+
+ phy-control_dev = control_pdev-dev;
omap_control_usb_phy_power(phy-control_dev, 0);
usb_add_phy_dev(phy-phy);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/8] phy: omap-usb: Support multiple instances and new types
Hi, This patchset does the following: * Get rid of omap_control_usb platform data as we support DT only. * Restructure and add support for new PHY types. We now support the follwing four types TYPE_OMAP - if it has otghs_control mailbox register (e.g. on OMAP4) TYPE_USB2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY TYPE_USB3 - if it has DPLL and individual Rx Tx power control. e.g. USB3 PHY or SATA PHY TYPE_DRA7 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7 * Get rid of ti,type DT property and introduce compatible strings for each type. * Have only one power control API omap_control_usb_phy_power() instead of a different one for each PHY type. * Get rid of omap_get_control_dev() so that we can support multiple instances of the control device. We take advantage of the fact that omap control USB device is only present on OMAP4 onwards and hence only supports DT boot. The users of control USB device can get a reference to it from the device node's phandle. Patches are based on balbi/next. Smoke tested on OMAP4 panda with MUSB in gadget mode (g_zero). You can find the patches in branch usb-control-module in git tree git://github.com/rogerq/linux.git v4: - removed ti,has-mailbox from omap-usb binding document example. v3: - return -EINVAL instead of -ENODEV on probe failure. - pass device type data through of_device_id table. - get rid of ti,mailbox property and has_mailbox from musb platform data. v2: - get rid of ti,type property and introduce compatible strings for each device type. cheers, -roger --- Roger Quadros (8): usb: phy: omap-control: Get rid of platform data usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power() usb: phy: omap-usb2: Don't use omap_get_control_dev() usb: phy: omap-usb3: Don't use omap_get_control_dev() usb: musb: omap2430: Don't use omap_get_control_dev() usb: phy: omap: get rid of omap_get_control_dev() ARM: dts: omap4: update omap-control-usb nodes ARM: dts: omap5: update omap-control-usb node Documentation/devicetree/bindings/usb/omap-usb.txt | 33 ++-- arch/arm/boot/dts/omap4.dtsi | 20 ++- arch/arm/boot/dts/omap5.dtsi | 20 ++- drivers/usb/musb/omap2430.c| 25 ++- drivers/usb/phy/phy-omap-control.c | 210 +++- drivers/usb/phy/phy-omap-usb2.c| 26 ++- drivers/usb/phy/phy-omap-usb3.c| 28 ++- include/linux/usb/musb.h |2 - include/linux/usb/omap_control_usb.h | 33 ++-- 9 files changed, 224 insertions(+), 173 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/8] ARM: dts: omap4: update omap-control-usb nodes
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of ti,type property.
Also get rid of ti,has-mailbox property from usb_otg_hs
node and provide the ctrl-module phandle.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a77dd0a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
};
@@ -643,12 +643,16 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ omap_control_usb2phy: omap-control-usb@4a002300 {
+ compatible = ti,usb2-control-usb;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usbotg: omap-control-usb@4a00233c {
+ compatible = ti,omap4-control-usb;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -661,7 +665,7 @@
multipoint = 1;
num-eps = 16;
ram-bits = 12;
- ti,has-mailbox;
+ ctrl-module = omap_control_usbotg;
};
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/8] usb: phy: omap-control: Get rid of platform data
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/phy/phy-omap-control.c | 18 +++---
include/linux/usb/omap_control_usb.h |4
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..7f446c4 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,13 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev-dev.of_node;
- struct omap_control_usb_platform_data *pdata =
- dev_get_platdata(pdev-dev);
+
+ if (np) {
+ of_property_read_u32(np, ti,type, control_usb-type);
+ } else {
+ /* We only support DT boot */
+ return -EINVAL;
+ }
control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,15 +212,6 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- if (np) {
- of_property_read_u32(np, ti,type, control_usb-type);
- } else if (pdata) {
- control_usb-type = pdata-type;
- } else {
- dev_err(pdev-dev, no pdata present\n);
- return -EINVAL;
- }
-
control_usb-dev= pdev-dev;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..e2416b4 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -31,10 +31,6 @@ struct omap_control_usb {
u32 type;
};
-struct omap_control_usb_platform_data {
- u8 type;
-};
-
enum omap_control_usb_mode {
USB_MODE_UNDEFINED = 0,
USB_MODE_HOST,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/8] usb: phy: omap-usb2: Don't use omap_get_control_dev()
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 rog...@ti.com
---
drivers/usb/phy/phy-omap-usb2.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..e278a3d 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -121,8 +122,14 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
static int omap_usb2_probe(struct platform_device *pdev)
{
- struct omap_usb *phy;
- struct usb_otg *otg;
+ 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 -EINVAL;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -144,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);
- return -ENODEV;
+ control_node = of_parse_phandle(node, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device phandle\n);
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ return -EINVAL;
+ }
+
+ phy-control_dev = control_pdev-dev;
phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 6/8] usb: phy: omap: get rid of omap_get_control_dev()
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 rog...@ti.com
---
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 4c4c85c..1a7e19a 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -26,26 +26,6 @@
#include linux/clk.h
#include linux/usb/omap_control_usb.h
-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
@@ -188,11 +168,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_TYPE_OMAP4)
+ 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_TYPE_OMAP4)
+ return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -215,6 +203,7 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
const struct of_device_id *of_id;
+ struct omap_control_usb *control_usb;
of_id = of_match_device(omap_control_usb_id_table, pdev-dev);
if (!of_id)
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 450b5c1..8008e8d 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -65,15 +65,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)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()
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.
Also get rid of ti,has-mailbox property as it is redundant and
we can determine that from whether ctrl-module property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ---
drivers/usb/musb/omap2430.c| 25 +++
include/linux/usb/musb.h |2 -
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index e24078f..4dc9100 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
- ti,hwmods : must be usb_otg_hs
- - ti,has-mailbox : to specify that omap uses an external mailbox
- (in control module) to communicate with the musb core during device connect
- and disconnect.
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num-eps : Specifies the number of endpoints. This is also a
@@ -28,7 +25,6 @@ SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
ti,hwmods = usb_otg_hs;
- ti,has-mailbox;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..516795b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
#include linux/delay.h
#include linux/usb/musb-omap.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
#include musb_core.h
#include omap2430.h
@@ -509,8 +510,12 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev = pdev-dev;
glue-musb = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+ glue-control_otghs = ERR_PTR(-ENODEV);
if (np) {
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
dev_err(pdev-dev,
@@ -539,22 +544,20 @@ static int omap2430_probe(struct platform_device *pdev)
of_property_read_u32(np, ram-bits, (u32 *)config-ram_bits);
of_property_read_u32(np, power, (u32 *)pdata-power);
config-multipoint = of_property_read_bool(np, multipoint);
- pdata-has_mailbox = of_property_read_bool(np,
- ti,has-mailbox);
pdata-board_data = data;
pdata-config = config;
- }
- if (pdata-has_mailbox) {
- glue-control_otghs = omap_get_control_dev();
- if (IS_ERR(glue-control_otghs)) {
- dev_vdbg(pdev-dev, Failed to get control device\n);
- ret = PTR_ERR(glue-control_otghs);
- goto err2;
+ control_node = of_parse_phandle(np, ctrl-module, 0);
+ if (control_node) {
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control
device\n);
+ ret = -EINVAL;
+ goto err2;
+ }
+ glue-control_otghs = control_pdev-dev;
}
- } else {
- glue-control_otghs = ERR_PTR(-ENODEV);
}
pdata-platform_ops = omap2430_ops;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..eb50525 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,8 +99,6 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
- u8 has_mailbox:1;
-
/* for clk_get() */
const char *clock;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AM335x, early printk
Hi, I activated: [*] Kernel low-level debugging functions Kernel low-level debugging port (Kernel low-level debugging messages via OMAP2PLUS UART) Low-level debug console UART (AM33XX UART1) [*] Early printk and booted my am335x-evm. I haven't seen any early output in the decompressor or during the kernel boot. I believe that all I saw is just regular ttyO0 output. I saw also: |44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 |console [ttyO0] enabled and I would also except the bootconsole (if any) to be deactivated here. What am I missing? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: always send stop after nack
Hi, Which means your original patch starts to make a lot more sense. I wonder is this is really what we should be doing though - breaking out of the loop, I mean. Yup, that is fine. I applied the old patch with Acks from Hein and Felipe to -next. Thanks! It looks like TI's i2c-davinci will have the same problem as i2c-omap, and will need the same change. Somebody up for this? signature.asc Description: Digital signature
Re: AM335x, early printk
Hi! You need to add 'earlyprintk' in the kernel command line, given (I suppose) by U-Boot. I hope this helps! Jean On Mon, Aug 19, 2013 at 1:21 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Hi, I activated: [*] Kernel low-level debugging functions Kernel low-level debugging port (Kernel low-level debugging messages via OMAP2PLUS UART) Low-level debug console UART (AM33XX UART1) [*] Early printk and booted my am335x-evm. I haven't seen any early output in the decompressor or during the kernel boot. I believe that all I saw is just regular ttyO0 output. I saw also: |44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 |console [ttyO0] enabled and I would also except the bootconsole (if any) to be deactivated here. What am I missing? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote: On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +- clock-names : ... + sleep_a_clk : Sleep clock, used when USB3 core goes into low ... + ref_clk : Reference clock - used in host mode. ... + core_clk : Master/Core clock, have to be = 125 MHz for SS ... + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low ... + utmi_clk : Generated by HS-PHY. Used to clock the low power I think it makes sense to remove _clk from all those names, unless the HW documentation really talks about a clock named e.g. iface_clk yet some other clock names in the documentation don't have the _clk suffix, e.g. the xo I didn't quote. From limited information that I have, I could not say how clock inputs are named from the controller perspective, but I agree that _clk suffix looks redundant. Side question: if for example label in controller says UTMI, should I also use capital letters for the resource or this could be utmi? +Sub nodes: +== That section title is the same style as all the other section title, so it's no obvious that this is a sub-node for the controller wrapper. Instead, I would suggest something more like: Required child nodes: +- Sub node for DWC3 USB3 controller. Then you can drop that since it's obvious. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. That doesn't really say much. How about. -- A child node must exist to represent the core DWC3 IP block. The name of the node is not important. The content of the node is defined in dwc3.txt. -- Thanks, I will use your suggestion. Regards, Ivan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x, early printk
On 08/19/2013 02:27 PM, Jean Pihet wrote: Hi! Hi Jean, You need to add 'earlyprintk' in the kernel command line, given (I suppose) by U-Boot. Ah, good hint. I hope this helps! Yes. I do not see the decompress messages but I have an early console later on. Unfortunately it stops now right at the serial core: |pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 |Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Jean Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 5/9] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
Hi, On 8/6/2013 11:19 PM, Dave Gerlach wrote: From: Vaibhav Bedia vaibhav.be...@ti.com 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. ...snip... ...snip... + ldr r1, [r0, #EMIF_DDR_PHY_CTRL_1] + str r1, emif_rd_lat_val + + /* Put SDRAM in self-refresh */ + ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL] + orr r1, r1, #0xa0 + str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW] + str r1, [r0, #4] This seems to be a bug which I had pointed out to VB earlier. r0 --- base of emif module r0 + 4 --- EMIF4_0_SDRAM_STATUS === which is read only register Above 2 lines should be as below + str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL] + str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW] It works even with the bug because the Shadow register is updated and that some how seems to take precedence. Thanks regards Gururaja + + ldr r1, dram_sync_word @ a dummy access to DDR as per spec + ldr r2, [r1, #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: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
On 08/13/2013 01:50 PM, Mark Rutland wrote:
Hi,
On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote:
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/dpll.txt | 70 +++
arch/arm/mach-omap2/clock.h| 144 +-
arch/arm/mach-omap2/clock3xxx.h|2 -
drivers/clk/Makefile |1 +
drivers/clk/ti/Makefile|3 +
drivers/clk/ti/dpll.c | 488
include/linux/clk/ti.h | 164 +++
7 files changed, 727 insertions(+), 145 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt
create mode 100644 drivers/clk/ti/Makefile
create mode 100644 drivers/clk/ti/dpll.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
new file mode 100644
index 000..dcd6e63
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -0,0 +1,70 @@
+Binding for Texas Instruments DPLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped DPLL with usually two selectable input clocks
+(reference clock and bypass clock), with digital phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) This binding has several
+sub-types, which effectively result in slightly different setup
+for the actual DPLL clock.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of:
+ ti,omap4-dpll-x2-clock,
+ ti,omap3-dpll-clock,
+ ti,omap3-dpll-core-clock,
+ ti,omap3-dpll-per-clock,
+ ti,omap3-dpll-per-j-type-clock,
+ ti,omap4-dpll-clock,
+ ti,omap4-dpll-core-clock,
+ ti,omap4-dpll-m4xen-clock,
+ ti,omap4-dpll-j-type-clock,
+ ti,omap4-dpll-no-gate-clock,
+ ti,omap4-dpll-no-gate-j-type-clock,
+
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
It might be a good idea to use clock-names to clarify which clocks are
present (I notice your examples contain only one clock input).
All DPLLs have both bypass and reference clocks, but these can be the
same. Is it better to just list both always (and hence drop
clock-names), or provide clock-names always?
+- reg : array of register base addresses for controlling the DPLL (some
+ of these can also be left as NULL):
+ reg[0] = control register
+ reg[1] = idle status register
+ reg[2] = autoidle register
+ reg[3] = multiplier / divider set register
Are all of these always present? Using reg-names seems sensible here.
Not always, I'll change the code. I am quite new to DT and didn't
actually know of the existence of reg-names prop.
+- ti,clk-ref : link phandle for the reference clock
+- ti,clk-bypass : link phandle for the bypass clock
You already have these in clocks, why do you need them again here?
Yea good point. Will fix based on the above.
+
+Optional properties:
+- ti,modes : available modes for the DPLL
Huh? What type is that property? What does it mean?
Will add some documentation to this.
+- ti,recal-en-bit : recalibration enable bit
+- ti,recal-st-bit : recalibration status bit
+- ti,auto-recal-bit : auto recalibration enable bit
These seem rather low-level, but I see other clock bindings are doing
similar things. When are these needed, and why? What type are they?
Bit shift values for the auto recalibration feature. HOWEVER, it seems
these are actually legacy, kernel does not have support for these
anymore if it ever had I think I can just drop these for now as they
are unused by the support code even.
+- ti,clkdm-name : clockdomain name for the DPLL
Could you elaborate on what this is for? What constitutes a valid name?
I'm not sure a string is the best way to define the linkage of several
elements to a domain...
Well, I am not sure if we can do this any better at this point, we don't
have DT nodes for clockdomain at the moment (I am not sure if we will
have those either as there are only a handful of those per SoC) but I'll
add some more documentation for this.
+
+Examples:
+ dpll_core_ck: dpll_core_ck@44e00490 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-core-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00490 0x4, 0x44e0045c 0x4, 0x0 0x4,
+ 0x44e00468 0x4;
+
Re: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On 08/13/2013 02:04 PM, Mark Rutland wrote:
On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote:
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/gate.txt | 41
arch/arm/mach-omap2/clock.h|9 --
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/gate.c | 106
include/linux/clk/ti.h |8 ++
5 files changed, 156 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt
create mode 100644 drivers/clk/ti/gate.c
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt
b/Documentation/devicetree/bindings/clock/ti/gate.txt
new file mode 100644
index 000..620a73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -0,0 +1,41 @@
+Binding for Texas Instruments gate clock.
+
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features. If no register
+is provided for this clock, the code assumes that a clockdomain
+will be controlled instead and the corresponding hw-ops for
+that is used.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+
+Required properties:
+- compatible : shall be ti,gate-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+
+Optional properties:
+- reg : base address for register controlling adjustable gate
Optional? That's odd. If I have a clock with registers, but don't
specify the register, will it still work? i.e. are registerless clocks
really compatible with clocks with registers?.
I think I implemented this in somewhat confusing manner. This could be
split to:
ti,gate-clock:
requires reg and ti,enable-bit info
ti,clkdm-clock:
requires ti,clkdm-name
clkdm clock is kind of a master clock for clockdomain, the clock is
provided always if the clockdomain is active.
+- ti,enable-bit : bit shift for programming the clock gate
Why is this needed? Does the hardware vary wildly, or are several clocks
sharing the same register(s)?
Yea, same register is shared.
+- ti,dss-clk : use DSS hardware OPS for the clock
+- ti,am35xx-clk : use AM35xx hardware OPS for the clock
Those last two sounds like the kind of thing that should be derived from
the compatible string (e.g. ti,am35xx-gate-clock).
Hmm yea, I think I can change this and add some sub-types.
+- ti,clkdm-name : clockdomain to control this gate
As previously mentioned, I'm not a fan of this property. It would make
more sense to describe the domain and have an explicit link to it
(either nodes being children of the domain or having a phandle).
Same comments as with patch #2.
[...]
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init = { 0 };
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ int i;
+ u32 val;
+
+ clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.flags = 0;
+
+ if (of_property_read_u32_index(node, reg, 0, val)) {
+ /* No register, clkdm control only */
+ init.ops = omap_gate_clkdm_clk_ops;
If they're truly compatible, you can just see if you can of_iomap, and
if not, continue. Your reg values might be wider than 32 bits, and usig
of_property_read_u32 to read this feels wrong.
I'll split this to two separate supported types.
+ } else {
+ init.ops = omap_gate_clk_ops;
+ clk_hw-enable_reg = of_iomap(node, 0);
+ of_property_read_u32(node, ti,enable-bit, val);
+ clk_hw-enable_bit = val;
What if of_property_read_u32 failed to read the ti,enable-bit
property? One might not be present, it's marked as optional in the
binding description.
I'll make sure this is present in case it is needed.
+
+ clk_hw-ops = clkhwops_wait;
+
+ if (of_property_read_bool(node, ti,dss-clk))
+ clk_hw-ops = clkhwops_omap3430es2_dss_usbhost_wait;
+
+ if (of_property_read_bool(node, ti,am35xx-clk))
+ clk_hw-ops = clkhwops_am35xx_ipss_module_wait;
I really don't like this. I think this
Re: [PATCHv5 06/31] ARM: dts: omap4 clock data
On 08/03/2013 05:16 PM, Tomasz Figa wrote:
On Friday 02 of August 2013 19:25:25 Tero Kristo wrote:
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
different clock tree which is taken into account in the data.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap443x-clocks.dtsi | 17 +
arch/arm/boot/dts/omap443x.dtsi|8 +
arch/arm/boot/dts/omap4460.dtsi|8 +
arch/arm/boot/dts/omap446x-clocks.dtsi | 27 +
arch/arm/boot/dts/omap44xx-clocks.dtsi | 1648
5 files changed, 1708 insertions(+)
create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi
b/arch/arm/boot/dts/omap443x-clocks.dtsi new file mode 100644
index 000..2bd82b2
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
@@ -0,0 +1,17 @@
+/*
+ * Device Tree Source for OMAP443x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as +
* published by the Free Software Foundation.
+ */
+
+bandgap_fclk: bandgap_fclk@4a307888 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = sys_32k_ck;
+ bit-shift = 8;
+ reg = 0x4a307888 0x4;
+};
diff --git a/arch/arm/boot/dts/omap443x.dtsi
b/arch/arm/boot/dts/omap443x.dtsi index bcf455e..dfd648c 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -30,4 +30,12 @@
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap44xx-clocks.dtsi
+ /include/ omap443x-clocks.dtsi
+ };
};
diff --git a/arch/arm/boot/dts/omap4460.dtsi
b/arch/arm/boot/dts/omap4460.dtsi index c2f0f39..d9d00b2 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -38,4 +38,12 @@
interrupts = 0 126 IRQ_TYPE_LEVEL_HIGH; /* talert */
gpios = gpio3 22 0; /* tshut */
};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap44xx-clocks.dtsi
+ /include/ omap446x-clocks.dtsi
+ };
};
diff --git a/arch/arm/boot/dts/omap446x-clocks.dtsi
b/arch/arm/boot/dts/omap446x-clocks.dtsi new file mode 100644
index 000..86d0805
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x-clocks.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as +
* published by the Free Software Foundation.
+ */
+
+div_ts_ck: div_ts_ck@4a307888 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = l4_wkup_clk_mux_ck;
+ bit-shift = 24;
+ reg = 0x4a307888 0x4;
+ table = 8 0 , 16 1 , 32 2 ;
+ bit-mask = 0x3;
+};
+
+bandgap_ts_fclk: bandgap_ts_fclk@4a307888 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = div_ts_ck;
+ bit-shift = 8;
+ reg = 0x4a307888 0x4;
+};
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
b/arch/arm/boot/dts/omap44xx-clocks.dtsi new file mode 100644
index 000..23f623c
--- /dev/null
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -0,0 +1,1648 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as +
* published by the Free Software Foundation.
+ */
+
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 5900;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = pad_clks_src_ck;
+ bit-shift = 8;
+ reg = 0x4a004108 0x4;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency =
Re: [PATCHv5 07/31] CLK: TI: add omap4 clock init file
On 08/05/2013 10:27 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [130802 09:33]:
clk-44xx.c now contains the clock init functionality for omap4, including
DT clock registration and adding of static clkdev entries.
Few comments below from boot new hardware with old kernels point of
view that seems to be pretty close for clocks.
--- /dev/null
+++ b/drivers/clk/ti/clk-44xx.c
...
+int __init omap4xxx_clk_init(void)
+{
+ int rc;
+ struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
+
+ /* FIXME register clocks from DT first */
+ of_clk_init(NULL);
+
+ omap_dt_clocks_register(omap44xx_clks);
+
+ omap2_clk_disable_autoidle_all();
+
+ /*
+* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+* state when turning the ABE clock domain. Workaround this by
+* locking the ABE DPLL on boot.
+* Lock the ABE DPLL in any case to avoid issues with audio.
+*/
+ abe_dpll_ref = clk_get_sys(NULL, abe_dpll_refclk_mux_ck);
+ sys_32k_ck = clk_get_sys(NULL, sys_32k_ck);
+ rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+ abe_dpll = clk_get_sys(NULL, dpll_abe_ck);
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+
+ /*
+* Lock USB DPLL on OMAP4 devices so that the L3INIT power
+* domain can transition to retention state when not in use.
+*/
+ usb_dpll = clk_get_sys(NULL, dpll_usb_ck);
+ rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure USB DPLL!\n, __func__);
+
+ return 0;
+}
Maybe try to have a generic init function, then have SoC specific
quirk function pointers set up based on the DT compatible property?
Grep for varioius _of_match[] examples in the drivers.
That way you might be able to make clocks work for some new similar
hardware with just .dts change and patching in the quirks later on
as needed ;)
I'll see what can be done for this once I figure out what to do with the
clkdev alias stuff. :)
-Tero
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 16/31] CLK: TI: DRA7: Add APLL support
On 08/13/2013 02:14 PM, Mark Rutland wrote:
On Fri, Aug 02, 2013 at 05:25:35PM +0100, Tero Kristo wrote:
From: Keerthy j-keer...@ti.com
The patch adds support for DRA7 PCIe APLL. The APLL
sources the optional functional clocks for PCIe module.
APLL stands for Analog PLL. This is different when comapred
with DPLL meaning Digital PLL, the phase detection is done
using an analog circuit.
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/apll.txt | 32 +++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/apll.c | 209
include/linux/clk/ti.h |2 +
5 files changed, 244 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/apll.txt
create mode 100644 drivers/clk/ti/apll.c
diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt
b/Documentation/devicetree/bindings/clock/ti/apll.txt
new file mode 100644
index 000..f7a82e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
@@ -0,0 +1,32 @@
+Binding for Texas Instruments APLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped APLL with usually two selectable input clocks
+(reference clock and bypass clock), with analog phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) APLL mostly behaves like
+a subtype of a DPLL [2], although a simplified one at that.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/dpll.txt
+
+Required properties:
+- compatible : shall be ti,dra7-apll-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : array of register base addresses for controlling the APLL:
+ reg[0] = control register
+ reg[1] = idle status register
Using reg-names is likely a good idea here.
I'll change these for next rev to be similar to what was discussed in
the DPLL part.
+- ti,clk-ref : link phandle for the reference clock
+- ti,clk-bypass : link phandle for the bypass clock
You don't need this. Use the clocks and clock-names properties.
Ditto.
[...]
+static int dra7_apll_enable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+ int r = 0, i = 0;
+ struct dpll_data *ad;
+ const char *clk_name;
+ u8 state = 1;
+ u32 v;
+
+ ad = clk-dpll_data;
+ if (!ad)
+ return -EINVAL;
+
+ clk_name = __clk_get_name(clk-hw.clk);
+
+ state = __ffs(ad-idlest_mask);
+
+ /* Check is already locked */
+ if ((__raw_readl(ad-idlest_reg) ad-idlest_mask) == state)
+ return r;
Why __raw_readl rather than raw_readl?
Hmm not sure, Keerthy, do you have any comment on this as the patch was
originally written by you? :)
+
+ v = __raw_readl(ad-control_reg);
+ v = ~ad-enable_mask;
+ v |= APLL_FORCE_LOCK __ffs(ad-enable_mask);
+ __raw_writel(v, ad-control_reg);
Why not raw_writel? Do you not need the rmb() provided by writel, here
or anywhere else?
Same, Keerthy? Probably just legacy copy paste from omap2 code and can
be updated based on your comment. Some of these might actually be some
old optimizations, but the APLL enable/disable should be called so
seldom it shouldn't matter. If no objections, I'll just change these all
for next rev.
[...]
+void __init of_dra7_apll_setup(struct device_node *node)
+{
+ const struct clk_ops *ops;
+ struct clk *clk;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ struct of_phandle_args clkspec;
+ u8 apll_flags = 0;
+ struct dpll_data *ad;
+ u32 idlest_mask = 0x1;
+ u32 autoidle_mask = 0x3;
+ int i;
+
+ ops = apll_ck_ops;
+ ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+ if (!ad) {
+ pr_err(%s: could not allocate dpll_data\n, __func__);
+ return;
+ }
+
+ of_property_read_string(node, clock-output-names, clk_name);
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap dpll %s must have parent(s)\n,
+ __func__, node-name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ clkspec.np = of_parse_phandle(node, ti,clk-ref, 0);
+ ad-clk_ref = of_clk_get_from_provider(clkspec);
Use clocks,
Re: [PATCHv5 22/31] CLK: TI: add interface clock support for OMAP3
On 08/13/2013 02:30 PM, Mark Rutland wrote: On Fri, Aug 02, 2013 at 05:25:41PM +0100, Tero Kristo wrote: OMAP3 has interface clocks in addition to functional clocks, which require special handling for the autoidle and idle status register offsets mainly. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/interface.txt | 45 + arch/arm/mach-omap2/clock.h|6 -- drivers/clk/ti/Makefile|2 +- drivers/clk/ti/interface.c | 105 include/linux/clk/ti.h |7 ++ 5 files changed, 158 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/interface.txt create mode 100644 drivers/clk/ti/interface.c diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt new file mode 100644 index 000..8b09ae7 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -0,0 +1,45 @@ +Binding for Texas Instruments interface clock. + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features, including +companion clock finding (match corresponding functional gate +clock) and hardware autoidle enable / disable. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt + +Required properties: +- compatible : shall be ti,interface-clock It might make sense to be more specific: ti,omap3-interface-clock. Ok. +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock +- reg : base address for the control register + +Optional properties: +- ti,enable-bit : bit shift for the bit enabling/disabling the clock + (default 0) +- ti,iclk-no-wait : flag for selecting non-waiting hw-ops +- ti,iclk-hsotgusb : flag for selecting hsotgusb hw-ops +- ti,iclk-dss : flag for selecting DSS interface clock hw-ops +- ti,iclk-ssi : flag for selecting SSI interface clock hw-ops +- ti,am35xx-clk : flag for selecting AM35xx interface clock hw-ops I think these should be selected based on the compatible string. They're mutually exclusive, and incompatible. Ok, I'll change this for next rev so that each has its own compatible string. Thanks for your comments Mark. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: always send stop after nack
On Mon, Aug 19, 2013 at 02:11:23PM +0200, Wolfram Sang wrote: Hi, Which means your original patch starts to make a lot more sense. I wonder is this is really what we should be doing though - breaking out of the loop, I mean. Yup, that is fine. I applied the old patch with Acks from Hein and Felipe to -next. Thanks! It looks like TI's i2c-davinci will have the same problem as i2c-omap, and will need the same change. Somebody up for this? I would suggest deleting i2c-davinci and making sure it can use i2c-omap. It's the same IP anyway. Just an older version which was used back in OMAP1 times. -- balbi signature.asc Description: Digital signature
Re: [PATCH] i2c-omap: always send stop after nack
On Mon, Aug 19, 2013 at 08:57:02AM -0500, Felipe Balbi wrote: On Mon, Aug 19, 2013 at 02:11:23PM +0200, Wolfram Sang wrote: Hi, Which means your original patch starts to make a lot more sense. I wonder is this is really what we should be doing though - breaking out of the loop, I mean. Yup, that is fine. I applied the old patch with Acks from Hein and Felipe to -next. Thanks! It looks like TI's i2c-davinci will have the same problem as i2c-omap, and will need the same change. Somebody up for this? I would suggest deleting i2c-davinci and making sure it can use i2c-omap. It's the same IP anyway. Just an older version which was used back in OMAP1 times. Yay, I'd love such a patch... signature.asc Description: Digital signature
Re: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. +- reg : array of register base addresses for controlling the DPLL (some + of these can also be left as NULL): + reg[0] = control register + reg[1] = idle status register + reg[2] = autoidle register + reg[3] = multiplier / divider set register Are all of these always present? Using reg-names seems sensible here. Not always, I'll change the code. I am quite new to DT and didn't actually know of the existence of reg-names prop. Ok. :) +- ti,recal-en-bit : recalibration enable bit +- ti,recal-st-bit : recalibration status bit +- ti,auto-recal-bit : auto recalibration enable bit These seem rather low-level, but I see other clock bindings are doing similar things. When are these needed, and why? What type are they? Bit shift values for the auto recalibration feature. HOWEVER, it seems these are actually legacy, kernel does not have support for these anymore if it ever had I think I can just drop these for now as they are unused by the support code even. Ok. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and we're not sure how
Re: [PATCH v12 10/11] ARM: dts: add AM33XX EDMA support
On 06/20/2013 11:06 PM, Joel A Fernandes wrote: From: Matt Porter m...@ti.com Adds AM33XX EDMA support to the am33xx.dtsi as documented in Documentation/devicetree/bindings/dma/ti-edma.txt Joel: Drop DT entries that are non-hardware-description for now as discussed in [1] [1] https://patchwork.kernel.org/patch/2226761/ Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com I've been browsing my lkml folders and I haven't seen any later version of this patch. It seems that other patches from this series have been applied. I don't see this patch in linux-next as of Friday. Any reason why this has not been applied yet? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
Hello.
On 08/19/2013 02:37 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 rog...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..981313e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
[...]
@@ -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;
Could you align the variable names with the above 2 variables?
Either that, or remove the alignment of those two.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
Hi Sergei,
On 08/19/2013 05:23 PM, Sergei Shtylyov wrote:
Hello.
On 08/19/2013 02:37 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 rog...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c
b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..981313e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
[...]
@@ -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;
Could you align the variable names with the above 2 variables?
Either that, or remove the alignment of those two.
OK, I'll remove the alignment of the 1st two lines.
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: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On Mon, Aug 19, 2013 at 02:42:05PM +0100, Tero Kristo wrote:
On 08/13/2013 02:04 PM, Mark Rutland wrote:
On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote:
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/gate.txt | 41
arch/arm/mach-omap2/clock.h|9 --
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/gate.c | 106
include/linux/clk/ti.h |8 ++
5 files changed, 156 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt
create mode 100644 drivers/clk/ti/gate.c
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt
b/Documentation/devicetree/bindings/clock/ti/gate.txt
new file mode 100644
index 000..620a73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -0,0 +1,41 @@
+Binding for Texas Instruments gate clock.
+
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features. If no register
+is provided for this clock, the code assumes that a clockdomain
+will be controlled instead and the corresponding hw-ops for
+that is used.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+
+Required properties:
+- compatible : shall be ti,gate-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+
+Optional properties:
+- reg : base address for register controlling adjustable gate
Optional? That's odd. If I have a clock with registers, but don't
specify the register, will it still work? i.e. are registerless clocks
really compatible with clocks with registers?.
I think I implemented this in somewhat confusing manner. This could be
split to:
ti,gate-clock:
requires reg and ti,enable-bit info
ti,clkdm-clock:
requires ti,clkdm-name
clkdm clock is kind of a master clock for clockdomain, the clock is
provided always if the clockdomain is active.
Ok.
+- ti,enable-bit : bit shift for programming the clock gate
Why is this needed? Does the hardware vary wildly, or are several clocks
sharing the same register(s)?
Yea, same register is shared.
Ok. Are those gate clocks are part of a larger gate clocks block, with
the register that controls them? or are they really independent? Does
the register control other items too?
If they were part of some bigger unit, it might be possible to have a
binding like the following (though maybe not):
gate_clks: gate_clks {
compatible = ti,gate-clocks-block;
reg = 0x4003a000 0x1000;
#clock-cells = 1;
/*
* has 4 gate clocks at bit shifts 0,1,2,3,
* corresponding to input clocks 0,1,2,3
*/
clocks = clk1 0 23,
clk1 0 4,
clk3 2,
clk3 5;
};
device {
compatible = vendor,some-device;
clocks = gate_clks 1; /* gate clock with bitshift 1*/
};
+- ti,dss-clk : use DSS hardware OPS for the clock
+- ti,am35xx-clk : use AM35xx hardware OPS for the clock
Those last two sounds like the kind of thing that should be derived from
the compatible string (e.g. ti,am35xx-gate-clock).
Hmm yea, I think I can change this and add some sub-types.
+- ti,clkdm-name : clockdomain to control this gate
As previously mentioned, I'm not a fan of this property. It would make
more sense to describe the domain and have an explicit link to it
(either nodes being children of the domain or having a phandle).
Same comments as with patch #2.
Same reply as to patch #2 :)
[...]
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init = { 0 };
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ int i;
+ u32 val;
+
+ clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name,
clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.flags = 0;
+
+ if (of_property_read_u32_index(node, reg, 0, val)) {
+ /* No register, clkdm control only */
+ init.ops =
Re: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On 08/19/2013 05:29 PM, Mark Rutland wrote:
On Mon, Aug 19, 2013 at 02:42:05PM +0100, Tero Kristo wrote:
On 08/13/2013 02:04 PM, Mark Rutland wrote:
On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote:
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/gate.txt | 41
arch/arm/mach-omap2/clock.h|9 --
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/gate.c | 106
include/linux/clk/ti.h |8 ++
5 files changed, 156 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt
create mode 100644 drivers/clk/ti/gate.c
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt
b/Documentation/devicetree/bindings/clock/ti/gate.txt
new file mode 100644
index 000..620a73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -0,0 +1,41 @@
+Binding for Texas Instruments gate clock.
+
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features. If no register
+is provided for this clock, the code assumes that a clockdomain
+will be controlled instead and the corresponding hw-ops for
+that is used.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+
+Required properties:
+- compatible : shall be ti,gate-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+
+Optional properties:
+- reg : base address for register controlling adjustable gate
Optional? That's odd. If I have a clock with registers, but don't
specify the register, will it still work? i.e. are registerless clocks
really compatible with clocks with registers?.
I think I implemented this in somewhat confusing manner. This could be
split to:
ti,gate-clock:
requires reg and ti,enable-bit info
ti,clkdm-clock:
requires ti,clkdm-name
clkdm clock is kind of a master clock for clockdomain, the clock is
provided always if the clockdomain is active.
Ok.
+- ti,enable-bit : bit shift for programming the clock gate
Why is this needed? Does the hardware vary wildly, or are several clocks
sharing the same register(s)?
Yea, same register is shared.
Ok. Are those gate clocks are part of a larger gate clocks block, with
the register that controls them? or are they really independent? Does
the register control other items too?
Not really. Typically they only have the clockdomain in common, and the
individual clocks are mostly controlled independently from each other.
For example on omap3 we have following register:
CM_FCLKEN_PER
Physical Address 0x4800 5000
BIT31:19 RESERVED Write 0s for future compatibility. Read returns 0.
BIT18 EN_UART4 UART4 functional clock control.
BIT17 EN_GPIO6 GPIO6 functional clock control.
BIT16 EN_GPIO5 GPIO5 functional clock control.
BIT15 EN_GPIO4 GPIO4 functional clock control.
BIT14 EN_GPIO3 GPIO3 functional clock control.
BIT13 EN_GPIO2 GPIO2 functional clock control.
BIT12 EN_WDT3 WDT3 functional clock control.
BIT11 EN_UART3 Type UART3 functional clock control.
BIT10 EN_GPT9 GPTIMER 9 functional clock control.
BIT9 EN_GPT8 GPTIMER 8 functional clock control.
BIT8 EN_GPT7 GPTIMER 7 functional clock control.
BIT7 EN_GPT6 GPTIMER 6 functional clock control.
BIT6 EN_GPT5 GPTIMER 5 functional clock control.
BIT5 EN_GPT4 GPTIMER 4 functional clock control.
BIT4 EN_GPT3GPTIMER 3 functional clock control.
BIT3 EN_GPT2 GPTIMER 2 functional clock control.
BIT2 EN_MCBSP4 McBSP 4 functional clock control.
BIT1 EN_MCBSP3 McBSP3 functional clock control.
BIT0 EN_MCBSP2 McBSP 2 functional clock control.
So multiple drivers will be using this register for example.
If they were part of some bigger unit, it might be possible to have a
binding like the following (though maybe not):
gate_clks: gate_clks {
compatible = ti,gate-clocks-block;
reg = 0x4003a000 0x1000;
#clock-cells = 1;
/*
* has 4 gate clocks at bit shifts 0,1,2,3,
* corresponding to input clocks 0,1,2,3
*/
clocks = clk1 0 23,
clk1 0 4,
clk3 2,
clk3 5;
};
device {
compatible = vendor,some-device;
clocks = gate_clks 1; /* gate clock with bitshift 1*/
};
+- ti,dss-clk : use DSS hardware OPS for the clock
+- ti,am35xx-clk : use AM35xx hardware OPS for the clock
Those last two sounds like the kind of thing that should be derived from
the compatible string (e.g. ti,am35xx-gate-clock).
Hmm yea, I think I can change this and add some sub-types.
+- ti,clkdm-name : clockdomain to control this gate
Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
On Fri, Aug 16, 2013 at 07:12:46PM +0100, Benoit Cousson wrote: Hi Mark, On 16/08/2013 19:20, Mark Rutland wrote: Hi Benoit, On Fri, Aug 16, 2013 at 03:15:57PM +0100, Benoit Cousson wrote: Hi Gururaja, On 16/08/2013 13:36, Hebbar, Gururaja wrote: The syntax of compatible property in DT is to mention the Most specific match to most generic match. Since AM335x is the platform with latest IP revision, add it 1st in the device id table. I don't understand why? The order should not matter at all. I've tried to follow the thread you had with Mark on the v2, but AFAIK, you've never answered to his latest question. Moreover, checking the differences between the Davinci and the am3352 RTC IP, I would not claim that both are compatible. Sure you can use the am3352 with the Davinci driver, but you will lose the wakeup functionality without even being notify about that. Could you describe the wakeup functionality, and how it differs between the am3352-rtc and the da830-rtc? AFAIK, da830-rtc does not have that functionality at all. This is something that was added to the am3352-rtc. Ok. So the am3352-rtc can be driven with the full functionality of the da830-rtc (ie. it's compatible with the da830-rtc programming model), or it can be driven as an am3352-rtc, for the OS to gain wakeup functionality in addition to the da830-rtc features. :) As I understand it, the am3352 functionality is a superset of the da830 functionality. You can use the old driver, and get some functionality, or use the new driver and get it all. Mmm, what your are saying now seems to make sense to me as well. So I'm even more confused :-) I'll convince you yet :) That means that am3352-rtc is compatible with da830. As long as the kernel first checks for am3352-rtc, there will be *no* loss of functionality. All this does is enable older kernels to use the hardware in some fashion, and given the older kernel didn't have support for the am3352-rtc features, this is a *gain* in functionality, not a loss. For my point of view, compatible mean that the HW will still be fully functional with both versions of the driver, which is not the case here. What? A driver for any entry in the compatible list should be able to drive the hardware to *some* level of functionality. We list from most-specific to most-general to allow a graceful degradation from fully supported to bare minimum functionality. OK, but where is it written in the DT spec that this is what the compatible is supposed to mean? I'm quoting it again: The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The graceful degradation or the loss of functionality is not something that I really understand in that text. I think it's implicit in the example that follows, where a failure to match against a specific device results in the OS falling back to a more general device. The more general device may not have all the features of a more specific device (conversely, the more general device may have more optional features that a more specific device is known not to implement). Anyway, I'm probably too tired... I'll go back home, and think about that after the week-end. Ok, let me know what you think. :) 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
[PATCH] ARM: OMAP: TI81XX: add always-on powerdomain for TI81XX
This patch adds alwon powerdomain support for TI81XX, which is required
for stable functioning of a big number of TI81XX subsystems.
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 8
arch/arm/mach-omap2/prcm-common.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index e2d4bd8..328c103 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -336,6 +336,13 @@ static struct powerdomain dpll5_pwrdm = {
.voltdm = { .name = core },
};
+static struct powerdomain alwon_81xx_pwrdm = {
+ .name = alwon_pwrdm,
+ .prcm_offs= TI81XX_PRM_ALWON_MOD,
+ .pwrsts = PWRSTS_OFF_ON,
+ .voltdm = { .name = core },
+};
+
static struct powerdomain device_81xx_pwrdm = {
.name = device_pwrdm,
.prcm_offs= TI81XX_PRM_DEVICE_MOD,
@@ -442,6 +449,7 @@ static struct powerdomain *powerdomains_am35x[] __initdata
= {
};
static struct powerdomain *powerdomains_ti81xx[] __initdata = {
+ alwon_81xx_pwrdm,
device_81xx_pwrdm,
active_816x_pwrdm,
default_816x_pwrdm,
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index ff1ac4a..0e841fd 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -58,6 +58,7 @@
#define TI816X_PRM_IVAHD1_MOD 0x0d00
#define TI816X_PRM_IVAHD2_MOD 0x0e00
#define TI816X_PRM_SGX_MOD 0x0f00
+#define TI81XX_PRM_ALWON_MOD 0x1800
/* 24XX register bits shared between CM PRM registers */
--
1.8.1.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
Re: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
On 08/19/2013 05:18 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. Ref and bypass clocks are used currently by all DPLLs (also the APLL) so I guess I just enforce both to be specified. +- reg : array of register base addresses for controlling the DPLL (some + of these can also be left as NULL): + reg[0] = control register + reg[1] = idle status register + reg[2] = autoidle register + reg[3] = multiplier / divider set register Are all of these always present? Using reg-names seems sensible here. Not always, I'll change the code. I am quite new to DT and didn't actually know of the existence of reg-names prop. Ok. :) +- ti,recal-en-bit : recalibration enable bit +- ti,recal-st-bit : recalibration status bit +- ti,auto-recal-bit : auto recalibration enable bit These seem rather low-level, but I see other clock bindings are doing similar things. When are these needed, and why? What type are they? Bit shift values for the auto recalibration feature. HOWEVER, it seems these are actually legacy, kernel does not have support for these anymore if it ever had I think I can just drop these for now as they are unused by the support code even. Ok. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and
Re: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On Mon, Aug 19, 2013 at 03:43:15PM +0100, Tero Kristo wrote: On 08/19/2013 05:29 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:42:05PM +0100, Tero Kristo wrote: On 08/13/2013 02:04 PM, Mark Rutland wrote: On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote: This node adds support for a clock node which allows control to the clockdomain enable / disable. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/gate.txt | 41 arch/arm/mach-omap2/clock.h|9 -- drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gate.c | 106 include/linux/clk/ti.h |8 ++ 5 files changed, 156 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt create mode 100644 drivers/clk/ti/gate.c diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt new file mode 100644 index 000..620a73d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -0,0 +1,41 @@ +Binding for Texas Instruments gate clock. + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features. If no register +is provided for this clock, the code assumes that a clockdomain +will be controlled instead and the corresponding hw-ops for +that is used. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt + +Required properties: +- compatible : shall be ti,gate-clock +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock + +Optional properties: +- reg : base address for register controlling adjustable gate Optional? That's odd. If I have a clock with registers, but don't specify the register, will it still work? i.e. are registerless clocks really compatible with clocks with registers?. I think I implemented this in somewhat confusing manner. This could be split to: ti,gate-clock: requires reg and ti,enable-bit info ti,clkdm-clock: requires ti,clkdm-name clkdm clock is kind of a master clock for clockdomain, the clock is provided always if the clockdomain is active. Ok. +- ti,enable-bit : bit shift for programming the clock gate Why is this needed? Does the hardware vary wildly, or are several clocks sharing the same register(s)? Yea, same register is shared. Ok. Are those gate clocks are part of a larger gate clocks block, with the register that controls them? or are they really independent? Does the register control other items too? Not really. Typically they only have the clockdomain in common, and the individual clocks are mostly controlled independently from each other. For example on omap3 we have following register: You say they typically only have the clockdomain in common. Do you mean that they always have the same clockdomain, but not necessarily other properties, or may they not even have the clockdomain in common? CM_FCLKEN_PER Physical Address 0x4800 5000 BIT31:19 RESERVED Write 0s for future compatibility. Read returns 0. BIT18 EN_UART4 UART4 functional clock control. BIT17 EN_GPIO6 GPIO6 functional clock control. BIT16 EN_GPIO5 GPIO5 functional clock control. BIT15 EN_GPIO4 GPIO4 functional clock control. BIT14 EN_GPIO3 GPIO3 functional clock control. BIT13 EN_GPIO2 GPIO2 functional clock control. BIT12 EN_WDT3 WDT3 functional clock control. BIT11 EN_UART3 Type UART3 functional clock control. BIT10 EN_GPT9 GPTIMER 9 functional clock control. BIT9 EN_GPT8 GPTIMER 8 functional clock control. BIT8 EN_GPT7 GPTIMER 7 functional clock control. BIT7 EN_GPT6 GPTIMER 6 functional clock control. BIT6 EN_GPT5 GPTIMER 5 functional clock control. BIT5 EN_GPT4 GPTIMER 4 functional clock control. BIT4 EN_GPT3GPTIMER 3 functional clock control. BIT3 EN_GPT2 GPTIMER 2 functional clock control. BIT2 EN_MCBSP4 McBSP 4 functional clock control. BIT1 EN_MCBSP3 McBSP3 functional clock control. BIT0 EN_MCBSP2 McBSP 2 functional clock control. So multiple drivers will be using this register for example. The point I was trying to get across is that this looks like a single logical block which controls the (independent) gating of several clocks, along the same lines as multiple swtiches bound together in a DIP switch. It's equally valid to view that as several clock gates which happen to have their control bits in close proximity in the memory map, as you suggest. 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
Re: [PATCHv9 1/2] drivers: spi: Add qspi flash controller
Hi Felipe,
Hi,
On Sun, Aug 04, 2013 at 02:28:09PM +0530, Sourav Poddar wrote:
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 Poddarsourav.pod...@ti.com
+ *
+ * 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.
+ */
+
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/interrupt.h
+#includelinux/module.h
+#includelinux/device.h
+#includelinux/delay.h
+#includelinux/dma-mapping.h
+#includelinux/dmaengine.h
+#includelinux/omap-dma.h
+#includelinux/platform_device.h
+#includelinux/err.h
+#includelinux/clk.h
+#includelinux/io.h
+#includelinux/slab.h
+#includelinux/pm_runtime.h
+#includelinux/of.h
+#includelinux/of_device.h
+#includelinux/pinctrl/consumer.h
+
+#includelinux/spi/spi.h
+
+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;
+
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+ u32 stat;
+};
+
+#define QSPI_PID (0x0)
+#define QSPI_SYSCONFIG (0x10)
+#define QSPI_INTR_STATUS_RAW_SET (0x20)
+#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
+#define QSPI_INTR_ENABLE_SET_REG (0x28)
+#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
+#define QSPI_SPI_CLOCK_CNTRL_REG (0x40)
+#define QSPI_SPI_DC_REG(0x44)
+#define QSPI_SPI_CMD_REG (0x48)
+#define QSPI_SPI_STATUS_REG(0x4c)
+#define QSPI_SPI_DATA_REG (0x50)
+#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SWITCH_REG(0x64)
+#define QSPI_SPI_SETUP1_REG(0x58)
+#define QSPI_SPI_SETUP2_REG(0x5c)
+#define QSPI_SPI_SETUP3_REG(0x60)
+#define QSPI_SPI_DATA_REG_1(0x68)
+#define QSPI_SPI_DATA_REG_2(0x6c)
+#define QSPI_SPI_DATA_REG_3(0x70)
+
+#define QSPI_COMPLETION_TIMEOUTmsecs_to_jiffies(2000)
+
+#define QSPI_FCLK 19200
+
+/* Clock Control */
+#define QSPI_CLK_EN(1 31)
+#define QSPI_CLK_DIV_MAX 0x
+
+/* Command */
+#define QSPI_EN_CS(n) (n 28)
+#define QSPI_WLEN(n) ((n-1) 19)
spaces around '-'
+#define QSPI_3_PIN (1 18)
+#define QSPI_RD_SNGL (1 16)
+#define QSPI_WR_SNGL (2 16)
+#define QSPI_RD_DUAL (3 16)
+#define QSPI_RD_QUAD (7 16)
+#define QSPI_INVAL (4 16)
+#define QSPI_WC_CMD_INT_EN (1 14)
+#define QSPI_FLEN(n) ((n-1) 0)
spaces around '-'
Ok.
+/* STATUS REGISTER */
+#define WC 0x02
+
+/* INTERRUPT REGISTER */
+#define QSPI_WC_INT_EN (1 1)
+#define QSPI_WC_INT_DISABLE(1 1)
+
+/* Device Control */
+#define QSPI_DD(m, n) (m (3 + n * 8))
+#define QSPI_CKPHA(n) (1 (2 + n * 8))
+#define QSPI_CSPOL(n) (1 (1 + n * 8))
+#define QSPI_CKPOL(n) (1 (n*8))
spaces around '*'
Ok.
+#defineQSPI_FRAME 4096
+
+#define QSPI_AUTOSUSPEND_TIMEOUT 2000
+
+static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void ti_qspi_write(struct ti_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi-base + reg);
+}
+
+static int ti_qspi_setup(struct spi_device *spi)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi-master);
+ struct ti_qspi_regs *ctx_reg =qspi-ctx_reg;
+ int clk_div = 0, ret;
+ u32 clk_ctrl_reg, clk_rate, clk_mask;
+
+ if (spi-master-busy) {
+ dev_dbg(qspi-dev, master busy doing other trasnfers\n);
+ return -EBUSY;
+ }
+
+ if (!qspi-spi_max_frequency) {
+ dev_err(qspi-dev, spi max frequency not defined\n);
+ return -EINVAL;
+ }
+
+ clk_rate =
Re: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On 08/19/2013 06:58 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 03:43:15PM +0100, Tero Kristo wrote: On 08/19/2013 05:29 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:42:05PM +0100, Tero Kristo wrote: On 08/13/2013 02:04 PM, Mark Rutland wrote: On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote: This node adds support for a clock node which allows control to the clockdomain enable / disable. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/gate.txt | 41 arch/arm/mach-omap2/clock.h|9 -- drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gate.c | 106 include/linux/clk/ti.h |8 ++ 5 files changed, 156 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt create mode 100644 drivers/clk/ti/gate.c diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt new file mode 100644 index 000..620a73d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -0,0 +1,41 @@ +Binding for Texas Instruments gate clock. + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features. If no register +is provided for this clock, the code assumes that a clockdomain +will be controlled instead and the corresponding hw-ops for +that is used. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt + +Required properties: +- compatible : shall be ti,gate-clock +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock + +Optional properties: +- reg : base address for register controlling adjustable gate Optional? That's odd. If I have a clock with registers, but don't specify the register, will it still work? i.e. are registerless clocks really compatible with clocks with registers?. I think I implemented this in somewhat confusing manner. This could be split to: ti,gate-clock: requires reg and ti,enable-bit info ti,clkdm-clock: requires ti,clkdm-name clkdm clock is kind of a master clock for clockdomain, the clock is provided always if the clockdomain is active. Ok. +- ti,enable-bit : bit shift for programming the clock gate Why is this needed? Does the hardware vary wildly, or are several clocks sharing the same register(s)? Yea, same register is shared. Ok. Are those gate clocks are part of a larger gate clocks block, with the register that controls them? or are they really independent? Does the register control other items too? Not really. Typically they only have the clockdomain in common, and the individual clocks are mostly controlled independently from each other. For example on omap3 we have following register: You say they typically only have the clockdomain in common. Do you mean that they always have the same clockdomain, but not necessarily other properties, or may they not even have the clockdomain in common? Currently it seems if the clocks share a register, they are in the same clockdomain (I guess this is something that might also change in future.) The input clocks can be different (some are using the same), and the outputs are routed to different destinations on the SoC. For the below example, GPTs can have either sys_ck or 32k_ck as parent, UARTs are fed from 48M clock etc. CM_FCLKEN_PER Physical Address 0x4800 5000 BIT31:19 RESERVED Write 0s for future compatibility. Read returns 0. BIT18 EN_UART4 UART4 functional clock control. BIT17 EN_GPIO6 GPIO6 functional clock control. BIT16 EN_GPIO5 GPIO5 functional clock control. BIT15 EN_GPIO4 GPIO4 functional clock control. BIT14 EN_GPIO3 GPIO3 functional clock control. BIT13 EN_GPIO2 GPIO2 functional clock control. BIT12 EN_WDT3 WDT3 functional clock control. BIT11 EN_UART3 Type UART3 functional clock control. BIT10 EN_GPT9 GPTIMER 9 functional clock control. BIT9 EN_GPT8 GPTIMER 8 functional clock control. BIT8 EN_GPT7 GPTIMER 7 functional clock control. BIT7 EN_GPT6 GPTIMER 6 functional clock control. BIT6 EN_GPT5 GPTIMER 5 functional clock control. BIT5 EN_GPT4 GPTIMER 4 functional clock control. BIT4 EN_GPT3GPTIMER 3 functional clock control. BIT3 EN_GPT2 GPTIMER 2 functional clock control. BIT2 EN_MCBSP4 McBSP 4 functional clock control. BIT1 EN_MCBSP3 McBSP3 functional clock control. BIT0 EN_MCBSP2 McBSP 2 functional clock control. So multiple drivers will be using this register for example. The point I was trying to get across is that this looks like a single logical block which controls the (independent) gating of several clocks, along the same lines as multiple swtiches bound together in a DIP switch. It's equally valid
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On 08/18/2013 11:05 PM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? So anything in 3.11-rc1 will make it into 3.11 final, and hence has already been published, and hence should be an ABI. This current patch is only going into 3.12, so really should be amended not to break the ABI. -- 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 1/3] usb: dwc3: msm: Add device tree binding information
On 08/19/2013 06:27 AM, Ivan T. Ivanov wrote: Hi, On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote: On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +- clock-names : ... + sleep_a_clk : Sleep clock, used when USB3 core goes into low ... + ref_clk : Reference clock - used in host mode. ... + core_clk : Master/Core clock, have to be = 125 MHz for SS ... + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low ... + utmi_clk : Generated by HS-PHY. Used to clock the low power I think it makes sense to remove _clk from all those names, unless the HW documentation really talks about a clock named e.g. iface_clk yet some other clock names in the documentation don't have the _clk suffix, e.g. the xo I didn't quote. From limited information that I have, I could not say how clock inputs are named from the controller perspective, but I agree that _clk suffix looks redundant. Side question: if for example label in controller says UTMI, should I also use capital letters for the resource or this could be utmi? All the clock-names entries I've seen so far have been lower-case, but I suppose there's no hard-and-fast rule that they couldn't be upper-/mixed-case if that best matched the HW documentation. -- 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: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
On Mon, Aug 19, 2013 at 04:09:37PM +0100, Tero Kristo wrote: On 08/19/2013 05:18 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. Ref and bypass clocks are used currently by all DPLLs (also the APLL) so I guess I just enforce both to be specified. Ok. It's always possible to add clock-names later if a platform doesn't wire an input. We lose the possibility of future compatibility, but backwards compatibility is easy enough to maintain. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and we're not sure how the domains themselves will be represented in dt. Hmm so, should I add a stub representation for the clockdomains to the DT then for now or how should this be handled? The stubs could then be mapped to the actual clock domains based on their node names. I unfortunately don't have a good answer here, because I'm not that familiar with how we handle clockdomains for power management purposes. As I understand it, each clock domain is essentially a clock gate controlling multiple clock signals, so it's possible to describe that with the common clock bindings, with a domain's clocks
Re: [PATCH v3 1/3] usb: dwc3: msm: Add device tree binding information
On 08/19/13 05:27, Ivan T. Ivanov wrote: Hi, On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote: On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +- clock-names : ... + sleep_a_clk : Sleep clock, used when USB3 core goes into low ... + ref_clk : Reference clock - used in host mode. ... + core_clk : Master/Core clock, have to be = 125 MHz for SS ... + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low ... + utmi_clk : Generated by HS-PHY. Used to clock the low power I think it makes sense to remove _clk from all those names, unless the HW documentation really talks about a clock named e.g. iface_clk yet some other clock names in the documentation don't have the _clk suffix, e.g. the xo I didn't quote. From limited information that I have, I could not say how clock inputs are named from the controller perspective, but I agree that _clk suffix looks redundant. In downstream trees we've tried to standardize the names on core_clk, iface_clk, bus_clk, etc. Historically the hardware designers have used the names from the clock controller instead of coming up with standard names of their own when they put the clock inputs in their data sheets (if they do at all). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
On 08/19/2013 07:24 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 04:09:37PM +0100, Tero Kristo wrote: On 08/19/2013 05:18 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. Ref and bypass clocks are used currently by all DPLLs (also the APLL) so I guess I just enforce both to be specified. Ok. It's always possible to add clock-names later if a platform doesn't wire an input. We lose the possibility of future compatibility, but backwards compatibility is easy enough to maintain. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and we're not sure how the domains themselves will be represented in dt. Hmm so, should I add a stub representation for the clockdomains to the DT then for now or how should this be handled? The stubs could then be mapped to the actual clock domains based on their node names. I unfortunately don't have a good answer here, because I'm not that familiar with how we handle clockdomains for power management purposes. As I understand it, each clock domain is essentially a clock gate controlling multiple clock signals, so it's possible to describe that with the common clock bindings, with a domain's clocks all coming from a domain-gate-clock node (or something like that). That would make the wiring of clocks to
Re: [PATCHv3 5/9] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
On 08/19/2013 07:54 AM, Gururaja Hebbar wrote: Hi, On 8/6/2013 11:19 PM, Dave Gerlach wrote: From: Vaibhav Bedia vaibhav.be...@ti.com 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. ...snip... ...snip... + ldr r1, [r0, #EMIF_DDR_PHY_CTRL_1] + str r1, emif_rd_lat_val + + /* Put SDRAM in self-refresh */ + ldr r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL] + orr r1, r1, #0xa0 + str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW] + str r1, [r0, #4] This seems to be a bug which I had pointed out to VB earlier. r0 --- base of emif module r0 + 4 --- EMIF4_0_SDRAM_STATUS === which is read only register Above 2 lines should be as below + str r1, [r0, #EMIF_POWER_MANAGEMENT_CONTROL] + str r1, [r0, #EMIF_POWER_MANAGEMENT_CTRL_SHDW] It works even with the bug because the Shadow register is updated and that some how seems to take precedence. Thanks regards Gururaja Thanks for pointing this out, I have fixed it for next version. Regards, Dave + + ldr r1, dram_sync_word @ a dummy access to DDR as per spec + ldr r2, [r1, #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: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 08/19/2013 04:23 AM, Gururaja Hebbar wrote: On 8/6/2013 11:19 PM, Dave Gerlach wrote: 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. can you share the working repo which has all these patches applied? Thanks Regards Gururaja The working repo for this version of the patch series can be found here: git://github.com/dgerlach/linux-pm.git am335x-3.11rc4-suspend-resume Regards, Dave 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-kernelm=135698501821090w=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-kernelm=137303736714638w=4 [2] http://marc.info/?l=linux-omapm=137303723114610w=4 [3] http://marc.info/?l=linux-omapm=137401384611934w=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 -- 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 RESEND] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de --- Sigh, hitting the CC threshold on vger again. So resending to the lists only. BTW this patch is based on -rc4 and was tested on an AT91 board. More tests very welcome. Thanks! Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include linux/module.h #include linux/of.h #include linux/of_device.h -#include linux/of_i2c.h #include linux/platform_device.h #include linux/slab.h #include linux/platform_data/dma-atmel.h @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(dev-adapter); - dev_info(dev-dev, AT91 i2c bus driver.\n); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include linux/dma-mapping.h #include linux/of_device.h #include linux/of_platform.h -#include linux/of_i2c.h #include sysdev/fsl_soc.h #include asm/cpm.h @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* -* register OF I2C devices -*/ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index fa55605..62be3b3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,7 +38,6 @@ #include linux/slab.h #include
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 07:59 PM, Wolfram Sang wrote:
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver. So, fix the drivers and documentation, too.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Sigh, hitting the CC threshold on vger again. So resending to the lists only.
BTW this patch is based on -rc4 and was tested on an AT91 board. More tests
very welcome. Thanks!
drivers/i2c/busses/i2c-s3c2410.c|2 -
drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 -
For these:
Acked-by: Sylwester Nawrocki s.nawro...@amsung.com
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6:
Applying: i2c: move of helpers into the core
fatal: sha1 information is lacking or useless
(drivers/i2c/busses/i2c-powermac.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 i2c: move of helpers into the core
One nitpick below..
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..321b7ca 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -23,7 +23,11 @@
SMBus 2.0 support by Mark Studebaker mdsxyz...@yahoo.com and
Jean Delvare kh...@linux-fr.org
Mux support by Rodolfo Giometti giome...@enneenne.com and
- Michael Lawnick michael.lawnick@nsn.com */
+ Michael Lawnick michael.lawnick@nsn.com
+ OF support is copyright (c) 2008 Jochen Friedrich joc...@scram.de
+ (based on a previous patch from Jon Smirl jonsm...@gmail.com) and
+ (c) 2013 Wolfram Sang w...@the-dreams.de
+ */
#include linux/module.h
#include linux/kernel.h
@@ -35,7 +39,9 @@
#include linux/init.h
#include linux/idr.h
#include linux/mutex.h
+#include linux/of.h
#include linux/of_device.h
+#include linux/of_irq.h
#include linux/completion.h
#include linux/hardirq.h
#include linux/irqflags.h
@@ -954,6 +960,102 @@ static void i2c_scan_static_board_info(struct
i2c_adapter *adapter)
up_read(__i2c_board_lock);
}
+/* of support code */
/* OF support code */
or
/*
* Device Tree support code.
*/
?
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+ void *result;
+ struct device_node *node;
+
+ /* Only register child devices if the adapter has a node pointer set */
+ if (!adap-dev.of_node)
+ return;
+
+ dev_dbg(adap-dev, of_i2c: walking child nodes\n);
+
+ for_each_available_child_of_node(adap-dev.of_node, node) {
+ struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
+ const __be32 *addr;
+ int len;
+
+ dev_dbg(adap-dev, of_i2c: register %s\n, node-full_name);
+
+ if (of_modalias_node(node, info.type, sizeof(info.type)) 0) {
+ dev_err(adap-dev, of_i2c: modalias failure on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ addr = of_get_property(node, reg, len);
+ if (!addr || (len sizeof(int))) {
+ dev_err(adap-dev, of_i2c: invalid reg on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ info.addr = be32_to_cpup(addr);
+ if (info.addr (1 10) - 1) {
+ dev_err(adap-dev, of_i2c: invalid addr=%x on %s\n,
+ info.addr, node-full_name);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ info.of_node = of_node_get(node);
+ info.archdata = dev_ad;
+
+ if (of_get_property(node, wakeup-source, NULL))
+ info.flags |= I2C_CLIENT_WAKE;
+
+ request_module(%s%s, I2C_MODULE_PREFIX, info.type);
+
+ result = i2c_new_device(adap, info);
+ if (result == NULL) {
+ dev_err(adap-dev, of_i2c: Failure registering %s\n,
+ node-full_name);
+ of_node_put(node);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev-of_node == data;
+}
+
+/* must call put_device() when done with returned i2c_client device */
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+
Re: [PATCH 1/6] ASoC: omap: simplify platform_get_resource_byname/devm_ioremap_resource
Hi
On 08/19/2013 11:51 AM, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to
devm_ioremap_resource.
In the case of omap-dmic.c, the error-handling code of
devm_ioremap_resource is also corrected to include releasing the clock.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c |9 +++--
sound/soc/omap/omap-mcpdm.c |3 ---
2 files changed, 3 insertions(+), 9 deletions(-)
To the patch and catch of missing clock release in omap-dmic.c in case
of failing devm_ioremap_resource:
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
--
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
Hi,
On Mon, Aug 19, 2013 at 09:46:28PM +0530, Sourav Poddar wrote:
+ } else if (wlen == 32) {
if else if else if else if this looks like a switch to me. I know
someone else commented that switch wasn't the best construct, but to my
eyes, switch looks a lot cleaner.
My previous switch implementation was implemented as a seperate
function, as a result of which there was the need to pass pointers, other
variables, then collect it as a double pointer, making things a bit untidy.
What I can do is to convert these portion into switch here itself,
which will
make the code a lot more cleaner. ?
perhaps, at least to me it looks cleaner.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND] i2c: move of helpers into the core
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6: Argh, did not drop the MPC patch before rebasing :( So either pick the patch i2c: powermac: fix return path on error before, pull the branch [1], or force me to resend ;) Thanks! [1] git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/core-with-of signature.asc Description: Digital signature
Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection
On 08/16/2013 04:13 AM, George Cherian wrote:
Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
+EXTCON FOR DRA7xx
+
+Required Properties:
Please at lest explain what a DRA7xxx is, and the purpose of the HW
module this binding describes.
+ - compatible : Should be ti,dra7xx-usb
If this is a USB VID detector rather than a full USB host controller,
then usb in the binding is a bit over-reaching. Perhaps -usb-vid or
-usb-vid-detector would be more accurate.
+ - gpios : phandle to ID pin and interrupt gpio.
This isn't just a phandle; it's phandle+args, or a GPIO specifier. Some
reference should be made to ../gpio/gpio.txt for the format.
Why does the interrupt line need to be included in a list of GPIOs?
If the DRA7xxx is a VID detector, why does it even need/have any GPIOs
associated with it; surely it has a dedicated VID input pin. Can you
provide more details re: how the HW is structured.
+Optional Properties:
+ - interrupt-parent : interrupt controller phandle
+ - interrupts : interrupt number
+
+
It's typical insert the following between those two blank lines:
Example:
... or delete one of the blank lines.
+dra7x_extcon1 {
+ compatible = ti,dra7xx-usb;
+ gpios = pcf_usb 1 0,
+ gpio6 11 2;
+ interrupt-parent = gpio6;
+ interrupts = 11;
+ };
+
No need for that trailing blank line.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
[...]
+}
[...]
+#endif /* CONFIG_OF */
Isn't this missing the dummy implementation for !OF.
static int i2c_do_add_adapter(struct i2c_driver *driver,
struct i2c_adapter *adap)
{
@@ -1058,6 +1160,8 @@ static int i2c_register_adapter(struct i2c_adapter
*adap)
exit_recovery:
/* create pre-declared device nodes */
+ of_i2c_register_devices(adap);
Alternatively you could remove the of_i2c_register_devices() from the
#ifdef CONFIG_OF block so that it will always be compiled. You could
turn the above into
if (IS_ENABLED(CONFIG_OF))
of_i2c_register_devices(adap);
and let the compiler throw the static function away if it sees that the
condition is always false.
Thierry
pgpbXf7EO5KsX.pgp
Description: PGP signature
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de for i2c-omap.c: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 09:46:04PM +0200, Thierry Reding wrote:
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
[...]
+}
[...]
+#endif /* CONFIG_OF */
Isn't this missing the dummy implementation for !OF.
Argh, will fix...
signature.asc
Description: Digital signature
Re: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
Quoting Tero Kristo (2013-08-19 10:06:39) On 08/19/2013 07:24 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 04:09:37PM +0100, Tero Kristo wrote: On 08/19/2013 05:18 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. Ref and bypass clocks are used currently by all DPLLs (also the APLL) so I guess I just enforce both to be specified. Ok. It's always possible to add clock-names later if a platform doesn't wire an input. We lose the possibility of future compatibility, but backwards compatibility is easy enough to maintain. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and we're not sure how the domains themselves will be represented in dt. Hmm so, should I add a stub representation for the clockdomains to the DT then for now or how should this be handled? The stubs could then be mapped to the actual clock domains based on their node names. I'm not sure that this binding should know about the clock domain at all. Maybe the clock domain binding should list the clocks that are within the domain? I unfortunately don't have a good answer here, because
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 12:59 PM, Wolfram Sang wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de --- Glad to see this. Acked-by: Rob Herring rob.herr...@calxeda.com Sigh, hitting the CC threshold on vger again. So resending to the lists only. BTW this patch is based on -rc4 and was tested on an AT91 board. More tests very welcome. Thanks! Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include linux/module.h #include linux/of.h #include linux/of_device.h -#include linux/of_i2c.h #include linux/platform_device.h #include linux/slab.h #include linux/platform_data/dma-atmel.h @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(dev-adapter); - dev_info(dev-dev, AT91 i2c bus driver.\n); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include linux/dma-mapping.h #include linux/of_device.h #include linux/of_platform.h -#include linux/of_i2c.h #include sysdev/fsl_soc.h #include asm/cpm.h @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* - * register OF I2C devices - */ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Hi Linus, On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely wrote: On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij wrote: To solve this dilemma, perform an interrupt consistency check when adding a GPIO chip: if the chip is both gpio-controller and interrupt-controller, walk all children of the device tree, check if these in turn reference the interrupt-controller, and if they do, loop over the interrupts used by that child and perform gpio_reques() and gpio_direction_input() on these, making them unreachable from the GPIO side. Ugh, that's pretty awful, and it doesn't actually solve the root problem of the GPIO and IRQ subsystems not cooperating. It's also a very DT-centric solution even though we're going to see the exact same issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? We have to solve the problem in a better way than that. Rearranging your patch description, here are some of the points you brought up so I can comment on them... This has the following undesired effects: - The GPIOlib subsystem is not aware that the line is in use and willingly lets some other consumer perform gpio_request() on it, leading to a complex resource conflict if it occurs. If a gpio line is being both requested as a gpio and used as an interrupt line, then either a) it's a bug, or b) the gpio line needs to be used as input only so it is compatible with irq usage. b) should be supportable. Yes this is what I'm saying too I think... The bug in (a) manifested itself in the OMAP patch with no real solution in sight. - The GPIO debugfs file claims this GPIO line is free. Surely we can fix this. I still don't see a problem of having the controller request the gpio when it is claimed as an irq if we can get around the problem of another user performing a /valid/ request on the same GPIO line. The solution may be to have a special form of request or flag that allows it to be shared. I don't see how sharing works here, or how another user, i.e. another one than the user wanting to recieve the IRQ, can validly request such a line? What would the usecase for that valid request be? When the GPIO is wired to a status signal (such as an MMC card detect signal) the driver might want to read the state of the signal independently of the interrupt handler. Basically I believe these two things need to be exclusive in the DT world: A: request_irq(a resource passed from interrupts); - core implicitly performs gpio_request() gpio_direction_input() B: gpio_request(a resource passed from gpios); gpio_direction_input() request_irq(gpio_to_irq()) Never both. And IIUC that was what happened in the OMAP case. Isn't the core issue that we can translate a GPIO number to an IRQ number, but not the other way around ? If that could be done, we could request the GPIO and configure it as an input when the IRQ is requested. - The line direction of the interrupt GPIO line is not explicitly set as input, even though it is obvious that such a line need to be set up in this way, often making the system depend on boot-on defaults for this kind of settings. Should also be solvable if the gpio request problem is solved. Agreed... -- Regards, Laurent Pinchart -- 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: [GIT PULL 1/2] usb phy nop rename for v3.12 merge window
Tony Lindgren t...@atomide.com writes: The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.12/usb-signed for you to fetch changes up to 3fa4d7344be0afebd80382ffeea6b1787cccf971: usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv (2013-08-09 17:26:00 +0300) Pulled into next/cleanup. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] minimal dra7xx support for v3.12 merge window
Tony Lindgren t...@atomide.com writes: The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.12/dra7xx for you to fetch changes up to cf470a1b1a741bca00080ebc70968b4f22d9b1ea: Merge tag 'dra7-core-support-minus-dt' of git://github.com/rrnayak/linux into omap-for-v3.12/soc (2013-08-14 01:01:41 -0700) Thanks, pulled into next/soc. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection
Hi George,
On 08/16/2013 07:13 PM, George Cherian wrote:
Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
Signed-off-by: George Cherian george.cher...@ti.com
---
.../devicetree/bindings/extcon/extcon-dra7xx.txt | 19 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-dra7xx.c | 234
+
4 files changed, 261 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
create mode 100644 drivers/extcon/extcon-dra7xx.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
new file mode 100644
index 000..37e4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
@@ -0,0 +1,19 @@
+EXTCON FOR DRA7xx
+
+Required Properties:
+ - compatible : Should be ti,dra7xx-usb
+ - gpios : phandle to ID pin and interrupt gpio.
+
+Optional Properties:
+ - interrupt-parent : interrupt controller phandle
+ - interrupts : interrupt number
+
+
+dra7x_extcon1 {
You used 'dra7xx-usb' device name. Why did you use 'dra7x_extcon1' name?
What is meaning 'dra7x_extcon1'?
+ compatible = ti,dra7xx-usb;
+ gpios = pcf_usb 1 0,
+ gpio6 11 2;
+ interrupt-parent = gpio6;
+ interrupts = 11;
+ };
You have to keep indentation rule.
+
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index f1d54a3..b9cf0b2 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,4 +64,11 @@ config EXTCON_PALMAS
Say Y here to enable support for USB peripheral and USB host
detection by palmas usb.
+config EXTCON_DRA7XX
+ tristate DRA7XX EXTCON support
+ help
+ Say Y here to enable support for USB peripheral and USB host
+ detection by pcf8575 using DRA7XX extcon.
You should explain detailed description about pcf8575 on patch description
and change description of EXTCON_DRA7xx as following:
using DRA7XX extcon - using DRA7XX device or using DRA7XX usb
+
+
Remove unnecessary blank line.
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index e4fa8ba..e4778f9 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
+obj-$(CONFIG_EXTCON_DRA7XX) += extcon-dra7xx.o
diff --git a/drivers/extcon/extcon-dra7xx.c b/drivers/extcon/extcon-dra7xx.c
new file mode 100644
index 000..268c25e
--- /dev/null
+++ b/drivers/extcon/extcon-dra7xx.c
@@ -0,0 +1,234 @@
+/*
+ * DRA7XX USB ID pin detection driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: George Cherian george.cher...@ti.com
+ *
+ * Based on extcon-palmas.c
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/kthread.h
+#include linux/freezer.h
+#include linux/platform_device.h
+#include linux/extcon.h
+#include linux/err.h
+#include linux/of.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+
+struct dra7xx_usb {
+ struct device *dev;
+
+ struct extcon_dev edev;
+ struct task_struct *thread_task;
+
+ /*GPIO pin */
Add space between /* and GPIO.
+ int id_gpio;
+ int irq_gpio;
+
+ int id_prev;
+ int id_current;
+
+};
+
+static const char *dra7xx_extcon_cable[] = {
+ [0] = USB,
+ [1] = USB-HOST,
+ NULL,
+};
+
+static const int mutually_exclusive[] = {0x3, 0x0};
+
+static int id_poll_func(void *data)
+{
+ struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
+
+ allow_signal(SIGINT);
+ allow_signal(SIGTERM);
+ allow_signal(SIGKILL);
+ allow_signal(SIGUSR1);
+
+ set_freezable();
+
+ while (!kthread_should_stop()) {
+ dra7xx_usb-id_current = gpio_get_value_cansleep
+ (dra7xx_usb-id_gpio);
+ if (dra7xx_usb-id_current == dra7xx_usb-id_prev) {
+
Re: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support
Hi Grygorii, On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote: This patch series intorduces twl6030-irq module rework to use Threaded IRQ and linear irq_domain, and adds support for PMIC TWL6032 IRQs. After this patch series TWL6030/6032 IRQs will be supported only for DT boot mode. Changes since v1: - Added new patch mfd: twl6030-irq: create struct twl6030_irq which introduces struct twl6030_irq to store all local variables inside it. - Patch mfd: twl6030-irq: migrate to IRQ threaded handler: Minor comments applied; fixed twl6030_exit_irq(); The Parent IRQ has been set for each nested IRQ. - Patch mfd: twl6030-irq: convert to use linear irq_domain: The irq_find_mapping() is used in twl6030_mmc_card_detect_config() to get virtual IRQ number. This looks good to me. Kevin, Graeme, any further comments/ACKs ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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: [PATCHv5 16/31] CLK: TI: DRA7: Add APLL support
Hi Mark/Tero,
Sorry for responding late.
On Monday 19 August 2013 07:22 PM, Tero Kristo wrote:
On 08/13/2013 02:14 PM, Mark Rutland wrote:
On Fri, Aug 02, 2013 at 05:25:35PM +0100, Tero Kristo wrote:
From: Keerthy j-keer...@ti.com
The patch adds support for DRA7 PCIe APLL. The APLL
sources the optional functional clocks for PCIe module.
APLL stands for Analog PLL. This is different when comapred
with DPLL meaning Digital PLL, the phase detection is done
using an analog circuit.
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/apll.txt | 32 +++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/apll.c | 209
include/linux/clk/ti.h |2 +
5 files changed, 244 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/ti/apll.txt
create mode 100644 drivers/clk/ti/apll.c
diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt
b/Documentation/devicetree/bindings/clock/ti/apll.txt
new file mode 100644
index 000..f7a82e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
@@ -0,0 +1,32 @@
+Binding for Texas Instruments APLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped APLL with usually two selectable input clocks
+(reference clock and bypass clock), with analog phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) APLL mostly behaves like
+a subtype of a DPLL [2], although a simplified one at that.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/dpll.txt
+
+Required properties:
+- compatible : shall be ti,dra7-apll-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : array of register base addresses for controlling the APLL:
+ reg[0] = control register
+ reg[1] = idle status register
Using reg-names is likely a good idea here.
I'll change these for next rev to be similar to what was discussed in
the DPLL part.
+- ti,clk-ref : link phandle for the reference clock
+- ti,clk-bypass : link phandle for the bypass clock
You don't need this. Use the clocks and clock-names properties.
Ditto.
[...]
+static int dra7_apll_enable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+ int r = 0, i = 0;
+ struct dpll_data *ad;
+ const char *clk_name;
+ u8 state = 1;
+ u32 v;
+
+ ad = clk-dpll_data;
+ if (!ad)
+ return -EINVAL;
+
+ clk_name = __clk_get_name(clk-hw.clk);
+
+ state = __ffs(ad-idlest_mask);
+
+ /* Check is already locked */
+ if ((__raw_readl(ad-idlest_reg) ad-idlest_mask) == state)
+ return r;
Why __raw_readl rather than raw_readl?
Hmm not sure, Keerthy, do you have any comment on this as the patch
was originally written by you? :)
It was more taking the reference from omap2 code. raw_readl can be used.
+
+ v = __raw_readl(ad-control_reg);
+ v = ~ad-enable_mask;
+ v |= APLL_FORCE_LOCK __ffs(ad-enable_mask);
+ __raw_writel(v, ad-control_reg);
Why not raw_writel? Do you not need the rmb() provided by writel, here
or anywhere else?
Same, Keerthy? Probably just legacy copy paste from omap2 code and can
be updated based on your comment. Some of these might actually be some
old optimizations, but the APLL enable/disable should be called so
seldom it shouldn't matter. If no objections, I'll just change these
all for next rev.
Thanks Tero.
[...]
+void __init of_dra7_apll_setup(struct device_node *node)
+{
+ const struct clk_ops *ops;
+ struct clk *clk;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ struct of_phandle_args clkspec;
+ u8 apll_flags = 0;
+ struct dpll_data *ad;
+ u32 idlest_mask = 0x1;
+ u32 autoidle_mask = 0x3;
+ int i;
+
+ ops = apll_ck_ops;
+ ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+ if (!ad) {
+ pr_err(%s: could not allocate dpll_data\n, __func__);
+ return;
+ }
+
+ of_property_read_string(node, clock-output-names, clk_name);
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap dpll %s must have parent(s)\n,
+ __func__, node-name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents,
GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+
Re: AM335x, early printk
Hi Sebastian, On Monday 19 August 2013 06:07 PM, Sebastian Andrzej Siewior wrote: Yes. I do not see the decompress messages but I have an early console later on. Unfortunately it stops now right at the serial core: |pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 |Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled I vaguely remember facing a similar issue on it's yet to be born sibling while trying to woke it up in the womb, see if placing dtb at a different location helps (probably so that images won't get corrupted) Regards Afzal -- 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
