Re: [PATCH 0/2] arm: am335x: am335x evm sk: add touchscreen DT node
On Mon, Oct 21, 2013 at 03:13:22PM -0500, Felipe Balbi wrote: Hi, the following patches fix a typo on TSC/ADC DT binding while maintaining backwards compatibility and add support for the touchscreen available on am335x-evm-sk. Patches have been tested with am335x-evm-sk with a couple patches (already floating around the mailing lists) to get that board booting in mainline. cheers Applied, thank you. Felipe Balbi (2): input: touchscreen: fix spelling mistake in TSC/ADC DT binding arm: dts: am335x sk: add touchscreen support .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 2 +- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/boot/dts/am335x-evmsk.dts | 10 ++ drivers/input/touchscreen/ti_am335x_tsc.c | 9 - 4 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.4.GIT -- Dmitry -- 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
[pandaboard] OTG port not working
Since suggested by gregkh, here a CC. Greets, Tobias EDIT: Oops, I totally missed the most important bit: https://bugzilla.kernel.org/show_bug.cgi?id=64771 -- 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] doc: devicetree: Add bindings documentation for omap-des driver
Hi Joel,
I realise I'm a little late in replying to this, but there are a few
things that would be nice to fix up.
On Fri, Nov 08, 2013 at 12:37:09AM +, Joel Fernandes wrote:
Add documentation for the generic OMAP DES crypto module describing the device
tree bindings.
Signed-off-by: Joel Fernandes jo...@ti.com
---
.../devicetree/bindings/crypto/omap-des.txt| 28
++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt
diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt
b/Documentation/devicetree/bindings/crypto/omap-des.txt
new file mode 100644
index 000..0637647
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-des.txt
@@ -0,0 +1,28 @@
+OMAP SoC DES crypto Module
+
+Required properties:
+
+- compatible : Should be ti,omap4-des
Nit: s/Should be/Should contain/
+- ti,hwmods: Name of the hwmod associated with the DES module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the DES module
Just to check: there's only one interrupt?
+- clocks : phandle to the functional clock node of the DES module
+- clock-names : Name of the functional clock
What name is expected here? The intent of clock-names is to describe
which clock input lines the clocks are wired to, so this should be
well-defined.
From the looks of the example, the clock input is called fck. Is that
correct?
When you have clock-names, the nicest thing to do is to define clocks
in terms of clock-names. Something like:
- clocks: A phandle + clock-specifier pair for each entry in
clock-names.
- clock-names: Should contain:
* fck for the functional clock
Which implies that the correct way to find clocks is to look in
clock-names first to find the clock's index, rather than grabbing the
clock by index. This makes it far easier to add/remove/change clocks in
future.
+
+Optional properties:
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+ Documentation/devicetree/bindings/dma/dma.txt
Similarly here it would be nice to have dmas refer to dma-names for
the description of which dmas exist.
+- dma-names: DMA request names should include tx and rx if present
+
+Example:
+ /* DRA7xx SoC */
+ des: des@480a5000 {
+ compatible = ti,omap4-des;
+ ti,hwmods = des;
+ reg = 0x480a5000 0xa0;
+ interrupts = GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH;
+ dmas = sdma 117, sdma 116;
+ dma-names = tx, rx;
+ clocks = l3_iclk_div;
+ clock-names = fck;
+ };
Cheers,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance
On 2013-11-06 23:24, Aaro Koskinen wrote: When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig (LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled, the following BUG is seen during the boot: [7.302154] = [7.307128] [ BUG: bad unlock balance detected! ] [7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted [7.318450] - [7.323425] kworker/u2:1/12 is trying to release lock (ddata-mutex) at: [7.330657] [c031b760] acx565akm_enable+0x12c/0x18c [7.335998] but there are no more locks to release! Fix by removing the extra mutex_unlock(). Reported-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c index e6d56f7..72fe2a8 100644 --- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c +++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c @@ -616,7 +616,7 @@ static int acx565akm_enable(struct omap_dss_device *dssdev) mutex_lock(ddata-mutex); r = acx565akm_panel_power_on(dssdev); - mutex_unlock(ddata-mutex); + /* NOTE: acx565akm_panel_power_on() will unlock the mutex. */ if (r) return r; Hm why would you fix it like this? Why not remove the mutex_unlock from acx565akm_panel_power_on()? Looks to me like that one is the buggy one. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. But that is your decision. BR and thanks, Nikolaus -- 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 0/3] omapdss: venc: Add support for bypass and acbias.
On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, and I don't want to cause needless changes on code that I do not maintain. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Yes that is very likely true. The problem is that there is no other official API to modify the DEFCONF1 register. Therefore we introduced this (propsal). Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the constants (bit patterns) you suggested below. But we thought that it is not robust enough because a VENC driver or other one could then change bits it is not responsible for. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); Hm. Depends on. If the func is explaining enough it is clear. Or if I have access to some header file. If I don't, the enum values are probably more readable. But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. Well, there must be a method how the OPA can tell the VENC that it exists and the VENC can tell the SoC DEFCONF1 to enable bias and bypass. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias and bypass are enabled, but is not allowed to tell that it is there. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, because we think that it is unavoidable (no API to control the DEFCONF1 register exists yet). Maybe one of the omap3 core maintainers can comment as well? and I don't want to cause needless changes on code that I do not maintain. Yes, this should be avoided of course. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi Felipe,
On Thursday 17 October 2013 10:08 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 16, 2013 at 01:24:11AM +0530, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt boot
or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
I'm fine with this patch, but one comment below:
@@ -387,16 +388,49 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
-dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
-dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+count = of_count_phandle_with_args(node, usb-phy, NULL);
+switch (count) {
+case 2:
+dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+usb-phy, 1);
+if (IS_ERR(dwc-usb3_phy)) {
+dev_err(dev, usb3 phy not found\n);
+return PTR_ERR(dwc-usb3_phy);
+}
+case 1:
+dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+usb-phy, 0);
+if (IS_ERR(dwc-usb2_phy)) {
+dev_err(dev, usb2 phy not found\n);
+return PTR_ERR(dwc-usb2_phy);
+}
+break;
+default:
+dev_err(dev, usb phy nodes not configured\n);
+}
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
-dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+if (pdata-usb2_phy) {
+dwc-usb2_phy = devm_usb_get_phy(dev,
+USB_PHY_TYPE_USB2);
+if (IS_ERR(dwc-usb2_phy)) {
+dev_err(dev, usb2 phy not found\n);
+return PTR_ERR(dwc-usb2_phy);
+}
+}
+
+if (pdata-usb3_phy) {
+dwc-usb3_phy = devm_usb_get_phy(dev,
+USB_PHY_TYPE_USB3);
+if (IS_ERR(dwc-usb3_phy)) {
+dev_err(dev, usb3 phy not found\n);
+return PTR_ERR(dwc-usb3_phy);
+}
+}
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +443,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
-if (IS_ERR(dwc-usb2_phy)) {
-ret = PTR_ERR(dwc-usb2_phy);
-
-/*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
-if (ret == -ENXIO)
-return ret;
-
-dev_err(dev, no usb2 phy configured\n);
-return -EPROBE_DEFER;
-}
-
-if (IS_ERR(dwc-usb3_phy)) {
-ret = PTR_ERR(dwc-usb3_phy);
-
-/*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
-if (ret == -ENXIO)
-return ret;
-
-dev_err(dev, no usb3 phy configured\n);
-return -EPROBE_DEFER;
-}
the idea for doing the error checking here was actually to avoid
duplicating it in all previous cases, as you did. Please keep the error
checking here and you're good to go.
-
dwc-xhci_resources[0].start = res-start;
dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
DWC3_XHCI_REGS_END;
diff --git a/drivers/usb/dwc3/platform_data.h
b/drivers/usb/dwc3/platform_data.h
index 7db34f0..49ffa6d 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+bool usb2_phy;
+bool usb3_phy;
This would look better as a quirks flag, then we could:
unsigned long quirks;
#define DWC3_QUIRK_NO_USB3_PHY
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. What about calling it prepare_venc_for_external_amplifier (or similar). Then, venc.c can hide that really has to be done and call whatever SoC API is needed to program DEFCONF1? I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, and I don't want to cause needless changes on code that I do not maintain. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: doc: Document missing binding for ti-sdma controller
On Sat, Nov 9, 2013 at 5:53 AM, Sricharan R r.sricha...@ti.com wrote: Hi Rob, On Saturday 09 November 2013 03:24 AM, Rob Herring wrote: On Fri, Nov 8, 2013 at 4:38 AM, Sricharan R r.sricha...@ti.com wrote: The binding and support for system DMA module present in OMAP2+ Socs and DRA7 with dma-engine is already present. So adding the missing documentation for the same. Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Documentation/devicetree/bindings/dma/ti-sdma.txt | 28 + 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti-sdma.txt diff --git a/Documentation/devicetree/bindings/dma/ti-sdma.txt b/Documentation/devicetree/bindings/dma/ti-sdma.txt new file mode 100644 index 000..7fb2342 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-sdma.txt @@ -0,0 +1,28 @@ +TI SDMA + +Required Properties: +- compatible : Should be ti,omap2420-sdma, ti,omap2430-sdma for OMAP2 + Should be ti,omap3430-sdma, ti,omap3630-sdma for OMAP3 + Should be ti,omap4430-sdma for OMAP4, OMAP5 and DRA7 +- reg: Memory map for accessing module +- interrupts: Interrupt request number from the dma controller to s/dma/DMA/ + interrupt controller +- dma-cells: Should be set to 1 +- dma-channels: Total number of logical DMA channels supported by the + controller +- dma-requests: Total number of dma request signals supported by the s/dma/DMA/ Ok, will correct case. + controller These should have the # included. Sorry, i do not follow this ? You are missing the # in the property names as the example has: + #dma-cells = 1; + #dma-channels = 32; + #dma-requests = 64; Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: doc: Document missing binding for ti-sdma controller
On Monday 11 November 2013 09:26 PM, Rob Herring wrote: On Sat, Nov 9, 2013 at 5:53 AM, Sricharan R r.sricha...@ti.com wrote: Hi Rob, On Saturday 09 November 2013 03:24 AM, Rob Herring wrote: On Fri, Nov 8, 2013 at 4:38 AM, Sricharan R r.sricha...@ti.com wrote: The binding and support for system DMA module present in OMAP2+ Socs and DRA7 with dma-engine is already present. So adding the missing documentation for the same. Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Documentation/devicetree/bindings/dma/ti-sdma.txt | 28 + 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti-sdma.txt diff --git a/Documentation/devicetree/bindings/dma/ti-sdma.txt b/Documentation/devicetree/bindings/dma/ti-sdma.txt new file mode 100644 index 000..7fb2342 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-sdma.txt @@ -0,0 +1,28 @@ +TI SDMA + +Required Properties: +- compatible : Should be ti,omap2420-sdma, ti,omap2430-sdma for OMAP2 + Should be ti,omap3430-sdma, ti,omap3630-sdma for OMAP3 + Should be ti,omap4430-sdma for OMAP4, OMAP5 and DRA7 +- reg: Memory map for accessing module +- interrupts: Interrupt request number from the dma controller to s/dma/DMA/ + interrupt controller +- dma-cells: Should be set to 1 +- dma-channels: Total number of logical DMA channels supported by the + controller +- dma-requests: Total number of dma request signals supported by the s/dma/DMA/ Ok, will correct case. + controller These should have the # included. Sorry, i do not follow this ? You are missing the # in the property names as the example has: + #dma-cells = 1; + #dma-channels = 32; + #dma-requests = 64; Rob Oh, ok, Will add this. Regards, Sricharan -- 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 V2 1/2] ARM: dts: doc: Document missing binding for omap5-mpu
The binding and support for omap5-mpu which has a cortex-a15
smp core, gic and integrated L2 cache has been existing for sometime.
So Documenting the missing binding here.
Cc: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
Documentation/devicetree/bindings/arm/omap/mpu.txt |8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/mpu.txt
b/Documentation/devicetree/bindings/arm/omap/mpu.txt
index 1a5a42c..83f405b 100644
--- a/Documentation/devicetree/bindings/arm/omap/mpu.txt
+++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt
@@ -7,10 +7,18 @@ The MPU contain CPUs, GIC, L2 cache and a local PRCM.
Required properties:
- compatible : Should be ti,omap3-mpu for OMAP3
Should be ti,omap4-mpu for OMAP4
+ Should be ti,omap5-mpu for OMAP5
- ti,hwmods: mpu
Examples:
+- For an OMAP5 SMP system:
+
+mpu {
+compatible = ti,omap5-mpu;
+ti,hwmods = mpu
+};
+
- For an OMAP4 SMP system:
mpu {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] ARM: dts: doc: Document missing binding for ti-sdma controller
The binding and support for system DMA module present in OMAP2+ Socs
and DRA7 with dma-engine is already present. So adding the missing
documentation for the same.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Fixed comments from Rob Herring robherri...@gmail.com
Documentation/devicetree/bindings/dma/ti-sdma.txt | 28 +
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-sdma.txt
b/Documentation/devicetree/bindings/dma/ti-sdma.txt
new file mode 100644
index 000..2e0a6d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-sdma.txt
@@ -0,0 +1,28 @@
+TI SDMA
+
+Required Properties:
+- compatible : Should be ti,omap2420-sdma, ti,omap2430-sdma for OMAP2
+ Should be ti,omap3430-sdma, ti,omap3630-sdma for OMAP3
+ Should be ti,omap4430-sdma for OMAP4, OMAP5 and DRA7
+- reg: Memory map for accessing module
+- interrupts: Interrupt request number from the DMA controller to
+ interrupt controller
+- #dma-cells: Should be set to 1
+- #dma-channels: Total number of logical DMA channels supported by the
+ controller
+- #dma-requests: Total number of DMA request signals supported by the
+ controller
+
+Example:
+
+sdma: dma-controller@48056000 {
+ compatible = ti,omap4430-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+};
--
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] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On 16:38-20131107, Kevin Hilman wrote:
[...]
That's debatable I guess. The ideal world is that runtime PM hides all
of this, but I'm not sure it's achievable in all cases.
Agreed. some drivers like edma need to save and restore context around
suspend.
[...]
No, that sysfs knob is for disabling runtime PM. We still want the
device to hit low-power state in system suspend. Solving that problem
is half the reason we have this omap_device noirq mess in the first
place.
You need to test this by disabling runtime PM from userspace and ensure
that the low power state is still hit during suspend.
Done and it still does work, makes sense since it just ensures that
runtime PM's dev-power.runtime_status is set to RPM_SUSPENDED instead
of RPM_ACTIVE for devices that depend on autosuspend.
Logs (based on vendor kernel which has relevant out of tree patches to
enable suspend resume - still in the works):
AM335x-BBB: http://pastie.org/8472182
OMAP5-uEVM: http://pastie.org/8472183
+ /* NOTE: *might* indicate driver race */
Yes, a driver race which should then be fixed in the driver.
true if this is a non-autosuspend device, in auto suspend devices,
this could be a regular phenomenon if timeout is pretty large.. but
atleast that should allow debug.
Agreed. I wasn't thinking about the autosuspend case. Thanks for
clarifying.
+ dev_dbg(dev, %s: Force suspending\n,
+ __func__);
+ pm_runtime_set_suspended(dev);
+ od-flags |= OMAP_DEVICE_SUSPEND_FORCED;
Not sure why you need an additonal flag. Why not just always do this
and use the existin OMAP_DEVICE_SUSPENDED flag.
restore of runtime data structure state is only needed for specific
devices - not all..
The question is why do you a flag in addition to OMAP_DEVICE_SUSPEND.
Whenever that flag is set, omap_device has gone behind your back, and
the runtime PM status should be kept in sync.
Yes, you are right, originally, I had intended this to indicate devices
that needed to be runtime_status updated, but then, now I realize that
it is true for all devices that have OMAP_DEVICE_SUSPEND set. It can be
applied without an additional flag. Do see if the updated patch is more
sensible:
-- 8 --
From 96b5a7b89fef4ba55bca48bae83e5536d697c6c4 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 24 Oct 2013 09:12:42 -0500
Subject: [PATCH V2] ARM: OMAP2+: omap_device: maintain sane runtime pm status
around suspend/resume
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity.
For a device such as i2c who uses autosuspend, it is possible to enter
the suspend path with dev-power.runtime_status = RPM_ACTIVE.
As part of the suspend flow, the generic runtime logic would increment
it's dev-power.disable_depth to 1. This should prevent further
pm_runtime_get_sync from succeeding once the runtime_status has been
set to RPM_SUSPENDED.
Now, as part of the suspend_noirq handler in omap_device, we force the
following: if the device status is !suspended, we force the device
to idle using omap_device_idle (clocks are cut etc..). This ensures
that from a hardware perspective, the device is suspended. However,
runtime_status is left to be active.
*if* an operation is attempted after this point to
pm_runtime_get_sync, runtime framework depends on runtime_status to
indicate accurately the device status, and since it sees it to be
ACTIVE, it assumes the module is functional and returns a non-error
value. As a result the user will see pm_runtime_get succeed, however a
register access will crash due to the lack of clocks.
To prevent this from happening, we should ensure that runtime_status
exactly indicates the device status. As a result of this change
any further calls to pm_runtime_get* would return -EACCES (since
disable_depth is 1). On resume, we restore the clocks and runtime
status exactly as we suspended with.
Reported-by: J Keerthy j-keer...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_device.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
omap_device_idle(pdev);
od-flags |= OMAP_DEVICE_SUSPENDED;
}
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct
Re: [PATCH] clk: add flags to distinguish xtal clocks
On 11/08/2013 11:00 AM, Felipe Balbi wrote: From: Luciano Coelho l...@coelho.fi Add a flag that indicate whether the clock is a crystal or not. Additionally, parse a new device tree binding in clk-fixed-rate to set this flag. If clock-xtal isn't set, the clock framework will assume clock to be generated by an oscillator. There's only one user for this binding right now which is Texas Instruments' WiLink devices which need to know details about the clock in order to initialize the underlying WiFi HW correctly. Why on earth does it care? Surely the WiFi HW doesn't care about crystal-vs-non-crystal, but rather some facet of the clock signal that the type of source implies. Shouldn't the DT property describe that facet of the signal, rather than the reason why it has that facet? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
* Marek Belisko ma...@goldelico.com [131014 14:11]:
devconf1 reg access is localized only in mach-omap2 and we need to export
updating of devconf1 from omapdss venc driver (bypass and acbias bits).
Add simple api call which update only necessary bits.
...
+void update_bypass_acbias(bool bypass, bool acbias)
+{
+#ifdef CONFIG_ARCH_OMAP3
+ int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+
+ if (bypass)
+ val |= OMAP2_TVOUTBYPASS;
+ else
+ val = ~OMAP2_TVOUTBYPASS;
+
+ if (acbias)
+ val |= OMAP2_TVACEN;
+ else
+ val = ~OMAP2_TVACEN;
+
+ omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
+#endif
If this is truly a pinmux, you could already access this
using pinctrl-single,bits device tree driver.
But I guess that won't work yet, so it's best to set this
up as a separate driver like we've done for the USB PHY
registers.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
* Dr. H. Nikolaus Schaller h...@goldelico.com [13 06:30]: Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Yes that is very likely true. The problem is that there is no other official API to modify the DEFCONF1 register. Therefore we introduced this (propsal). Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the constants (bit patterns) you suggested below. I posted something about accessing the ctrl module regs to the first patch in the series. It's best to set it up as a separate driver for now and then maybe handle it with pinctrl-single,bits when DSS is device tree enabled. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add missing reg, interrupt and dma entries for omap3
* Sebastian Reichel s...@ring0.de [131110 15:48]: Hi Tony, On Thu, Oct 17, 2013 at 03:15:22PM -0700, Tony Lindgren wrote: Looks like omap3 is still relying on hwmod data for some basic device tree information. Let's add the information to omap3.dtsi so we can remove the related hwmod data once omap3 is DT only. This patch fixes a regression in omap3 DT boot introduced by commit 2a0b965cfb6efc667228831fc3a30308b4f94a87. This commit assumes, that interrupts are specified via DT data if booted via DT. Yes sorry about that, this should have been merged as a fix earlier to avoid breaking things during the merge window. Looks like I only tested 2a0b965cfb6efc667228831fc3a30308b4f94a87 separately on omap4 or something and forgot about the dependency. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: devicetree: Add bindings documentation for omap-des driver
On 11/11/2013 05:01 AM, Mark Rutland wrote: Hi Joel, I realise I'm a little late in replying to this, but there are a few things that would be nice to fix up. On Fri, Nov 08, 2013 at 12:37:09AM +, Joel Fernandes wrote: Add documentation for the generic OMAP DES crypto module describing the device tree bindings. Signed-off-by: Joel Fernandes jo...@ti.com --- .../devicetree/bindings/crypto/omap-des.txt| 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt b/Documentation/devicetree/bindings/crypto/omap-des.txt new file mode 100644 index 000..0637647 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/omap-des.txt @@ -0,0 +1,28 @@ +OMAP SoC DES crypto Module + +Required properties: + +- compatible : Should be ti,omap4-des Nit: s/Should be/Should contain/ ok +- ti,hwmods: Name of the hwmod associated with the DES module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt-specifier for the DES module Just to check: there's only one interrupt? Yes. +- clocks : phandle to the functional clock node of the DES module +- clock-names : Name of the functional clock What name is expected here? The intent of clock-names is to describe which clock input lines the clocks are wired to, so this should be well-defined. From the looks of the example, the clock input is called fck. Is that correct? Yes. The clock name is used by PM code to get the clock for the particular device. Yes the code assumes it to be fck, I can change doc to be so. When you have clock-names, the nicest thing to do is to define clocks in terms of clock-names. Something like: - clocks: A phandle + clock-specifier pair for each entry in clock-names. - clock-names: Should contain: * fck for the functional clock Which implies that the correct way to find clocks is to look in clock-names first to find the clock's index, rather than grabbing the clock by index. This makes it far easier to add/remove/change clocks in future. Ok. I'll reword documentation of clocks as above. + +Optional properties: +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, +Documentation/devicetree/bindings/dma/dma.txt Similarly here it would be nice to have dmas refer to dma-names for the description of which dmas exist. Ok, will make the above 3 changes and resubmit, if its ok will add your Reviewed-by. thanks, -Joel -- 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] doc: devicetree: Add bindings documentation for omap-des driver
On Mon, Nov 11, 2013 at 05:13:35PM +, Joel Fernandes wrote: On 11/11/2013 05:01 AM, Mark Rutland wrote: Hi Joel, I realise I'm a little late in replying to this, but there are a few things that would be nice to fix up. On Fri, Nov 08, 2013 at 12:37:09AM +, Joel Fernandes wrote: Add documentation for the generic OMAP DES crypto module describing the device tree bindings. Signed-off-by: Joel Fernandes jo...@ti.com --- .../devicetree/bindings/crypto/omap-des.txt| 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt b/Documentation/devicetree/bindings/crypto/omap-des.txt new file mode 100644 index 000..0637647 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/omap-des.txt @@ -0,0 +1,28 @@ +OMAP SoC DES crypto Module + +Required properties: + +- compatible : Should be ti,omap4-des Nit: s/Should be/Should contain/ ok +- ti,hwmods: Name of the hwmod associated with the DES module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt-specifier for the DES module Just to check: there's only one interrupt? Yes. +- clocks : phandle to the functional clock node of the DES module +- clock-names : Name of the functional clock What name is expected here? The intent of clock-names is to describe which clock input lines the clocks are wired to, so this should be well-defined. From the looks of the example, the clock input is called fck. Is that correct? Yes. The clock name is used by PM code to get the clock for the particular device. Yes the code assumes it to be fck, I can change doc to be so. When you have clock-names, the nicest thing to do is to define clocks in terms of clock-names. Something like: - clocks: A phandle + clock-specifier pair for each entry in clock-names. - clock-names: Should contain: * fck for the functional clock Which implies that the correct way to find clocks is to look in clock-names first to find the clock's index, rather than grabbing the clock by index. This makes it far easier to add/remove/change clocks in future. Ok. I'll reword documentation of clocks as above. + +Optional properties: +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt Similarly here it would be nice to have dmas refer to dma-names for the description of which dmas exist. Ok, will make the above 3 changes and resubmit, if its ok will add your Reviewed-by. That would be fine by me. With the changes: Reviewed-by: Mark Rutland mark.rutl...@arm.com Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add missing reg, interrupt and dma entries for omap3
On Mon, Nov 11, 2013 at 08:56:39AM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@ring0.de [131110 15:48]: Hi Tony, On Thu, Oct 17, 2013 at 03:15:22PM -0700, Tony Lindgren wrote: Looks like omap3 is still relying on hwmod data for some basic device tree information. Let's add the information to omap3.dtsi so we can remove the related hwmod data once omap3 is DT only. This patch fixes a regression in omap3 DT boot introduced by commit 2a0b965cfb6efc667228831fc3a30308b4f94a87. This commit assumes, that interrupts are specified via DT data if booted via DT. Yes sorry about that, this should have been merged as a fix earlier to avoid breaking things during the merge window. Looks like I only tested 2a0b965cfb6efc667228831fc3a30308b4f94a87 separately on omap4 or something and forgot about the dependency. No problem, but I think its currently not queued for 3.13. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Add missing reg, interrupt and dma entries for omap3
* Sebastian Reichel s...@ring0.de [13 09:49]: On Mon, Nov 11, 2013 at 08:56:39AM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@ring0.de [131110 15:48]: Hi Tony, On Thu, Oct 17, 2013 at 03:15:22PM -0700, Tony Lindgren wrote: Looks like omap3 is still relying on hwmod data for some basic device tree information. Let's add the information to omap3.dtsi so we can remove the related hwmod data once omap3 is DT only. This patch fixes a regression in omap3 DT boot introduced by commit 2a0b965cfb6efc667228831fc3a30308b4f94a87. This commit assumes, that interrupts are specified via DT data if booted via DT. Yes sorry about that, this should have been merged as a fix earlier to avoid breaking things during the merge window. Looks like I only tested 2a0b965cfb6efc667228831fc3a30308b4f94a87 separately on omap4 or something and forgot about the dependency. No problem, but I think its currently not queued for 3.13. Should be merged now it seems. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance
Hi, On Mon, Nov 11, 2013 at 03:37:37PM +0200, Tomi Valkeinen wrote: On 2013-11-06 23:24, Aaro Koskinen wrote: When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig (LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled, the following BUG is seen during the boot: [7.302154] = [7.307128] [ BUG: bad unlock balance detected! ] [7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted [7.318450] - [7.323425] kworker/u2:1/12 is trying to release lock (ddata-mutex) at: [7.330657] [c031b760] acx565akm_enable+0x12c/0x18c [7.335998] but there are no more locks to release! Fix by removing the extra mutex_unlock(). Reported-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c index e6d56f7..72fe2a8 100644 --- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c +++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c @@ -616,7 +616,7 @@ static int acx565akm_enable(struct omap_dss_device *dssdev) mutex_lock(ddata-mutex); r = acx565akm_panel_power_on(dssdev); - mutex_unlock(ddata-mutex); + /* NOTE: acx565akm_panel_power_on() will unlock the mutex. */ if (r) return r; Hm why would you fix it like this? Why not remove the mutex_unlock from acx565akm_panel_power_on()? Looks to me like that one is the buggy one. The unlock needs to be there because acx565akm_bl_update_status() also locks the mutex. I'll send a new version where the mutex_lock() is done inside acx565akm_panel_power_on(). A. -- 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 v2] ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance
When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig (LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled, the following BUG is seen during the boot: [7.302154] = [7.307128] [ BUG: bad unlock balance detected! ] [7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted [7.318450] - [7.323425] kworker/u2:1/12 is trying to release lock (ddata-mutex) at: [7.330657] [c031b760] acx565akm_enable+0x12c/0x18c [7.335998] but there are no more locks to release! Fix by removing double unlock and handling the locking completely inside acx565akm_panel_power_on() when doing the power on. Reported-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c index e6d56f7..d94f35d 100644 --- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c +++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c @@ -526,6 +526,8 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev) struct omap_dss_device *in = ddata-in; int r; + mutex_lock(ddata-mutex); + dev_dbg(ddata-spi-dev, %s\n, __func__); in-ops.sdi-set_timings(in, ddata-videomode); @@ -614,10 +616,7 @@ static int acx565akm_enable(struct omap_dss_device *dssdev) if (omapdss_device_is_enabled(dssdev)) return 0; - mutex_lock(ddata-mutex); r = acx565akm_panel_power_on(dssdev); - mutex_unlock(ddata-mutex); - if (r) return r; -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
From: Andreas Fenkart afenk...@gmail.com This a resend: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 42 +++ drivers/mmc/host/omap_hsmmc.c | 299 ++-- include/linux/platform_data/mmc-omap.h |4 + 3 files changed, 325 insertions(+), 20 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.
From: Andreas Fenkart andreas.fenk...@dev.digitalstrom.org
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Broken hardware, missing the swakueup line, should fallback
to polling, by setting 'ti,quirk-swakup-missing' in the
device tree. Otherwise pending SDIO IRQ are not detected
while in suspend. This affects am33xx processors.
For the DT-Binding portion:
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Kumar Gala ga...@codeaurora.org
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 18
drivers/mmc/host/omap_hsmmc.c | 86 ++--
2 files changed, 95 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..1136e6b 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,24 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
+SDIO irq while in suspend. Fallback to polling. Affected chips are
+am335x,
+
+--
+| PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request fclk
+restore, when an external event is detected. Once the clock is
+restored, the host detects the event normally.
Example:
mmc1: mmc@0x4809c000 {
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b392130..6b0ec55 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -210,6 +211,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -490,27 +494,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1067,8 +1084,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
[PATCH 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
From: Andreas Fenkart andreas.fenk...@dev.digitalstrom.org
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 28 ++-
drivers/mmc/host/omap_hsmmc.c | 195 ++--
include/linux/platform_data/mmc-omap.h |4 +
3 files changed, 213 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states default, active and idle , see example below. The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b0ec55..e880b44 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -213,11 +214,30 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_FIRED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-flags |= HSMMC_CIRQ_GPIO_FIRED;
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +472,31 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (pdata-slots[0].gpio_cirq 0
+ gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
+
+ ret = gpio_request(pdata-slots[0].gpio_cirq, sdio_cirq);
+ if (ret)
+ goto err_free_ro;
+ ret = gpio_direction_input(pdata-slots[0].gpio_cirq);
+ if (ret)
+ goto err_free_cirq;
+
+ } else {
+ pdata-slots[0].gpio_cirq = -EINVAL;
+ }
+
+
return 0;
+err_free_cirq:
+ gpio_free(pdata-slots[0].gpio_cirq);
+err_free_ro:
+ if (gpio_is_valid(pdata-slots[0].gpio_wp))
err_free_wp:
- gpio_free(pdata-slots[0].gpio_wp);
+
[PATCH 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
From: Andreas Fenkart afenk...@gmail.com
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e880b44..34e2ee0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1800,6 +1801,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ unsigned long flags;
+ bool suspended;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ if (suspended)
+ seq_printf(s, sdio irq pin\t%s\n,
+ gpio_get_value(mmc_slot(host).gpio_cirq) ?
+ high : low);
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
@@ -1807,9 +1825,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
}
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Hi
On Mon, Nov 11, 2013 at 7:52 PM, afenk...@gmail.com wrote:
From: Andreas Fenkart afenk...@gmail.com
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e880b44..34e2ee0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1800,6 +1801,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ unsigned long flags;
+ bool suspended;
+
+ spin_lock_irqsave(host-irq_lock, flags);
Why do you need a spin_lock_irqsave just to print out the status?
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags
HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ if (suspended)
+ seq_printf(s, sdio irq pin\t%s\n,
+ gpio_get_value(mmc_slot(host).gpio_cirq) ?
+ high : low);
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
Michael
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
@@ -1807,9 +1825,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
}
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
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 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
Hi
On Mon, Nov 11, 2013 at 7:52 PM, afenk...@gmail.com wrote:
From: Andreas Fenkart andreas.fenk...@dev.digitalstrom.org
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 28 ++-
drivers/mmc/host/omap_hsmmc.c | 195
++--
include/linux/platform_data/mmc-omap.h |4 +
3 files changed, 213 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as
a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to
set
+named pinctrl states default, active and idle , see example below. The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b0ec55..e880b44 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -213,11 +214,30 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_FIRED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-flags |= HSMMC_CIRQ_GPIO_FIRED;
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +472,31 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (pdata-slots[0].gpio_cirq 0
+ gpio_is_valid(pdata-slots[0].gpio_cirq)) {
Is ok only gpio_is_valid?
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
+
+ ret = gpio_request(pdata-slots[0].gpio_cirq, sdio_cirq);
+ if (ret)
+ goto err_free_ro;
+ ret = gpio_direction_input(pdata-slots[0].gpio_cirq);
+ if (ret)
+ goto err_free_cirq;
Can you use gpio_request_one?
Michael
+
+ } else {
+
Re: [PATCH 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Hi,
2013/11/11 Michael Trimarchi mich...@amarulasolutions.com:
Hi
On Mon, Nov 11, 2013 at 7:52 PM, afenk...@gmail.com wrote:
From: Andreas Fenkart afenk...@gmail.com
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e880b44..34e2ee0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1800,6 +1801,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ unsigned long flags;
+ bool suspended;
+
+ spin_lock_irqsave(host-irq_lock, flags);
Why do you need a spin_lock_irqsave just to print out the status?
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags
HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
initially, because the flags field could be changed by an irq.
It's atomic and since the code path doesn't change, it's safe to remove
the spinlock, thx
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ if (suspended)
+ seq_printf(s, sdio irq pin\t%s\n,
+ gpio_get_value(mmc_slot(host).gpio_cirq) ?
+ high : low);
This is more of an issue, the pinmux could have changed underneath, if we
resumed meanwile. Reading the GPIO value read will not reflect the pin on the
package.
It has nothing to do with the spinlock though so will remove that.
.
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
Michael
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
@@ -1807,9 +1825,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
}
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
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] clk: add flags to distinguish xtal clocks
Hi,
On Sun, Nov 10, 2013 at 12:37:16PM +0100, Maxime Ripard wrote:
Hi Felipe,
On Fri, Nov 08, 2013 at 12:00:48PM -0600, Felipe Balbi wrote:
From: Luciano Coelho l...@coelho.fi
Add a flag that indicate whether the clock is a crystal or not.
Additionally, parse a new device tree binding in clk-fixed-rate to set
this flag.
If clock-xtal isn't set, the clock framework will assume clock to be
generated by an oscillator. There's only one user for this binding
right now which is Texas Instruments' WiLink devices which need to know
details about the clock in order to initialize the underlying WiFi HW
correctly.
Signed-off-by: Luciano Coelho l...@coelho.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
Dropped CLK_IS_TYPE_DEFINED flag and just assume that if the flag
isn't there, default behavior will be taken.
Documentation/devicetree/bindings/clock/fixed-clock.txt | 1 +
drivers/clk/clk-fixed-rate.c| 6 +-
include/linux/clk-provider.h| 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt
b/Documentation/devicetree/bindings/clock/fixed-clock.txt
index 0b1fe78..3036dfe 100644
--- a/Documentation/devicetree/bindings/clock/fixed-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt
@@ -12,6 +12,7 @@ Required properties:
Optional properties:
- gpios : From common gpio binding; gpio connection to clock enable pin.
- clock-output-names : From common clock binding.
+- clock-xtal: true when a clock is provided by a crystal
Example:
clock {
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 1ed591a..5db9bf0 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -91,13 +91,17 @@ void of_fixed_clk_setup(struct device_node *node)
struct clk *clk;
const char *clk_name = node-name;
u32 rate;
+ unsigned long flags = CLK_IS_ROOT;
if (of_property_read_u32(node, clock-frequency, rate))
return;
+ if (of_property_read_bool(node, clock-xtal))
+ flags |= CLK_IS_TYPE_XTAL;
+
Introducing a new compatible instead of a property would make more
sense here I think.
Do you have a reason not to do so?
As you can see, this is original work from Luca but I disagree that
adding a new compatible makes more sense. This still related to a fixed
rate clock, we're just giving it one extra metadata which will
differentiate between crystal and oscilator fixed rate clocks.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] clk: add flags to distinguish xtal clocks
Hi, On Mon, Nov 11, 2013 at 09:27:58AM -0700, Stephen Warren wrote: On 11/08/2013 11:00 AM, Felipe Balbi wrote: From: Luciano Coelho l...@coelho.fi Add a flag that indicate whether the clock is a crystal or not. Additionally, parse a new device tree binding in clk-fixed-rate to set this flag. If clock-xtal isn't set, the clock framework will assume clock to be generated by an oscillator. There's only one user for this binding right now which is Texas Instruments' WiLink devices which need to know details about the clock in order to initialize the underlying WiFi HW correctly. Why on earth does it care? Surely the WiFi HW doesn't care about crystal-vs-non-crystal, but rather some facet of the clock signal that the type of source implies. Shouldn't the DT property describe that facet of the signal, rather than the reason why it has that facet? well, if you can figure out what that facet is, then _do_ tell. Luca has tried for months to get that information with no success. -- balbi signature.asc Description: Digital signature
[PATCH v2] doc: devicetree: Add bindings documentation for omap-des driver
Add documentation for the generic OMAP DES crypto modul describing the device
tree bindings.
Reviewed-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
v2 changes: Update documentation for clocks, clock-names and dma-names.
.../devicetree/bindings/crypto/omap-des.txt| 30 ++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt
diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt
b/Documentation/devicetree/bindings/crypto/omap-des.txt
new file mode 100644
index 000..e8c63bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-des.txt
@@ -0,0 +1,30 @@
+OMAP SoC DES crypto Module
+
+Required properties:
+
+- compatible : Should contain ti,omap4-des
+- ti,hwmods: Name of the hwmod associated with the DES module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the DES module
+- clocks : A phandle to the functional clock node of the DES module
+ corresponding to each entry in clock-names
+- clock-names : Name of the functional clock, should be fck
+
+Optional properties:
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+ Documentation/devicetree/bindings/dma/dma.txt
+ Each entry corresponds to an entry in dma-names
+- dma-names: DMA request names should include tx and rx if present
+
+Example:
+ /* DRA7xx SoC */
+ des: des@480a5000 {
+ compatible = ti,omap4-des;
+ ti,hwmods = des;
+ reg = 0x480a5000 0xa0;
+ interrupts = GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH;
+ dmas = sdma 117, sdma 116;
+ dma-names = tx, rx;
+ clocks = l3_iclk_div;
+ clock-names = fck;
+ };
--
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: [PATCH] clk: add flags to distinguish xtal clocks
On Mon, 2013-11-11 at 13:42 -0600, Felipe Balbi wrote:
Hi,
On Sun, Nov 10, 2013 at 12:37:16PM +0100, Maxime Ripard wrote:
Hi Felipe,
On Fri, Nov 08, 2013 at 12:00:48PM -0600, Felipe Balbi wrote:
From: Luciano Coelho l...@coelho.fi
Add a flag that indicate whether the clock is a crystal or not.
Additionally, parse a new device tree binding in clk-fixed-rate to set
this flag.
If clock-xtal isn't set, the clock framework will assume clock to be
generated by an oscillator. There's only one user for this binding
right now which is Texas Instruments' WiLink devices which need to know
details about the clock in order to initialize the underlying WiFi HW
correctly.
Signed-off-by: Luciano Coelho l...@coelho.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
Dropped CLK_IS_TYPE_DEFINED flag and just assume that if the flag
isn't there, default behavior will be taken.
Documentation/devicetree/bindings/clock/fixed-clock.txt | 1 +
drivers/clk/clk-fixed-rate.c| 6 +-
include/linux/clk-provider.h| 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt
b/Documentation/devicetree/bindings/clock/fixed-clock.txt
index 0b1fe78..3036dfe 100644
--- a/Documentation/devicetree/bindings/clock/fixed-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt
@@ -12,6 +12,7 @@ Required properties:
Optional properties:
- gpios : From common gpio binding; gpio connection to clock enable pin.
- clock-output-names : From common clock binding.
+- clock-xtal: true when a clock is provided by a crystal
Example:
clock {
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 1ed591a..5db9bf0 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -91,13 +91,17 @@ void of_fixed_clk_setup(struct device_node *node)
struct clk *clk;
const char *clk_name = node-name;
u32 rate;
+ unsigned long flags = CLK_IS_ROOT;
if (of_property_read_u32(node, clock-frequency, rate))
return;
+ if (of_property_read_bool(node, clock-xtal))
+ flags |= CLK_IS_TYPE_XTAL;
+
Introducing a new compatible instead of a property would make more
sense here I think.
Do you have a reason not to do so?
As you can see, this is original work from Luca but I disagree that
adding a new compatible makes more sense. This still related to a fixed
rate clock, we're just giving it one extra metadata which willAnd t
differentiate between crystal and oscilator fixed rate clocks.
I agree with Felipe. This was discussed before [1]. While still at TI,
I tried to figure out the exact need for the firmware to know whether it
was an oscillator or not. It was mostly because the stabilization time
and such things differ with oscillators, but I wasn't able to find out
how exactly this affected things.
In any case, as I concluded earlier (but it's not really my call), being
a crystal or an oscillator *is* a characteristic of the hardware,
regardless of whether that information is useful or not. In the WiLink
case it is, at least it can differentiate the clocks that are used in
the HW modules it uses.
So IMHO it doesn't really hurt and it's not really against the DT
principles.
[1] https://lkml.org/lkml/2013/7/29/321
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
This a resend: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 42 +++ drivers/mmc/host/omap_hsmmc.c | 299 ++-- include/linux/platform_data/mmc-omap.h |4 + 3 files changed, 325 insertions(+), 20 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Broken hardware, missing the swakueup line, should fallback
to polling, by setting 'ti,quirk-swakup-missing' in the
device tree. Otherwise pending SDIO IRQ are not detected
while in suspend. This affects am33xx processors.
For the DT-Binding portion:
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Kumar Gala ga...@codeaurora.org
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 18
drivers/mmc/host/omap_hsmmc.c | 86 ++--
2 files changed, 95 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..1136e6b 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,24 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
+SDIO irq while in suspend. Fallback to polling. Affected chips are
+am335x,
+
+--
+| PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request fclk
+restore, when an external event is detected. Once the clock is
+restored, the host detects the event normally.
Example:
mmc1: mmc@0x4809c000 {
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b392130..6b0ec55 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -210,6 +211,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -490,27 +494,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1067,8 +1084,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status =
[PATCH 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 28 ++-
drivers/mmc/host/omap_hsmmc.c | 189 ++--
include/linux/platform_data/mmc-omap.h |4 +
3 files changed, 207 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states default, active and idle , see example below. The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b0ec55..5a7fb4b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -213,11 +214,30 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_FIRED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-flags |= HSMMC_CIRQ_GPIO_FIRED;
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +472,25 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
+ ret = gpio_request_one(pdata-slots[0].gpio_cirq, GPIOF_DIR_IN,
+ sdio_cirq);
+ if (ret)
+ goto err_free_ro;
+
+ } else {
+ pdata-slots[0].gpio_cirq = -EINVAL;
+ }
+
+
return 0;
+err_free_ro:
+ if (gpio_is_valid(pdata-slots[0].gpio_wp))
err_free_wp:
- gpio_free(pdata-slots[0].gpio_wp);
+ gpio_free(pdata-slots[0].gpio_wp);
err_free_cd:
if (gpio_is_valid(pdata-slots[0].switch_pin))
err_free_sp:
@@ -469,6 +504,69 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
[PATCH 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5a7fb4b..c4f71d0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1794,6 +1795,20 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
+
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ if (suspended)
+ seq_printf(s, sdio irq pin\t%s\n,
+ gpio_get_value(mmc_slot(host).gpio_cirq) ?
+ high : low);
+ }
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
@@ -1801,9 +1816,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
}
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
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] clk: add flags to distinguish xtal clocks
On Mon, Nov 11, 2013 at 01:42:47PM -0600, Felipe Balbi wrote: + if (of_property_read_bool(node, clock-xtal)) + flags |= CLK_IS_TYPE_XTAL; + Introducing a new compatible instead of a property would make more sense here I think. Do you have a reason not to do so? As you can see, this is original work from Luca but I disagree that adding a new compatible makes more sense. This still related to a fixed rate clock, we're just giving it one extra metadata which will differentiate between crystal and oscilator fixed rate clocks. I don't know, I think it's more a matter of consistency. If we turn the problem the other way around. Let's say we have a crystal that for some reason can't be used with clk-fixed-rate. You'd add a new driver for it, with a compatible of its own, and you'd put that XTAL flag in there, without any extra metadata in the DT, right? And I'm pretty sure having a compatible like clk-xtal would make it pretty obvious that it's still a fixed rate clock. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] clk: add flags to distinguish xtal clocks
Hi Luca, On Mon, Nov 11, 2013 at 09:50:56PM +0200, Luca Coelho wrote: On Mon, 2013-11-11 at 13:42 -0600, Felipe Balbi wrote: + if (of_property_read_bool(node, clock-xtal)) + flags |= CLK_IS_TYPE_XTAL; + Introducing a new compatible instead of a property would make more sense here I think. Do you have a reason not to do so? As you can see, this is original work from Luca but I disagree that adding a new compatible makes more sense. This still related to a fixed rate clock, we're just giving it one extra metadata which willAnd t differentiate between crystal and oscilator fixed rate clocks. I agree with Felipe. This was discussed before [1]. While still at TI, I tried to figure out the exact need for the firmware to know whether it was an oscillator or not. It was mostly because the stabilization time and such things differ with oscillators, but I wasn't able to find out how exactly this affected things. In any case, as I concluded earlier (but it's not really my call), being a crystal or an oscillator *is* a characteristic of the hardware, regardless of whether that information is useful or not. In the WiLink case it is, at least it can differentiate the clocks that are used in the HW modules it uses. So IMHO it doesn't really hurt and it's not really against the DT principles. Just to be clear, I'm not against your patch. If you need this to make your driver work, then it's fine for me. Mike will probably know better if we actually need some extra metadata. What I'm not really convinced about is *how* you carry that metadata in the DT, that's all, nothing more. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
Hi Tony,
On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren t...@atomide.com wrote:
* Marek Belisko ma...@goldelico.com [131014 14:11]:
devconf1 reg access is localized only in mach-omap2 and we need to export
updating of devconf1 from omapdss venc driver (bypass and acbias bits).
Add simple api call which update only necessary bits.
...
+void update_bypass_acbias(bool bypass, bool acbias)
+{
+#ifdef CONFIG_ARCH_OMAP3
+ int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+
+ if (bypass)
+ val |= OMAP2_TVOUTBYPASS;
+ else
+ val = ~OMAP2_TVOUTBYPASS;
+
+ if (acbias)
+ val |= OMAP2_TVACEN;
+ else
+ val = ~OMAP2_TVACEN;
+
+ omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
+#endif
If this is truly a pinmux, you could already access this
using pinctrl-single,bits device tree driver.
But I guess that won't work yet, so it's best to set this
up as a separate driver like we've done for the USB PHY
registers.
Can you please point me to that driver directly? I cannot see benefit
of new driver as as it will be only dummy driver
with export_symbol_gpl of upper function. Can it sit then in dss
directory or somewhere else? Thanks.
Regards,
Tony
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
Hi Tony,
On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren t...@atomide.com wrote:
* Marek Belisko ma...@goldelico.com [131014 14:11]:
devconf1 reg access is localized only in mach-omap2 and we need to export
updating of devconf1 from omapdss venc driver (bypass and acbias bits).
Add simple api call which update only necessary bits.
...
+void update_bypass_acbias(bool bypass, bool acbias)
+{
+#ifdef CONFIG_ARCH_OMAP3
+ int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+
+ if (bypass)
+ val |= OMAP2_TVOUTBYPASS;
+ else
+ val = ~OMAP2_TVOUTBYPASS;
+
+ if (acbias)
+ val |= OMAP2_TVACEN;
+ else
+ val = ~OMAP2_TVACEN;
+
+ omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
+#endif
If this is truly a pinmux, you could already access this
using pinctrl-single,bits device tree driver.
AFAIK it's not pinmux it's register where we update bits. Or am I
missing something?
But I guess that won't work yet, so it's best to set this
up as a separate driver like we've done for the USB PHY
registers.
Regards,
Tony
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
* Belisko Marek marek.beli...@gmail.com [13 14:01]:
Hi Tony,
On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren t...@atomide.com wrote:
* Marek Belisko ma...@goldelico.com [131014 14:11]:
devconf1 reg access is localized only in mach-omap2 and we need to export
updating of devconf1 from omapdss venc driver (bypass and acbias bits).
Add simple api call which update only necessary bits.
...
+void update_bypass_acbias(bool bypass, bool acbias)
+{
+#ifdef CONFIG_ARCH_OMAP3
+ int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+
+ if (bypass)
+ val |= OMAP2_TVOUTBYPASS;
+ else
+ val = ~OMAP2_TVOUTBYPASS;
+
+ if (acbias)
+ val |= OMAP2_TVACEN;
+ else
+ val = ~OMAP2_TVACEN;
+
+ omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
+#endif
If this is truly a pinmux, you could already access this
using pinctrl-single,bits device tree driver.
But I guess that won't work yet, so it's best to set this
up as a separate driver like we've done for the USB PHY
registers.
Can you please point me to that driver directly? I cannot see benefit
of new driver as as it will be only dummy driver
with export_symbol_gpl of upper function. Can it sit then in dss
directory or somewhere else? Thanks.
You can take a look at drivers/usb/phy/phy-omap-control.c.
Then there's a device tree using example for control_devconf0 in
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
Looks like CONTROL_DEVCONF1 contains a bunch of misc registers,
and arch/arm/mach-omap2/hsmmc.c seems to be tinkering with it too.
It would be best to set it up as omap-ctrl.c driver under drivers
somewhere with few functions exported for DSS and MMC drivers.
The reason why it should be a separate driver is that the system
control module can live a separate runtime PM life from the
drivers using the CONTROL_DEVCONF register bits.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
* Belisko Marek marek.beli...@gmail.com [13 14:21]: AFAIK it's not pinmux it's register where we update bits. Or am I missing something? Most of the omap control module registers seem to affect either external pin configuration or internal signal muxes. So a big chunk of them can already be handled with pinctrl-single,bits for device tree. But some of the control module registers also have regulator and clock like features, and those are better exposed as regulators and clocks to the consumer drivers. 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
[RFC] Refactoring and moving dmtimer code
Hi Thomas and everyone, I'm currently trying to refactor our dmtimer code in various ways and there are different challenges in doing so, some goals are shorterm and others long term, but I need some guidance so that I can do things the right way to begin with. I wanted to start a discussion on what needs to be done, and sort of track what's blocking us and establish certain guidelines/recommendations before starting to do things etc. (1) With ARCH_MULTIPLATFORM turned on, arch/arm/plat-*/include/plat/ is no longer accessible to drivers/. Due to this, all such drivers that need direct access to a *specific* dmtimer don't work and are disabled: drivers/media/rc/ir-rx51.c and drivers/staging/tidspbridge/core/dsp-clock.c We're also going to be having mailbox code needing dedicated timers at some point. So as a first step, I'd like to split dmtimer.h (arch/arm/plat-omap/include/plat/dmtimer.h) into a public header. The header currently consists of 2 parts, First part is mostly private where __omap_dmtimer functions are defined, which should really not be accessible to users of the dmtimer API. Second mostly would be the public dmtimer API which *should* be public so that drivers that need it are not disabled with ARCH_MULTIPLATFORM. Could you suggest a good place for this header? I'd like to split this header and expose a second dmtimer.h in a suitable include directory. (2) Moving of dmtimer.c code out of plat-omap into a suitable drivers/ directory This could be the next step where we move dmtimer.c into a suitable place other than arch/arm/plat-omap/. The public dmtimer API will be declared through the above header. Drivers that need specific timers such as DSP and mailbox can use it. Though this part of the code would not deal with clocksource framework, does it makes sense to move it into drivers/clocksource/? Any other suggestions? (3) Establish an omap clocksource driver in drivers/clocksource/ Currently all our system timer code resides in arch/arm/mach-omap2/timer.c, in the long run I'd like to convert this to a clocksource driver. But currently the code is a bit dependent and entangled with PM code (which we call hwmod). This work may have to wait till hwmod cleanups can happen, that's why I'm keeping it for last before we can finish with the baby steps. Suggestions are welcome here. (2) and (3) can indeed be combined into a single driver even and placed in a suitable location. But the big question I guess is, is drivers/clocksource/ the right place. Thanks in advance for your valuable guidance, looking forward to getting some momentum with this work. regards, -Joel -- 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] dma: edma: Add support for Cyclic DMA
On Thu, Oct 31, 2013 at 04:31:23PM -0500, Joel Fernandes wrote: Using the PaRAM configuration function that we split for reuse by the different DMA types, we implement Cyclic DMA support. For the cyclic case, we pass different configuration parameters to this function, and handle all the Cyclic-specific functionality separately. Callbacks to the DMA users are handled using vchan_cyclic_callback in the virt-dma layer. Linking is handled the same way as the slave SG case except for the last slot where we link it back to the first one in a cyclic fashion. For continuity, we check for cases where no.of periods is great than the MAX number of slots the driver can allocate for a particular descriptor and error out on such cases. Applied, thanks ~Vinod -- 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/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote:
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/omap4-common.c |4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b5fb5f7..2086c65 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -141,6 +141,7 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_SMP
select COMMON_CLK
+ select IRQ_CROSSBAR
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 5791143..274cbfa 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -22,6 +22,7 @@
#include linux/of_platform.h
#include linux/export.h
#include linux/irqchip/arm-gic.h
+#include linux/irqchip/irq-crossbar.h
#include linux/of_address.h
#include linux/reboot.h
@@ -282,9 +283,12 @@ void __init omap_gic_of_init(void)
skip_errata_init:
omap_wakeupgen_init();
+ if (soc_is_dra7xx())
+ crossbar_init();
Its good if this is called irqcrossbar_init() to avoid confusion
with the dma crossbar which also exists in dra7 devices.
irqchip_init();
}
+
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
Hi Rajendra, On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote: On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote: Enable the crossbar IP support for DRA7xx soc. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap4-common.c |4 2 files changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..2086c65 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -141,6 +141,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK +select IRQ_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 5791143..274cbfa 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -22,6 +22,7 @@ #include linux/of_platform.h #include linux/export.h #include linux/irqchip/arm-gic.h +#include linux/irqchip/irq-crossbar.h #include linux/of_address.h #include linux/reboot.h @@ -282,9 +283,12 @@ void __init omap_gic_of_init(void) skip_errata_init: omap_wakeupgen_init(); +if (soc_is_dra7xx()) +crossbar_init(); Its good if this is called irqcrossbar_init() to avoid confusion with the dma crossbar which also exists in dra7 devices. Ya makes sense. Will change this. Regards, Sricharan -- 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
