Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
On 12/17/13 21:31, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [131216 23:16]:
On 12/16/13 21:17, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [131216 05:57]:
On 12/13/13 21:22, Tony Lindgren wrote:
[...]
I think we can drop the different memory sizes and
let boot loader adjust the blob. This will make the list shorter:
omap3-cm-t3x.dtsi- common to cm-t3x cpu boards
omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
omap3-cm-t3730.dtsi - cm-t3730 specific
omap3-cm-t3530.dtsi - cm-t3530 specific
omap3-cm-t3517.dtsi - cm-t3517 specific
omap3-sb-t35.dtsi- sb-t35 specific
omap3-cb-t3.dtsi - cb-t3 specific
omap3-sbc-t3730.dts - sb-t35 with cm-t3730 and default memory size
omap3-sbc-t3530.dts - sb-t35 with cm-t3530 and default memory size
omap3-sbc-t3517.dts - sb-t35 with cm-t3517 and default memory size
omap3-em-t3730.dts - cb-t3 with cm-t3730 and default memory size
omap3-em-t3530.dts - cb-t3 with cm-t3530 and default memory size
So what do you think?
Makes sense to me. I've updated the patch below to use the following:
omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
omap3-cm-t3730.dts- cm-t3730 specific, should work on it's own too, not a
.dtsi
omap3-sb-t35.dtsi - sb-t35 specific
omap3-sbc-t3730.dts - sb-t35 with cm-t3730 and default memory size
So the only changes compared to your naming are to not use .dtsi
extension for omap3-cm-t3730.dts, and I did not add omap3-cm-t3x.dtsi
as I don't know the details.
Ok.
It's probably best that you guys take over this patch from here and
add omap3-cm-t3x30.dtsi if needed.
Ok.
I got the basic stuff working for what I need right now for my router
to work, which is MMC, both Ethernet controllers and wl12xx. So I'm
not going to tweak this patch further. Of course having the battery
charging working would be nice for a router to have a backup battery :)
There are still some issues I've noticed:
1. Removing and reinserting the wl12xx modules seems to kill the
WLAN
2. Ethernet interfaces only come up if there's a cable connected
I see. Ok then, we'll try to figure those things out.
[...]
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat0.sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat1.sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat2.sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat3.sdmmc2_dat3 */
Here the following is missing:
0x134 (PIN_OUTPUT | MUX_MODE1) /* sdmmc2_dat4.sdmmc2_dir_dat0 */
That seems to be used for the wl12xx GPIO, so it's listed at
wl12xx_gpio below.
Yes, but only on cm-t3730 (and actually starting from revision 1.2),
not cm-t3530...
Sounds like that needs another set of .dts files, or patching in the
bootloader.
Yep, IMO, .dts will be better, as I think pinmux is something
the kernel should be aware of...
[...]
8 --
From: Tony Lindgren t...@atomide.com
Date: Tue, 10 Dec 2013 15:03:34 -0800
Subject: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
This adds support for CompuLab SBC-T3530, also known as cm-t3730:
http://compulab.co.il/products/sbcs/sbc-t3530/
It seems that with the sbc-3xxx mainboard is also used on
SBC-T3517 and SBC-T3730 with just a different CPU module:
http://compulab.co.il/products/sbcs/sbc-t3517/
http://compulab.co.il/products/sbcs/sbc-t3730/
So let's add a common omap3-sb-t35.dtsi and then separate SoC
specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
omap3-sbc-t3517.dts.
I've tested this with SBC-T3730 as that's the only one I have.
At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
work.
Note that WLAN seems to be different for SBC-T3530. And SBC-T3517
may need some changes for the EMAC Ethernet if that's used
instead of the smsc911x.
Cc: devicet...@vger.kernel.org
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
This one looks great!
Really minor comments below (we can fix those later)
[...]
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
b/arch/arm/boot/dts/omap3-cm-t3730.dts
new file mode 100644
index 000..80cf668
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
[...]
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
vsim is not present in TPS65930...
can be just left empty or set to a fixed voltage regulator.
+ bus-width = 4;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+};
[...]
diff
Re: [PATCH V5 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
Hi Thomas, On Tuesday 03 December 2013 03:57 PM, Sricharan R wrote: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. This series models the peripheral interrupts that can be routed through the crossbar to the GIC as 'routable-irqs'. The routable irqs are added in a separate linear domain inside the GIC. The registered routable domain's callback are invoked as a part of the GIC's callback, which in turn should allocate a free irq line and configure the IP accordingly. So every peripheral in the dts files mentions the fixed crossbar number as its interrupt. A free gic line for that gets allocated and configured when the peripheral interrupts are mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. V5: Addressed a comment from Mark Rutland mark.rutl...@arm.com, updated tags and rebased on 3.13-rc2 V4: Addressed a couple of comments and split the DTS file updates in to a separate series. V3: Addressed few more comments from Thomas Gleixner t...@linutronix.de Rebased patches 3,4,5,7 which updates the DTS file on top of below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts Rebased patches 1,2,6 on top of 3.12 mainline Updated Commit tags V2: Addressed Thomas Gleixner t...@linutronix.de comments and Kumar Gala ga...@codeaurora.org Split updating the DRA7.dtsi file for adding the routable-irqs Previous discussions that led to this is at https://lkml.org/lkml/2013/9/18/540 The V1,V2,V3,V4 post of these patches is at [V1] https://lkml.org/lkml/2013/9/30/283 [V2] http://www.spinics.net/lists/linux-omap/msg99540.html [V3] http://www.kernelhub.org/?msg=356470p=2 [V4] http://www.spinics.net/lists/linux-doc/msg16726.html Sricharan R (4): DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Documentation/devicetree/bindings/arm/gic.txt |6 + .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap-wakeupgen.c |4 +- arch/arm/mach-omap2/omap4-common.c |2 + drivers/irqchip/Kconfig|8 + drivers/irqchip/Makefile |1 + drivers/irqchip/irq-crossbar.c | 208 drivers/irqchip/irq-gic.c | 81 +++- include/linux/irqchip/arm-gic.h|7 +- include/linux/irqchip/irq-crossbar.h | 11 ++ 11 files changed, 343 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c create mode 100644 include/linux/irqchip/irq-crossbar.h I have addressed all the comments on this series, can this be merged now ? 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] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.9+
---
drivers/mfd/omap-usb-tll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..248004c 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
if (needs_tll) {
void __iomem *base = tll-base;
@@ -398,9 +400,8 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
@@ -420,7 +421,9 @@ int omap_tll_enable(struct usbhs_omap_platform_data *pdata)
tll = dev_get_drvdata(tll_dev);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
@@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data *pdata)
}
spin_unlock(tll_lock);
-
return 0;
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
@@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data *pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
On 2013-12-18 09:12, Tomi Valkeinen wrote: Well yeah let's keep those separate still as at least Russell needed some more time with the legacy booting. The point we can drop the legacy booting for omap3 may still need to wait a bit, maybe even until v3.15 to keep things working. They can't be separate. Once I add DT support for a board, I have to remove the legacy support for that board. This patch removes legacy support for the boards that are converted in the series. If I don't remove the legacy support, both DT and legacy side will be ran, and both create the DSS devices... But, it's true that this patch removes the whole file, as all the boards currently there are converted. But if new boards are added to the DSS quirks, then I can't remove the file. So I'll change this patch to only remove the parts for the converted boards, not the whole file. But but... If I understand right, the plan is to remove all omap3 board files for the next merge window. I'm not totally familiar with the quirks system, but how should this be handled: omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices are created via DT code. But if the display (i.e. panels) for a particular omap3 board has not been converted to DT, we should still use the legacy DSS initialization. But the DSS is already initialized via DT. I guess I can set the status for all the DSS nodes to disabled in omap3.dtsi, and that should prevent DT code from creating the DSS devices. Then, each omap3-board.dts that has been converted to DSS DT, can override those to enabled. That way the DT code should not create DSS devices by default, and the quirks system would probably work fine. I changed the DSS DT nodes to be disabled by default, and I think this works nicely. It's actually better this way in any case, as we can leave blocks like DSI out for boards that don't need it. Also, I now remove the quirks only for the boards that are converted to DT, not the whole dss-common.c file. So I think we can now add new boards to dss-common.c, if and when there are ones that cannot be converted to use DSS DT yet. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.9+
---
drivers/mfd/omap-usb-tll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..248004c 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
This is pretty ugly. Can't you move it above the spin_lock() instead?
snip
tll = dev_get_drvdata(tll_dev);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
Same here?
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
@@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data
*pdata)
}
spin_unlock(tll_lock);
-
This doesn't belong in this patch and is now inconsistent with the
other functions in the driver.
return 0;
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
@@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data
*pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe 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 3/5] usb: xhci-plat: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the XHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/xhci-plat.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 8abda5c..1bc1565 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -162,6 +162,8 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + device_enable_async_suspend(pdev-dev); + return 0; put_usb3_hcd: -- 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: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
On 2013-12-17 17:15, Laurent Pinchart wrote: Either the driver is too specific or the binding is too generic, but having such a generic name for an omap specific driver seems wrong. Same for panel-dpi, svideo-connector, composite-video-connector and hdmi-connector, Hmm. Good point. I was thinking that the driver is only used on OMAP, but of course that's not true, the driver is there for all platforms if the kernel just happens to be compiled with the driver. And it's not just about those drivers you mention. The same issue is there for, say, ti,tpd12s015. I have an omapdss specific driver for that, but if some other platform uses the same chip, they'll have a driver for it also... Sigh. I wonder how this should be handled... The only solution that comes to my mind is to have all the compatible strings as ti, But that's not correct, as they are not TI components, but some are generic ones and some from another vendor. And even ti,... is not good, as there are other TI SoCs with other display drivers. So I'd need to prepend the compatible strings with omapdss,..., making the hardware components driver specific. The long term plan is to make the drivers generic (or implement the same driver for common display framework). But for now I need to have future proof DT bindings with omapdss specific drivers... I'll refrain from mentioning that the problem has been identified more than a year ago. Oh, wait, I've metioned it, sorry :-D We really want to make drivers generic enough to be shared by multiple display controllers. I would vote for making the DT bindings generic now already, which would be enough to buy some time to fix the problem properly. If we start prepending driver-specific prefixes such as omapdss, to compatible string we'll just make the mess even larger and reduce the incentive to fix it. It would be the worst decision we could make. Well... I think there are no good options here. I see the following options: 1. Add omapdss, or similar to compat strings in DT, and the same for the drivers. This solves the issue, but then we'll have bad DT data, although I see similar method already being used in some places. When we have common drivers, we can remove the omapdss, strings from DT, but we still need to keep them in the drivers to have backward compatibility. 2. Keep the compat strings generic in DT. This way we'll have correct DT data, but if anyone happens to create a new driver with the same compat string, things will break. omapdss can only be compiled for a kernel with OMAP and ARM support, so it narrows the problematic drivers a bit. 3. Have correct DT data, but at init time, in omap arch code, go through the DT data and change the compat strings for the display nodes to include omapdss,. This way the drivers would only work for omap platforms. Like a combination of 1. and 2. I'm not sure if the DT-code allows this at the moment, though. We could also now select option 2., and go for 3. later if someone else creates a driver with the same compat string. While I'm obviously not very impartial here, I do think that using generic bindings for omapdss is not the worst possible case, as: I'm very much dedicated to get CDF merged at some point, and I already have been working on it for each revision. I also think that even if the omap panel drivers are currently omap specific, they are not very much so. I have been changing them over the years to be more and more generic, and I have used them as a base for CDF panel drivers. If some platform specific driver may have a generic compat string, omap panel drivers are not the worst option. I will look at the option 3., hopefully that will be possible and everybody will be happy. Any other ideas appreciated. Tomi signature.asc Description: OpenPGP digital signature
[RFC 5/5] usb: dwc3: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3 device (the parent of xhci-plat) in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3 driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/core.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 59bb8d2..9c8a273 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -586,6 +586,8 @@ static int dwc3_probe(struct platform_device *pdev) pm_runtime_allow(dev); + device_enable_async_suspend(dev); + return 0; err3: -- 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
[RFC 4/5] usb: dwc3-exynos: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3-exynos platform device in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3-exynos driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..57431b7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -155,6 +155,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev) goto err2; } + device_enable_async_suspend(dev); + return 0; err2: -- 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
[RFC 1/5] usb: ohci-exynos: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the Exynos OHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/ohci-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 68588d8..faad2bdc 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -137,6 +137,8 @@ skip_phy: if (exynos_ohci-otg) exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self); + device_enable_async_suspend(pdev-dev); + platform_set_drvdata(pdev, hcd); exynos_ohci_phy_enable(pdev); -- 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
[RFC 2/5] usb: ehci-s5p: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the Exynos EHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/ehci-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index f7ce8e2..e5125cd 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -165,6 +165,8 @@ skip_phy: } device_wakeup_enable(hcd-self.controller); + device_enable_async_suspend(pdev-dev); + platform_set_drvdata(pdev, hcd); return 0; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
On Wed, Dec 18, 2013 at 9:41 AM, Andreas Naumann d...@andin.de wrote:
Am 17.12.2013 18:22, schrieb David Cohen:
On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
From: Andreas Naumann anaum...@ultratronik.de
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it has not been
initialized yet.
Signed-off-by: Andreas Naumann anaum...@ultratronik.de
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy
with this.
drivers/usb/musb/omap2430.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
struct device *control_otghs;
+ u8 initialized;
};
#define glue_to_musb(g) platform_get_drvdata(g-musb)
@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}
musb_writel(musb-mregs, OTG_INTERFSEL, l);
+ glue-initialized = 1;
pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x,
sysstatus 0x%x, intrfsel 0x%x, simenable
0x%x\n,
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device
*pdev)
glue-dev = pdev-dev;
glue-musb = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+ glue-initialized = 0;
You don't need to do this. 'glue' was already allocated with kzalloc().
ok
if (np) {
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata),
GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device
*dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if(glue-initialized)
Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
No, the problem is that omap2430_runtime_resume() is called _during_
omap2430_must_init(), when pm_runtime_get_sync() is called. We can't
read the initial register value before pm_runtime_get_sync() returns
because the hardware is not powered up, and from pm_runtime_get_sync()
omap2430_runtime_resume() is called, where the cached register value
is needed.
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.
We would only have problems if runtime_suspend() and runtime_resume()
are called at the same time, can this really happed?
Grazvydas
--
To unsubscribe from this list: send the line unsubscribe 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] pwm: core: Rearrange pwm lock.
When tiecap is used as a module, then while doing a rmmod I
get the following dump.
root@am437x-evm:/# rmmod pwm_tiecap
[ 219.539245]
[ 219.540771] ==
[ 219.546936] [ INFO: possible circular locking dependency detected ]
[ 219.553192] 3.12.4-01557-g9921cde-dirty #134 Not tainted
[ 219.558471] ---
[ 219.564727] rmmod/1517 is trying to acquire lock:
[ 219.569427] (s_active#35){.+}, at: [c017ab00]
sysfs_hash_and_remove+0x4c/0x8c
[ 219.577239]
[ 219.577239] but task is already holding lock:
[ 219.583068] (pwm_lock){+.+.+.}, at: [c0303598] pwmchip_remove+0x14/0xf8
[ 219.589996]
[ 219.589996] which lock already depends on the new lock.
[ 219.589996]
[ 219.598144]
[ 219.598144] the existing dependency chain (in reverse order) is:
[ 219.605590]
- #1 (pwm_lock){+.+.+.}:
[ 219.609497][c00a2d1c] lock_acquire+0x9c/0x128
[ 219.614746][c0639bc0] mutex_lock_nested+0x50/0x3dc
[ 219.620391][c0303974] pwm_request_from_chip+0x38/0x6c
[ 219.626312][c0303fe0] pwm_export_store+0x50/0x140
[ 219.631896][c039aba8] dev_attr_store+0x18/0x24
[ 219.637207][c017aff0] sysfs_write_file+0x16c/0x1a0
[ 219.642883][c0119084] vfs_write+0xb0/0x188
[ 219.647857][c0119478] SyS_write+0x3c/0x70
[ 219.652770][c0014100] ret_fast_syscall+0x0/0x48
[ 219.658172]
- #0 (s_active#35){.+}:
[ 219.662353][c00a2778] __lock_acquire+0x1b28/0x1b70
[ 219.667999][c00a2d1c] lock_acquire+0x9c/0x128
[ 219.673248][c017c780] sysfs_addrm_finish+0xe8/0x158
[ 219.678985][c017ab00] sysfs_hash_and_remove+0x4c/0x8c
[ 219.684906][c017e224] remove_files+0x38/0x74
[ 219.690063][c017e2a4] sysfs_remove_group+0x44/0x108
[ 219.695800][c017e38c] sysfs_remove_groups+0x24/0x34
[ 219.701538][c039bc2c] device_del+0xec/0x178
[ 219.706604][c039bcc4] device_unregister+0xc/0x18
[ 219.712097][c0303658] pwmchip_remove+0xd4/0xf8
[ 219.717407][c039fdc4] platform_drv_remove+0x18/0x1c
[ 219.723175][c039e6c4] __device_release_driver+0x70/0xc8
[ 219.729248][c039eec8] driver_detach+0xb4/0xb8
[ 219.734497][c039e4ec] bus_remove_driver+0x8c/0xd0
[ 219.740081][c00abd2c] SyS_delete_module+0x118/0x22c
[ 219.745819][c0014100] ret_fast_syscall+0x0/0x48
[ 219.751220]
[ 219.751220] other info that might help us debug this:
[ 219.751220]
[ 219.759216] Possible unsafe locking scenario:
[ 219.759216]
[ 219.765106]CPU0CPU1
[ 219.769622]
[ 219.774139] lock(pwm_lock);
[ 219.777130]lock(s_active#35);
[ 219.782897]lock(pwm_lock);
[ 219.788391] lock(s_active#35);
[ 219.791656]
[ 219.791656] *** DEADLOCK ***
[ 219.791656]
[ 219.797546] 3 locks held by rmmod/1517:
[ 219.801391] #0: (__lockdep_no_validate__){..}, at: [c039ee58]
driver_detach+0x44/0xb8
[ 219.810028] #1: (__lockdep_no_validate__){..}, at: [c039ee64]
driver_detach+0x50/0xb8
[ 219.818695] #2: (pwm_lock){+.+.+.}, at: [c0303598]
pwmchip_remove+0x14/0xf8
[ 219.826049]
[ 219.826049] stack backtrace:
[ 219.830413] CPU: 0 PID: 1517 Comm: rmmod Not tainted
3.12.4-01557-g9921cde-dirty #134
[ 219.838256] [c001cc98] (unwind_backtrace+0x0/0xf0) from [c0018124]
(show_stack+0x10/0x14)
[ 219.846771] [c0018124] (show_stack+0x10/0x14) from [c0636728]
(dump_stack+0x74/0xb4)
[ 219.854858] [c0636728] (dump_stack+0x74/0xb4) from [c06344e4]
(print_circular_bug+0x284/0x2d8)
[ 219.863830] [c06344e4] (print_circular_bug+0x284/0x2d8) from [c00a2778]
(__lock_acquire+0x1b28/0x1b70)
[ 219.873443] [c00a2778] (__lock_acquire+0x1b28/0x1b70) from [c00a2d1c]
(lock_acquire+0x9c/0x128)
[ 219.882476] [c00a2d1c] (lock_acquire+0x9c/0x128) from [c017c780]
(sysfs_addrm_finish+0xe8/0x158)
[ 219.891601] [c017c780] (sysfs_addrm_finish+0xe8/0x158) from [c017ab00]
(sysfs_hash_and_remove+0x4c/0x8c)
[ 219.901397] [c017ab00] (sysfs_hash_and_remove+0x4c/0x8c) from [c017e224]
(remove_files+0x38/0x74)
[ 219.910614] [c017e224] (remove_files+0x38/0x74) from [c017e2a4]
(sysfs_remove_group+0x44/0x108)
[ 219.919647] [c017e2a4] (sysfs_remove_group+0x44/0x108) from [c017e38c]
(sysfs_remove_groups+0x24/0x34)
[ 219.929260] [c017e38c] (sysfs_remove_groups+0x24/0x34) from [c039bc2c]
(device_del+0xec/0x178)
[ 219.938201] [c039bc2c] (device_del+0xec/0x178) from [c039bcc4]
(device_unregister+0xc/0x18)
[ 219.946899] [c039bcc4] (device_unregister+0xc/0x18) from [c0303658]
(pwmchip_remove+0xd4/0xf8)
[ 219.955841] [c0303658] (pwmchip_remove+0xd4/0xf8) from [c039fdc4]
(platform_drv_remove+0x18/0x1c)
[ 219.965057] [c039fdc4] (platform_drv_remove+0x18/0x1c) from [c039e6c4]
(__device_release_driver+0x70/0xc8)
[ 219.975006] [c039e6c4] (__device_release_driver+0x70/0xc8) from
[PATCH 3/3] driver: pwmss: Disable stop clk bit during enable clock call.
Writing to ecap register on second insmod crashes with an external abort. This happens becuase the STOP_CLK bit remains set(from rmmod) during the second insmod thereby not allowing the clocks to get enabled. So, we disable STOP clock bit while doing a clock enable. Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- drivers/pwm/pwm-tipwmss.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/pwm/pwm-tipwmss.c b/drivers/pwm/pwm-tipwmss.c index 3b119bc..4749866 100644 --- a/drivers/pwm/pwm-tipwmss.c +++ b/drivers/pwm/pwm-tipwmss.c @@ -40,6 +40,8 @@ u16 pwmss_submodule_state_change(struct device *dev, int set) mutex_lock(info-pwmss_lock); val = readw(info-mmio_base + PWMSS_CLKCONFIG); + if (set == PWMSS_ECAPCLK_EN) + val = ~PWMSS_ECAPCLK_STOP_REQ; val |= set; writew(val , info-mmio_base + PWMSS_CLKCONFIG); mutex_unlock(info-pwmss_lock); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] pwm: ti: Miscellaneous Fixes and cleanup for pwm.
This patch series caters to the issue faced while using tiecap as a module. The patch fix lock dependency issue which leads to crash during rmmod. Also fixes the clock control register setup values during CLK EN call. Sourav Poddar (3): pwm: core: Rearrange pwm lock usage. driver: pwm: ti-ecap: Rmove duplicate put_sync call. driver: pwmss: Disable stop during Enable clock call.. drivers/pwm/core.c|4 +++- drivers/pwm/pwm-tiecap.c |1 - drivers/pwm/pwm-tipwmss.c |2 ++ 3 files changed, 5 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] driver: pwm: ti-ecap: Remove duplicate put_sync call.
Remove duplicate 'pm_runtime_put_sync' in the remove path. Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- drivers/pwm/pwm-tiecap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c index 4e5c3d1..032092c 100644 --- a/drivers/pwm/pwm-tiecap.c +++ b/drivers/pwm/pwm-tiecap.c @@ -279,7 +279,6 @@ static int ecap_pwm_remove(struct platform_device *pdev) pwmss_submodule_state_change(pdev-dev.parent, PWMSS_ECAPCLK_STOP_REQ); pm_runtime_put_sync(pdev-dev); - pm_runtime_put_sync(pdev-dev); pm_runtime_disable(pdev-dev); return pwmchip_remove(pc-chip); } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP display subsystem - does it work?
In my continuing woes with having the OMAP boards I have produce output, where things used to work on the LDP, they now do not. And on the SDP4430 board, where things were detected, they're no longer detected. I thought this was just a matter of adjusting the configuration, but it seems there's much more wrong than just that - so I wasn't too worried. Last night, I updated the configuration to ensure that the appropriate connector configuration symbols were enabled (see the changelog in the configuration seeds.) All the time that stuff on OMAP gets broken and/or doesn't work (inspite of repeated attempts at reporting problems - I've never seen the displays on the SDP4430 board ever work with a mainline kernel in all the years I've had the platform - but they have worked with the originally supplied TI kernels) I really find myself not really caring very much about OMAP and whether it works or not. Quite honestly, I regard OMAP as nothing more than an overly complex toy implementation rather than a serious architecture because of this kind of stuff - unlike every other ARM platform where stuff like this just works, OMAP stuff is always seems to be much harder to make work, and more prone to stuff breaking. So, here goes. LDP3430: OMAP DSS rev 2.0 omapdss DPI error: can't get VDDS_DSI regulator omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral I don't see evidence of it being re-probed, but I do see this during boot which implies that there's nothing there: XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: OMAP DSS rev 4.0 omapdss DSI error: can't get VDDS_DSI regulator panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral ... omapdss DSI error: failed to set complexio power state to 1 panel-dsi-cm panel-dsi-cm.0: failed to enable DSI omapfb omapfb: Failed to enable display 'lcd' omapfb omapfb: failed to initialize default display omapfb omapfb: failed to setup omapfb Configurations, build and boot logs are all on http://www.arm.linux.org.uk/developer/build/ -- To unsubscribe from this list: send the line unsubscribe 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] crypto: omap-sham: Fix Polling mode for larger blocks
Command tcrypt sec=1 mode=403 give the follwoing error for Polling
mode:
root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403
[...]
[ 346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates):
4352 opers/sec, 17825792 bytes/sec
[ 347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates):
7095 opers/sec, 29061120 bytes/sec
[ 349.002667] test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates):
[ 349.010882] Unable to handle kernel NULL pointer dereference at virtual
address
[ 349.020037] pgd = ddeac000
[ 349.022884] [] *pgd=9dcb4831, *pte=, *ppte=
[ 349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 349.035482] Modules linked in: tcrypt(+)
[ 349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted
3.12.4-01566-g6279006-dirty #38
[ 349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000
[ 349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238
[ 349.058544] LR is at omap_sham_xmit_dma+0x38/0x238
[ 349.063570] pc : [c04eb7cc]lr : [c04eb798]psr: 2013
[ 349.063570] sp : ddcd3c78 ip : fp : 9d8980b8
[ 349.075610] r10: r9 : r8 :
[ 349.081090] r7 : 1000 r6 : dd898000 r5 : 0040 r4 : ddb10550
[ 349.087935] r3 : 0004 r2 : 0010 r1 : 53100080 r0 :
[ 349.094783] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 349.102268] Control: 10c5387d Table: 9deac019 DAC: 0015
[ 349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248)
[...]
This is because polling_mode is not enabled for ctx without FLAGS_FINUP.
For polling mode the bufcnt is made 0 unconditionally. But it should be made 0
only if it is a final update or a total is not zero(This condition is similar
to what is done in DMA case). Because of this wrong hashes are produced.
Fixing the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-sham.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index e45aaaf..a47094a 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -789,10 +789,13 @@ static int omap_sham_update_cpu(struct omap_sham_dev *dd)
dev_dbg(dd-dev, cpu: bufcnt: %u, digcnt: %d, final: %d\n,
ctx-bufcnt, ctx-digcnt, final);
- bufcnt = ctx-bufcnt;
- ctx-bufcnt = 0;
+ if (final || (ctx-bufcnt == ctx-buflen ctx-total)) {
+ bufcnt = ctx-bufcnt;
+ ctx-bufcnt = 0;
+ return omap_sham_xmit_cpu(dd, ctx-buffer, bufcnt, final);
+ }
- return omap_sham_xmit_cpu(dd, ctx-buffer, bufcnt, final);
+ return 0;
}
static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
@@ -1103,6 +1106,9 @@ static int omap_sham_update(struct ahash_request *req)
return 0;
}
+ if (dd-polling_mode)
+ ctx-flags |= BIT(FLAGS_CPU);
+
return omap_sham_enqueue(req, OP_UPDATE);
}
--
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: OMAP display subsystem - does it work?
On 2013-12-18 14:00, Russell King - ARM Linux wrote: So, here goes. LDP3430: OMAP DSS rev 2.0 omapdss DPI error: can't get VDDS_DSI regulator omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral I don't see evidence of it being re-probed, but I do see this during boot which implies that there's nothing there: XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I don't have an LDP board at hand, and I wasn't able to find out anything from the logs. I think I should change omapfb to print something if it's probed succesfully, as the deferred probing makes finding out if something is probed fine or not quite murky. Without deferred probing, it was simpler: no errors - the driver must be (most likely) ok. Although... In an earlier log, where there was no panel driver, the log has these errors: Error opening /dev/fb0: No such device There are none in the latest log, which makes me guess the omapfb has been probed, and fb0 is actually there. But the X is still dying for some reason... I'll look at this more. Maybe someone in our team can find a board to test. For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: Those particular LCDs are supposed to be updated manually using custom ioctl, so normal software using fb won't put anything on the display. For testing purposes, a SW based automatic update (~20 fps) can be enabled by kernel cmdline parameter omapfb.auto_update or via sysfs: echo 1 /sys/class/graphics/fb0/update_mode OMAP DSS rev 4.0 omapdss DSI error: can't get VDDS_DSI regulator panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral ... omapdss DSI error: failed to set complexio power state to 1 panel-dsi-cm panel-dsi-cm.0: failed to enable DSI omapfb omapfb: Failed to enable display 'lcd' omapfb omapfb: failed to initialize default display omapfb omapfb: failed to setup omapfb Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux code for display.c) was overly enthusiastic in removing legacy code which was already in use. Tony has a partial revert for that queued up. It can also be reverted fully for testing. After that, the panel wakes up. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] drm/tilcdc: Defer probe if no encoders/connectors found
At the moment this driver fails to load if no encoders/connectors were
found. In case other drivers that register encoders/connectors
(tilcdc_panel) are defered it would be better to check for
encoders/connectors later again. This patch replaces the returncode
-ENXIO with -EPROBE_DEFER to get a working setup even if tilcdc_panel
probes after tilcdc.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 116da19..217303c 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -84,7 +84,7 @@ static int modeset_init(struct drm_device *dev)
if ((priv-num_encoders == 0) || (priv-num_connectors == 0)) {
/* oh nos! */
dev_err(dev-dev, no encoders/connectors found\n);
- return -ENXIO;
+ return -EPROBE_DEFER;
}
dev-mode_config.min_width = 0;
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
On 2013-12-18 12:41, Tomi Valkeinen wrote:
3. Have correct DT data, but at init time, in omap arch code, go through
the DT data and change the compat strings for the display nodes to
include omapdss,. This way the drivers would only work for omap
platforms. Like a combination of 1. and 2. I'm not sure if the DT-code
allows this at the moment, though.
This wasn't actually too hard. It says hack all over it, but the code
was quite compact. I call the omapdss_early_init_of() as the first thing
in omap_generic_init(), before the devices are created:
+static const char* const dss_compat_conv_list[] = {
+ hdmi-connector,
+ dvi-connector,
+ ti,tpd12s015,
+ panel-dsi-cm,
+};
+
+static void omapdss_omapify_node(struct device_node *node, const char
*compat)
+{
+ char *new_compat;
+ struct property *prop;
+
+ new_compat = kasprintf(GFP_KERNEL, omapdss,%s, compat);
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ prop-name = compatible;
+ prop-value = new_compat;
+ prop-length = strlen(new_compat) + 1;
+
+ of_update_property(node, prop);
+}
+
+void __init omapdss_early_init_of(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(dss_compat_conv_list); ++i) {
+ const char *compat = dss_compat_conv_list[i];
+ struct device_node *node = NULL;
+
+ while ((node = of_find_compatible_node(node, NULL,
compat))) {
+ if (!of_device_is_available(node))
+ continue;
+
+ omapdss_omapify_node(node, compat);
+ }
+ }
+}
The list has just part of the devices, and I've so far only tested on
OMAP 4430sdp board, but it seemed to work fine.
So with this, I can have hdmi-connector in the .dts file, and
omapdss,hdmi-connector as a compat string in the omap specific driver.
Does it make your eyes bleed, or is it maybe something that could be
fine for the time being?
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH 1/2] regulator: tps65910: Add backup battery regulator
tps65910 has a backup battery charger with a configurable voltage. This
patch adds a regulator for the backup battery.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/regulator/tps65910-regulator.c | 32 ++--
include/linux/mfd/tps65910.h | 3 ++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/tps65910-regulator.c
b/drivers/regulator/tps65910-regulator.c
index a00132e..74f5e05 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -88,6 +88,11 @@ static const unsigned int VMMC_VSEL_table[] = {
180, 280, 300, 330,
};
+/* supported BBCH voltages in microvolts */
+static const unsigned int VBB_VSEL_table[] = {
+ 300, 252, 315, 500,
+};
+
struct tps_info {
const char *name;
const char *vin_name;
@@ -183,6 +188,12 @@ static struct tps_info tps65910_regs[] = {
.voltage_table = VMMC_VSEL_table,
.enable_time_us = 100,
},
+ {
+ .name = vbb,
+ .vin_name = vcc7,
+ .n_voltages = ARRAY_SIZE(VBB_VSEL_table),
+ .voltage_table = VBB_VSEL_table,
+ },
};
static struct tps_info tps65911_regs[] = {
@@ -339,6 +350,8 @@ static int tps65910_get_ctrl_register(int id)
return TPS65910_VAUX33;
case TPS65910_REG_VMMC:
return TPS65910_VMMC;
+ case TPS65910_REG_VBB:
+ return TPS65910_BBCH;
default:
return -EINVAL;
}
@@ -528,6 +541,10 @@ static int tps65910_get_voltage_sel(struct regulator_dev
*dev)
value = LDO_SEL_MASK;
value = LDO_SEL_SHIFT;
break;
+ case TPS65910_REG_VBB:
+ value = BBCH_BBSEL_MASK;
+ value = BBCH_BBSEL_SHIFT;
+ break;
default:
return -EINVAL;
}
@@ -638,6 +655,9 @@ static int tps65910_set_voltage_sel(struct regulator_dev
*dev,
case TPS65910_REG_VMMC:
return tps65910_reg_update_bits(pmic-mfd, reg, LDO_SEL_MASK,
selector LDO_SEL_SHIFT);
+ case TPS65910_REG_VBB:
+ return tps65910_reg_update_bits(pmic-mfd, reg, BBCH_BBSEL_MASK,
+ selector BBCH_BBSEL_SHIFT);
}
return -EINVAL;
@@ -669,6 +689,9 @@ static int tps65911_set_voltage_sel(struct regulator_dev
*dev,
case TPS65910_REG_VIO:
return tps65910_reg_update_bits(pmic-mfd, reg, LDO_SEL_MASK,
selector LDO_SEL_SHIFT);
+ case TPS65910_REG_VBB:
+ return tps65910_reg_update_bits(pmic-mfd, reg, BBCH_BBSEL_MASK,
+ selector BBCH_BBSEL_SHIFT);
}
return -EINVAL;
@@ -771,7 +794,7 @@ static struct regulator_ops tps65910_ops = {
.get_voltage_sel= tps65910_get_voltage_sel,
.set_voltage_sel= tps65910_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
- .map_voltage= regulator_map_voltage_ascend,
+ .map_voltage= regulator_map_voltage_iterate,
};
static struct regulator_ops tps65911_ops = {
@@ -944,6 +967,7 @@ static struct of_regulator_match tps65910_matches[] = {
{ .name = vaux2, .driver_data = (void *) tps65910_regs[10] },
{ .name = vaux33, .driver_data = (void *) tps65910_regs[11] },
{ .name = vmmc, .driver_data = (void *) tps65910_regs[12] },
+ { .name = vbb,.driver_data = (void *) tps65910_regs[13] },
};
static struct of_regulator_match tps65911_matches[] = {
@@ -1167,7 +1191,11 @@ static int tps65910_probe(struct platform_device *pdev)
pmic-desc[i].type = REGULATOR_VOLTAGE;
pmic-desc[i].owner = THIS_MODULE;
pmic-desc[i].enable_reg = pmic-get_ctrl_reg(i);
- pmic-desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
+ if (tps65910_chip_id(tps65910) == TPS65910
+ i == TPS65910_REG_VBB)
+ pmic-desc[i].enable_mask = BBCH_BBCHEN_MASK;
+ else
+ pmic-desc[i].enable_mask =
TPS65910_SUPPLY_STATE_ENABLED;
config.dev = tps65910-dev;
config.init_data = reg_data;
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 20e433e..1adeee1 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -833,6 +833,7 @@
#define TPS65910_REG_VAUX2 10
#define TPS65910_REG_VAUX3311
#define TPS65910_REG_VMMC 12
+#define TPS65910_REG_VBB 13
#define
[PATCH 2/2] ARM: dts: tps65910 backup battery regulator
This patch adds a devicetree node for the backup battery regulator.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/tps65910.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65910.dtsi b/arch/arm/boot/dts/tps65910.dtsi
index 92693a8..b0ac665 100644
--- a/arch/arm/boot/dts/tps65910.dtsi
+++ b/arch/arm/boot/dts/tps65910.dtsi
@@ -82,5 +82,10 @@
reg = 12;
regulator-compatible = vmmc;
};
+
+ vbb_reg: regulator@13 {
+ reg = 13;
+ regulator-compatible = vbb;
+ };
};
};
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 2/8] mmc: omap_hsmmc: handle vcc and vcc_aux independently
On Wednesday 11 December 2013 04:51 PM, Ulf Hansson wrote:
On 10 December 2013 12:48, Balaji T K balaj...@ti.com wrote:
On Tuesday 10 December 2013 04:39 PM, Ulf Hansson wrote:
On 21 November 2013 15:20, Balaji T K balaj...@ti.com wrote:
handle vcc and vcc_aux independently to reduce indent.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 54
+++--
1 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 1eb4350..342be25 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -286,11 +286,12 @@ static int omap_hsmmc_set_power(struct device *dev,
int slot, int power_on,
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
+ if (host-vcc)
+ ret = mmc_regulator_set_ocr(host-mmc, host-vcc,
vdd);
/* Enable interface voltage rail, if needed */
if (ret == 0 host-vcc_aux) {
ret = regulator_enable(host-vcc_aux);
- if (ret 0)
+ if (ret 0 host-vcc)
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
}
@@ -298,7 +299,7 @@ static int omap_hsmmc_set_power(struct device *dev,
int slot, int power_on,
/* Shut down the rail */
if (host-vcc_aux)
ret = regulator_disable(host-vcc_aux);
- if (!ret) {
+ if (host-vcc) {
/* Then proceed to shut down the local regulator
*/
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
@@ -318,10 +319,10 @@ static int omap_hsmmc_reg_get(struct
omap_hsmmc_host *host)
reg = devm_regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
- dev_err(host-dev, vmmc regulator missing\n);
+ dev_err(host-dev, unable to get vmmc regulator %ld\n,
+ PTR_ERR(reg));
return PTR_ERR(reg);
} else {
- mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
@@ -334,31 +335,26 @@ static int omap_hsmmc_reg_get(struct
omap_hsmmc_host *host)
return -EINVAL;
}
}
+ }
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
- /* Allow an aux regulator */
- reg = devm_regulator_get_optional(host-dev, vmmc_aux);
- host-vcc_aux = IS_ERR(reg) ? NULL : reg;
+ /* Allow an aux regulator */
+ reg = devm_regulator_get_optional(host-dev, vmmc_aux);
+ host-vcc_aux = IS_ERR(reg) ? NULL : reg;
- /* For eMMC do not power off when not in sleep state */
- if (mmc_slot(host).no_regulator_off_init)
- return 0;
- /*
- * UGLY HACK: workaround regulator framework bugs.
- * When the bootloader leaves a supply active, it's
- * initialized with zero usecount ... and we can't
- * disable it without first enabling it. Until the
- * framework is fixed, we need a workaround like this
- * (which is safe for MMC, but not in general).
- */
The above problem is handled by the mmc core layer. I certainly think
you shall adopt your code to it.
Hi Ulf,
how about optional vqmmc, omap_hsmmc does call mmc_regulator_set_ocr for
vmmc
Am I missing something?
Hi Balaji,
Sorry for being to vague, let me elaborate.
1. Before omap_hsmmc_probe returns, it invokes mmc_add_host().
2. mmc_add_host() - mmc_start_host() - mmc_power_up().
3. mmc_power_up() invokes the host driver's .set_ios() callback, to
makes sure boot-on regulators are kept enabled. Otherwise the
late_initcall, regulator_init_complete() will potentially cut power
for unused regulators.
This is important because there are SoCs that are only capable of
power cycling the VCC regulator but not VCCQ. According to the eMMC
spec, we must not cut VCC without sending the SLEEP cmd first.
Obviously, since we prevent VCC from being cut, we need to prevent
VCCQ from being cut as well.
Normally a .set_ios() function's invokes mmc_regulator_set_ocr() for
the VCC regulator. VCCQ (vmmc_aux) is handled by directly using the
regulator API (I guess we could invent an API similar to
mmc_regulator_set_ocr() but for VCCQ, but that is a future task).
So, from a host driver perspective you could add a local variable to
cache the
Re: [PATCH] drm/tilcdc: Defer probe if no encoders/connectors found
On Wed, Dec 18, 2013 at 8:56 AM, Markus Pargmann m...@pengutronix.de wrote:
At the moment this driver fails to load if no encoders/connectors were
found. In case other drivers that register encoders/connectors
(tilcdc_panel) are defered it would be better to check for
encoders/connectors later again. This patch replaces the returncode
-ENXIO with -EPROBE_DEFER to get a working setup even if tilcdc_panel
probes after tilcdc.
yeah, that is probably better than relying on late_initcall() hacks..
Signed-off-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 116da19..217303c 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -84,7 +84,7 @@ static int modeset_init(struct drm_device *dev)
if ((priv-num_encoders == 0) || (priv-num_connectors == 0)) {
/* oh nos! */
dev_err(dev-dev, no encoders/connectors found\n);
- return -ENXIO;
+ return -EPROBE_DEFER;
}
dev-mode_config.min_width = 0;
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP display subsystem - does it work?
On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote: On 2013-12-18 14:00, Russell King - ARM Linux wrote: For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: Those particular LCDs are supposed to be updated manually using custom ioctl, so normal software using fb won't put anything on the display. For testing purposes, a SW based automatic update (~20 fps) can be enabled by kernel cmdline parameter omapfb.auto_update or via sysfs: echo 1 /sys/class/graphics/fb0/update_mode I'm confused. How then can the original kernel which came with the board run two gstreamer videos on these displays by just talking to the framebuffers and play it back smoothly given that we're talking about video at normal fps settings? When I received the board, that's exactly what it did at boot up - it played back two different video trailers, one on each LCD, and the playback was smooth, just like you'd expect from watching a DVD on your TV. No missing frames, which is what you'd get if you tried to update at 20fps. -- To unsubscribe from this list: send the line unsubscribe 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] usb: musb: Fix unstable init of OTG_INTERFSEL.
Hi, On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote: From: Andreas Naumann anaum...@ultratronik.de This is a hard to reproduce problem which leads to non-functional USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore of OTG_INTERFSEL over suspend. Since the resume function is also called early in driver init, it uses a non-initialized value (which is 0 and a non-supported setting in DM37xx for INTERFSEL). Shortly after the correct value is set. Apparently this works most time, but not always. yeah, but the problem is not on the glue layer. The bug is omap_device and pm_runtime not agreeing on device's state. I suppose there was a fix for that recently in linux-omap@vger mailing list. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation
Hi, On Tue, Dec 17, 2013 at 03:35:54PM -0800, David Cohen wrote: On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote: On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: hi all, these patches add pm_runtime support for all glue layers. I plan to add pm_runtime support for dwc3 after these patches are merged upstream. Please test. At first time I failed to notice you were removing #ifdef's around pm callback functions. Instead of saying DWC3 will start to have warnings when CONFIG_PM is not selected, I'd say your patch set is now a dependence of my RFC :) I guess I said it in wrong order :P Your patch set depends on my RFC. Or I just modify my patchset a little bit for now ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation
On Wed, Dec 18, 2013 at 09:36:14AM -0600, Felipe Balbi wrote: Hi, On Tue, Dec 17, 2013 at 03:35:54PM -0800, David Cohen wrote: On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote: On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: hi all, these patches add pm_runtime support for all glue layers. I plan to add pm_runtime support for dwc3 after these patches are merged upstream. Please test. At first time I failed to notice you were removing #ifdef's around pm callback functions. Instead of saying DWC3 will start to have warnings when CONFIG_PM is not selected, I'd say your patch set is now a dependence of my RFC :) I guess I said it in wrong order :P Your patch set depends on my RFC. Or I just modify my patchset a little bit for now ;-) nah, it looks horrible with all those ifdefs around. I'll delay my patch series. -- balbi signature.asc Description: Digital signature
Re: OMAP display subsystem - does it work?
On 2013-12-18 17:29, Russell King - ARM Linux wrote: On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote: On 2013-12-18 14:00, Russell King - ARM Linux wrote: For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: Those particular LCDs are supposed to be updated manually using custom ioctl, so normal software using fb won't put anything on the display. For testing purposes, a SW based automatic update (~20 fps) can be enabled by kernel cmdline parameter omapfb.auto_update or via sysfs: echo 1 /sys/class/graphics/fb0/update_mode I'm confused. How then can the original kernel which came with the board run two gstreamer videos on these displays by just talking to the framebuffers and play it back smoothly given that we're talking about video at normal fps settings? When I received the board, that's exactly what it did at boot up - it played back two different video trailers, one on each LCD, and the playback was smooth, just like you'd expect from watching a DVD on your TV. No missing frames, which is what you'd get if you tried to update at 20fps. We once had auto-update support in omapdss in the early versions. It was removed quite a while ago, as it was a burden to maintain. Either the kernel you talk about had the auto-update support, or the userspace has support for manual-update displays. The thing is, these LCDs are not meant to be used in auto-update mode. The main point with LCDs with their own framebuffer is that they are only updated when needed. So a production device would not need auto-update support. Furthermore, as these LCDs are quite rare, and 4430SDP is the only one we support having these displays, and that board itself is not exactly a common one, it was decided that the maintenance burden is not worth it. I have been thinking of improving the auto-update in omapfb, but it has never been on the top of my list (or even middle). The current code basically does just queue_delayed_work() 20 times per second, so it's just a hack for testing. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC 5/5] usb: dwc3: enable async suspend/resume
On Wed, Dec 18, 2013 at 04:09:34PM +0530, Yuvaraj Kumar C D wrote: From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3 device (the parent of xhci-plat) in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3 driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/core.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 59bb8d2..9c8a273 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -586,6 +586,8 @@ static int dwc3_probe(struct platform_device *pdev) pm_runtime_allow(dev); + device_enable_async_suspend(dev); how has this series been tested ? Let me rephrase this: was this series tested at all ? Note that if we are in gadget mode, we will disable physical endpoints 0 and 1, which will break USB communication requiring a new enumeration later. On top of that, for versions of the core which are configured without hibernation support - in fact for all cores currently, since we don't have hibernation support implemented in this driver -, we will loose communication with the far end (be it a host or a device). You mention there are no external dependencies to make async suspend work on this driver, but that's far from the truth. As it is today, this driver needs a lot of work to learn about all the details about all different versions of this IP when it comes to supporting async PM. I suppose this was tested with 500 other out-of-tree patches and you simply cherry-picked this patch to send upstream ? Am I right ? It certainly looks like it. Please let us know how has this been tested ? Did you run USB30CV ? Did you make sure to run through USB Certification interoperability tests ? Did you leave some stress test running for weeks before sending this patch out ? Is Exynos 5 working fine out of mainline ? cheers -- balbi signature.asc Description: Digital signature
[net PATCH v3 1/1] drivers: net : cpsw: pass proper device name while requesting irq
During checking the interrupts with cat /proc/interrupts, it is showing
device name as (null), this change was done with commit id aa1a15e2d where
request_irq is changed to devm_request_irq also changing the irq name from
platform device name to net device name, but the net device is not
registered at this point with the network frame work, so devm_request_irq
is called with device name as NULL, by which it is showed as (null) in
cat /proc/interrupts. So this patch changes back irq name to platform
device name itself in devm_request_irq so that the device name shows as
below.
Previous to this patch
root@am335x-evm:~# cat /proc/interrupts
CPU0
28: 2265 INTC 12 edma
30: 80 INTC 14 edma_error
56: 0 INTC 40 (null)
57: 1794 INTC 41 (null)
58: 7 INTC 42 (null)
59: 0 INTC 43 (null)
With this patch
root@am335x-evm:~# cat /proc/interrupts
CPU0
28:213 INTC 12 edma
30: 9 INTC 14 edma_error
56: 0 INTC 40 4a10.ethernet
57: 16097 INTC 41 4a10.ethernet
58: 11964 INTC 42 4a10.ethernet
59: 0 INTC 43 4a10.ethernet
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Changes from Initial version
* Changed the commit message to hold more details of the commit changes
Changes from v2
* Instead of moving request irq below net dev register, changing the
request irq name from net device to platform device as previous to
convertion to devm* is done.
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 614f284..5330fd2 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2108,7 +2108,7 @@ static int cpsw_probe(struct platform_device *pdev)
while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
for (i = res-start; i = res-end; i++) {
if (devm_request_irq(pdev-dev, i, cpsw_interrupt, 0,
-dev_name(priv-dev), priv)) {
+dev_name(pdev-dev), priv)) {
dev_err(priv-dev, error attaching irq\n);
goto clean_ale_ret;
}
--
1.8.5.2.192.g7794a68
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] usb: dwc3-exynos: enable async suspend/resume
On Wed, Dec 18, 2013 at 04:09:33PM +0530, Yuvaraj Kumar C D wrote: From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3-exynos platform device in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3-exynos driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..57431b7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -155,6 +155,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev) goto err2; } + device_enable_async_suspend(dev); sure that clk_disable() in your -suspend() callback will cause no issues at all ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] regulator: tps65910: Add backup battery regulator
On Wed, Dec 18, 2013 at 03:50:07PM +0100, Markus Pargmann wrote:
@@ -771,7 +794,7 @@ static struct regulator_ops tps65910_ops = {
.get_voltage_sel= tps65910_get_voltage_sel,
.set_voltage_sel= tps65910_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
- .map_voltage= regulator_map_voltage_ascend,
+ .map_voltage= regulator_map_voltage_iterate,
};
You should make separate ops for this rather than make all the other
regulators take the performance hit.
static struct regulator_ops tps65911_ops = {
@@ -944,6 +967,7 @@ static struct of_regulator_match tps65910_matches[] = {
{ .name = vaux2, .driver_data = (void *) tps65910_regs[10] },
{ .name = vaux33, .driver_data = (void *) tps65910_regs[11] },
{ .name = vmmc, .driver_data = (void *) tps65910_regs[12] },
+ { .name = vbb,.driver_data = (void *) tps65910_regs[13] },
};
Ugh, these numbered tables aren't good. Not a problem from this patch
though.
- pmic-desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
+ if (tps65910_chip_id(tps65910) == TPS65910
+ i == TPS65910_REG_VBB)
+ pmic-desc[i].enable_mask = BBCH_BBCHEN_MASK;
+ else
+ pmic-desc[i].enable_mask =
TPS65910_SUPPLY_STATE_ENABLED;
switch statements please - it means if additional things need
customising they can drop right in.
signature.asc
Description: Digital signature
Re: [PATCH 2/2] ARM: dts: tps65910 backup battery regulator
On Wed, Dec 18, 2013 at 03:50:08PM +0100, Markus Pargmann wrote: This patch adds a devicetree node for the backup battery regulator. Your previous patch missed an update to the binding documentation for the regulator driver. signature.asc Description: Digital signature
[PATCH 3/6] net: cpsw: Add control-module macid driver
This driver extracts the hardware macid from the control module of
am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw
to get the macid from within the processor.
This driver is not used, unless it is defined in DT and referenced by a
cpsw slave with a phandle.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
.../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 +
drivers/net/ethernet/ti/Kconfig| 8 ++
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 +
4 files changed, 178 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c
diff --git a/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
new file mode 100644
index 000..abff2af
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
@@ -0,0 +1,31 @@
+TI CPSW ctrl macid Devicetree bindings
+--
+
+Required properties:
+ - compatible : Should be ti,am3352-cpsw-ctrl-macid
+ - reg : physical base address and size of the cpsw
+ registers map
+ - reg-names : names of the register map given in reg node
+ - #ti,cpsw-ctrl-macid : Should be 1
+
+When used from cpsw, ti,mac-address-ctrl should be a phandle to this device
+node with one argument, 0 or 1 to select the macid 0 or 1.
+
+Examples:
+
+ cpsw_ctrl_macid: cpsw-ctrl-macid@44e10630 {
+ compatible = ti,am3352-cpsw-ctrl-macid;
+ #ti,mac-address-ctrl-cells = 1;
+ reg = 0x44e10630 0x16;
+ reg-names = ctrl-macid;
+ };
+
+Used in cpsw slave nodes like this:
+
+ cpsw_emac0: slave@4a100200 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 0;
+ };
+
+ cpsw_emac1: slave@4a100300 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 1;
+ };
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 53150c2..24819ef 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -56,12 +56,20 @@ config TI_CPSW_PHY_SEL
This driver supports configuring of the phy mode connected to
the CPSW.
+config TI_CPSW_CTRL_MACID
+ boolean TI CPSW internal MACID support
+ depends on TI_CPSW
+ ---help---
+ This driver supports reading the hardcoded MACID from am33xx
+ processors control module.
+
config TI_CPSW
tristate TI CPSW Switch Support
depends on ARM (ARCH_DAVINCI || SOC_AM33XX)
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
select TI_CPSW_PHY_SEL
+ select TI_CPSW_CTRL_MACID
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 9cfaab8..5a31c2b 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
+obj-$(CONFIG_TI_CPSW_CTRL_MACID) += cpsw-ctrl-macid.o
obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
diff --git a/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
new file mode 100644
index 000..e18c957
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
@@ -0,0 +1,138 @@
+/* CPSW Control Module MACID driver
+ *
+ * Copyright (C) 2013 Markus Pargmann m...@pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+
+#include cpsw.h
+
+#define AM33XX_CTRL_MAC_LO_REG(id) (0x8 * id)
+#define AM33XX_CTRL_MAC_HI_REG(id) (0x8 * id + 0x4)
+
+struct cpsw_ctrl_macid {
+ struct device *dev;
+ u8 __iomem *ctrl_macid;
+ void (*cpsw_macid_get)(struct cpsw_ctrl_macid *priv, int slave,
+ u8 *mac_addr);
+};
+
+
+static void cpsw_ctrl_get_macid(struct cpsw_ctrl_macid *priv, int slave,
+ u8 *mac_addr)
+{
+ u32 macid_lo;
+ u32 macid_hi;
+
+ macid_lo = readl(priv-ctrl_macid + AM33XX_CTRL_MAC_LO_REG(slave));
+ macid_hi = readl(priv-ctrl_macid +
[PATCH 2/6] net: cpsw: header, Add missing include
MII_BUS_ID_SIZE is defined in linux/phy.h which is not included in the
cpsw.h file.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/net/ethernet/ti/cpsw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index 574f49d..1b71067 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -15,6 +15,7 @@
#define __CPSW_H__
#include linux/if_ether.h
+#include linux/phy.h
struct cpsw_slave_data {
charphy_id[MII_BUS_ID_SIZE];
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] DT doc: net: cpsw mac-address is optional
mac-address is an optional property. If no mac-address is set, a random mac-address will be generated. Signed-off-by: Markus Pargmann m...@pengutronix.de --- Documentation/devicetree/bindings/net/cpsw.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 05d660e..c39f077 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -30,10 +30,10 @@ Required properties: - phy_id : Specifies slave phy id - phy-mode : The interface between the SoC and the PHY (a string that of_get_phy_mode() can understand) -- mac-address : Specifies slave MAC address Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports +- mac-address : Specifies slave MAC address Note: ti,hwmods field is used to fetch the base address and irq resources from TI, omap hwmod data base during device registration. -- 1.8.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] arm: dts: am335x beagle bone use processor macids
Use macids stored in the am335x chip.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/am335x-bone.dts | 8
arch/arm/boot/dts/am335x-boneblack.dts | 8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..9b65a62 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,14 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+cpsw_emac0 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 0;
+};
+
+cpsw_emac1 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 1;
+};
+
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..f6f0b40 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,14 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+cpsw_emac0 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 0;
+};
+
+cpsw_emac1 {
+ ti,mac-address-ctrl = cpsw_ctrl_macid 1;
+};
+
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] net: cpsw: Use cpsw-ctrl-macid driver
Use ctrl-macid driver to obtain the macids stored in the processor. This
is only done when defined in DT.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Documentation/devicetree/bindings/net/cpsw.txt | 5 +
drivers/net/ethernet/ti/cpsw.c | 18 ++
drivers/net/ethernet/ti/cpsw.h | 2 ++
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index c39f077..b95c38b 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -34,6 +34,11 @@ Required properties:
Optional properties:
- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
- mac-address : Specifies slave MAC address
+- ti,mac-address-ctrl : When cpsw-ctrl-macid support is compiledin, this can
+ be set to a phandle with one argument, see
+ cpsw-ctrl-macid.txt. If this method fails, cpsw falls
+ back to mac-address or random mac-address.
+
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 5120d9c..382d793 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1804,9 +1804,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
snprintf(slave_data-phy_id, sizeof(slave_data-phy_id),
PHY_ID_FMT, mdio-name, phyid);
- mac_addr = of_get_mac_address(slave_node);
- if (mac_addr)
- memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+ ret = cpsw_ctrl_macid_read(slave_node, slave_data-mac_addr);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ mac_addr = of_get_mac_address(slave_node);
+ if (mac_addr)
+ memcpy(slave_data-mac_addr, mac_addr,
+ ETH_ALEN);
+ }
slave_data-phy_if = of_get_phy_mode(slave_node);
@@ -1946,10 +1953,13 @@ static int cpsw_probe(struct platform_device *pdev)
/* Select default pin state */
pinctrl_pm_select_default_state(pdev-dev);
- if (cpsw_probe_dt(priv-data, pdev)) {
+ ret = cpsw_probe_dt(priv-data, pdev);
+ if (ret == -EINVAL) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
goto clean_runtime_disable_ret;
+ } else if (ret) {
+ goto clean_runtime_disable_ret;
}
data = priv-data;
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index 1b71067..222eebe 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -42,4 +42,6 @@ struct cpsw_platform_data {
void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
+int cpsw_ctrl_macid_read(struct device_node *np, u8 *mac_addr);
+
#endif /* __CPSW_H__ */
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] arm: dts: am33xx, Add device node for cpsw-ctrl-macid
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f6d8ffe..4e1bf08 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -676,6 +676,13 @@
reg= 0x44e10650 0x4;
reg-names = gmii-sel;
};
+
+ cpsw_ctrl_macid: cpsw-ctrl-macid@44e10630 {
+ compatible = ti,am3352-cpsw-ctrl-macid;
+ #ti,mac-address-ctrl-cells = 1;
+ reg = 0x44e10630 0x16;
+ reg-names = ctrl-macid;
+ };
};
ocmcram: ocmcram@4030 {
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
Hi, This series introduces a driver to read and use the MACIDs stored in the am335x control module. These are read-only registers for a unique MACID. At the moment the MACIDs are generated randomly or they are set by the bootloader. A device node is added in am33xx dtsi and used by the cpsw slaves in the bone board files. Regards, Markus Markus Pargmann (6): DT doc: net: cpsw mac-address is optional net: cpsw: header, Add missing include net: cpsw: Add control-module macid driver net: cpsw: Use cpsw-ctrl-macid driver arm: dts: am33xx, Add device node for cpsw-ctrl-macid arm: dts: am335x beagle bone use processor macids .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 + Documentation/devicetree/bindings/net/cpsw.txt | 7 +- arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-boneblack.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 7 ++ drivers/net/ethernet/ti/Kconfig| 8 ++ drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + drivers/net/ethernet/ti/cpsw.c | 18 ++- drivers/net/ethernet/ti/cpsw.h | 3 + 10 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c -- 1.8.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
Hi Nishanth,
On 17/12/2013 20:45, Nishanth Menon wrote:
On 12/09/2013 03:55 PM, Nishanth Menon wrote:
Craneboard is a hardware development platform based on the Sitara
AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
details. Add basic devices for craneboard as replacement for the board
file scheduled for removal as part of device tree conversion
[1] http://craneboard.org
Signed-off-by: Nishanth Menon n...@ti.com
---
gentle ping.. had'nt seen a response on this patch. Could we queue
this up for v3.14-rc1?
Yep, it looks good to me.
But if you don't mind I'll start pushing my branch after Xmas :-).
Thanks,
Benoit
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
branch: omap-for-v3.14/omap3-board-removal 736e812 ARM: OMAP2+: Remove unused
platform init code and headers
Bootlog: http://pastebin.mozilla.org/3744412
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/am3517-craneboard.dts | 174 +++
2 files changed, 175 insertions(+)
create mode 100644 arch/arm/boot/dts/am3517-craneboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fc37bca..ad155fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-boneblack.dtb \
am335x-nano.dtb \
am335x-base0033.dtb \
+ am3517-craneboard.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
diff --git a/arch/arm/boot/dts/am3517-craneboard.dts
b/arch/arm/boot/dts/am3517-craneboard.dts
new file mode 100644
index 000..2d40b3f
--- /dev/null
+++ b/arch/arm/boot/dts/am3517-craneboard.dts
@@ -0,0 +1,174 @@
+/*
+ * See craneboard.org for more details
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am3517.dtsi
+
+/ {
+ model = TI AM3517 CraneBoard (TMDSEVM3517);
+ compatible = ti,am3517-craneboard, ti,am3517, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000;/* 256 MB */
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-boot-on;
+ };
+};
+
+davinci_emac {
+ status = okay;
+};
+
+davinci_mdio {
+ status = okay;
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ tps: tps@2d {
+ reg = 0x2d;
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+i2c3 {
+ clock-frequency = 40;
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+mmc1 {
+ vmmc-supply = vdd2_reg;
+ bus-width = 8;
+};
+
+mmc2 {
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+mmc3 {
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+#include tps65910.dtsi
+
+omap3_pmx_core {
+ tps_pins: pinmux_tps_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
sys_nirq.sys_nirq */
+ ;
+ };
+};
+
+tps {
+ pinctrl-names = default;
+ pinctrl-0 = tps_pins;
+
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ ti,en-ck32k-xtal;
+
+ vcc1-supply = vbat;
+ vcc2-supply = vbat;
+ vcc3-supply = vbat;
+ vcc4-supply = vbat;
+ vcc5-supply = vbat;
+ vcc6-supply = vbat;
+ vcc7-supply = vbat;
+ vccio-supply = vbat;
+
+ regulators {
+ vrtc_reg: regulator@0 {
+ regulator-always-on;
+ };
+
+ vio_reg: regulator@1 {
+ regulator-always-on;
+ };
+
+ /*
+* Unused:
+* VDIG1=2.7V,300mA max
+* VDIG2=1.8V,300mA max
+*/
+
+ vpll_reg: regulator@7 {
+ /* VDDS_DPLL_1V8 */
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ vaux1_reg: regulator@9 {
+ /* VDDS_SRAM_1V8 */
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ vaux2_reg: regulator@10 {
+ /* VDDA1P8V_USBPHY */
+
Re: [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote: Hi, This series introduces a driver to read and use the MACIDs stored in the am335x control module. These are read-only registers for a unique MACID. At the moment the MACIDs are generated randomly or they are set by the bootloader. A device node is added in am33xx dtsi and used by the cpsw slaves in the bone board files. Regards, Markus Markus Pargmann (6): DT doc: net: cpsw mac-address is optional net: cpsw: header, Add missing include net: cpsw: Add control-module macid driver net: cpsw: Use cpsw-ctrl-macid driver arm: dts: am33xx, Add device node for cpsw-ctrl-macid arm: dts: am335x beagle bone use processor macids .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 + Documentation/devicetree/bindings/net/cpsw.txt | 7 +- arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-boneblack.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 7 ++ drivers/net/ethernet/ti/Kconfig| 8 ++ drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + drivers/net/ethernet/ti/cpsw.c | 18 ++- drivers/net/ethernet/ti/cpsw.h | 3 + 10 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c Mac ID is to be filled by U-Boot and this kind of approach is already rejected in linux-omap list. If proper ethaddr/eth*addr is populated in U-boot environment variable then mac-address dt property in ethernet* device nodes will be populated before boot kernel in U-boot. So I don't think this patch series is required. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
On 12/18/2013 10:57 AM, Benoit Cousson wrote: On 17/12/2013 20:45, Nishanth Menon wrote: On 12/09/2013 03:55 PM, Nishanth Menon wrote: Craneboard is a hardware development platform based on the Sitara AM3517 ARM Cortex - A8 microprocessor device - see [1] for more details. Add basic devices for craneboard as replacement for the board file scheduled for removal as part of device tree conversion [1] http://craneboard.org Signed-off-by: Nishanth Menon n...@ti.com --- gentle ping.. had'nt seen a response on this patch. Could we queue this up for v3.14-rc1? Yep, it looks good to me. Thanks benoit. But if you don't mind I'll start pushing my branch after Xmas :-). As long as Tony is ok with it, I have no issues either - will be great to have dt only boot in .14-rc1 though. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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/6] net: cpsw: Support for am335x chip MACIDs
On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote: On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote: Hi, This series introduces a driver to read and use the MACIDs stored in the am335x control module. These are read-only registers for a unique MACID. At the moment the MACIDs are generated randomly or they are set by the bootloader. A device node is added in am33xx dtsi and used by the cpsw slaves in the bone board files. Regards, Markus Markus Pargmann (6): DT doc: net: cpsw mac-address is optional net: cpsw: header, Add missing include net: cpsw: Add control-module macid driver net: cpsw: Use cpsw-ctrl-macid driver arm: dts: am33xx, Add device node for cpsw-ctrl-macid arm: dts: am335x beagle bone use processor macids .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 + Documentation/devicetree/bindings/net/cpsw.txt | 7 +- arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-boneblack.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 7 ++ drivers/net/ethernet/ti/Kconfig| 8 ++ drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + drivers/net/ethernet/ti/cpsw.c | 18 ++- drivers/net/ethernet/ti/cpsw.h | 3 + 10 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c Mac ID is to be filled by U-Boot and this kind of approach is already rejected in linux-omap list. If proper ethaddr/eth*addr is populated in U-boot environment variable then mac-address dt property in ethernet* device nodes will be populated before boot kernel in U-boot. So I don't think this patch series is required. but will u-boot read MACID from control module ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote: On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote: On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote: Hi, This series introduces a driver to read and use the MACIDs stored in the am335x control module. These are read-only registers for a unique MACID. At the moment the MACIDs are generated randomly or they are set by the bootloader. A device node is added in am33xx dtsi and used by the cpsw slaves in the bone board files. Regards, Markus Markus Pargmann (6): DT doc: net: cpsw mac-address is optional net: cpsw: header, Add missing include net: cpsw: Add control-module macid driver net: cpsw: Use cpsw-ctrl-macid driver arm: dts: am33xx, Add device node for cpsw-ctrl-macid arm: dts: am335x beagle bone use processor macids .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 + Documentation/devicetree/bindings/net/cpsw.txt | 7 +- arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-boneblack.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 7 ++ drivers/net/ethernet/ti/Kconfig| 8 ++ drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + drivers/net/ethernet/ti/cpsw.c | 18 ++- drivers/net/ethernet/ti/cpsw.h | 3 + 10 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c Mac ID is to be filled by U-Boot and this kind of approach is already rejected in linux-omap list. If proper ethaddr/eth*addr is populated in U-boot environment variable then mac-address dt property in ethernet* device nodes will be populated before boot kernel in U-boot. So I don't think this patch series is required. but will u-boot read MACID from control module ? Yes, U-Boot will read the MACID from control module and if a customer wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must be updated. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote: On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote: On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote: On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote: Hi, This series introduces a driver to read and use the MACIDs stored in the am335x control module. These are read-only registers for a unique MACID. At the moment the MACIDs are generated randomly or they are set by the bootloader. A device node is added in am33xx dtsi and used by the cpsw slaves in the bone board files. Regards, Markus Markus Pargmann (6): DT doc: net: cpsw mac-address is optional net: cpsw: header, Add missing include net: cpsw: Add control-module macid driver net: cpsw: Use cpsw-ctrl-macid driver arm: dts: am33xx, Add device node for cpsw-ctrl-macid arm: dts: am335x beagle bone use processor macids .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 31 + Documentation/devicetree/bindings/net/cpsw.txt | 7 +- arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-boneblack.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 7 ++ drivers/net/ethernet/ti/Kconfig| 8 ++ drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + drivers/net/ethernet/ti/cpsw.c | 18 ++- drivers/net/ethernet/ti/cpsw.h | 3 + 10 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c Mac ID is to be filled by U-Boot and this kind of approach is already rejected in linux-omap list. If proper ethaddr/eth*addr is populated in U-boot environment variable then mac-address dt property in ethernet* device nodes will be populated before boot kernel in U-boot. So I don't think this patch series is required. but will u-boot read MACID from control module ? Yes, U-Boot will read the MACID from control module and if a customer wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must be updated. cool, then I agree this series shouldn't be applied ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
On 18/12/2013 18:02, Nishanth Menon wrote: On 12/18/2013 10:57 AM, Benoit Cousson wrote: On 17/12/2013 20:45, Nishanth Menon wrote: On 12/09/2013 03:55 PM, Nishanth Menon wrote: Craneboard is a hardware development platform based on the Sitara AM3517 ARM Cortex - A8 microprocessor device - see [1] for more details. Add basic devices for craneboard as replacement for the board file scheduled for removal as part of device tree conversion [1] http://craneboard.org Signed-off-by: Nishanth Menon n...@ti.com --- gentle ping.. had'nt seen a response on this patch. Could we queue this up for v3.14-rc1? Yep, it looks good to me. Thanks benoit. But if you don't mind I'll start pushing my branch after Xmas :-). As long as Tony is ok with it, I have no issues either - will be great to have dt only boot in .14-rc1 though. Good point, it is already -rc4. OK, I'll just queued it and pushed it to for_3.14/dts. Regards, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.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: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
* Tomi Valkeinen tomi.valkei...@ti.com [131217 23:14]: On 2013-12-17 17:30, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131216 22:47]: On 2013-12-16 20:41, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]: As a temporary solution to enable DSS for selected boards when booting with DT, a hack was added to board-generic.c in 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable DSS for panda sdp boards). We're now adding proper DT support, so the hack can be removed. I guess this patch should be merged later on after we have the DT support working? I'll move this patch also to the end of the series. Merged later sounds like you mean this could be merged in a separate series. I think this and the other removal can be in this series, they just need to be at the end. Well yeah let's keep those separate still as at least Russell needed some more time with the legacy booting. The point we can drop the legacy booting for omap3 may still need to wait a bit, maybe even until v3.15 to keep things working. They can't be separate. Once I add DT support for a board, I have to remove the legacy support for that board. This patch removes legacy support for the boards that are converted in the series. Oh OK yeah makes sense. I was worried about the legacy board-*.c files.. If I don't remove the legacy support, both DT and legacy side will be ran, and both create the DSS devices... But, it's true that this patch removes the whole file, as all the boards currently there are converted. But if new boards are added to the DSS quirks, then I can't remove the file. So I'll change this patch to only remove the parts for the converted boards, not the whole file. OK But but... If I understand right, the plan is to remove all omap3 board files for the next merge window. I'm not totally familiar with the quirks system, but how should this be handled: omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices are created via DT code. But if the display (i.e. panels) for a particular omap3 board has not been converted to DT, we should still use the legacy DSS initialization. But the DSS is already initialized via DT. I guess I can set the status for all the DSS nodes to disabled in omap3.dtsi, and that should prevent DT code from creating the DSS devices. Then, each omap3-board.dts that has been converted to DSS DT, can override those to enabled. That way the DT code should not create DSS devices by default, and the quirks system would probably work fine. No need for DSS related quirks for the DT boot case. I was concerned about the legacy board-*.c case. 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: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
* Tomi Valkeinen tomi.valkei...@ti.com [131218 02:22]: On 2013-12-18 09:12, Tomi Valkeinen wrote: Well yeah let's keep those separate still as at least Russell needed some more time with the legacy booting. The point we can drop the legacy booting for omap3 may still need to wait a bit, maybe even until v3.15 to keep things working. They can't be separate. Once I add DT support for a board, I have to remove the legacy support for that board. This patch removes legacy support for the boards that are converted in the series. If I don't remove the legacy support, both DT and legacy side will be ran, and both create the DSS devices... But, it's true that this patch removes the whole file, as all the boards currently there are converted. But if new boards are added to the DSS quirks, then I can't remove the file. So I'll change this patch to only remove the parts for the converted boards, not the whole file. But but... If I understand right, the plan is to remove all omap3 board files for the next merge window. I'm not totally familiar with the quirks system, but how should this be handled: omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices are created via DT code. But if the display (i.e. panels) for a particular omap3 board has not been converted to DT, we should still use the legacy DSS initialization. But the DSS is already initialized via DT. I guess I can set the status for all the DSS nodes to disabled in omap3.dtsi, and that should prevent DT code from creating the DSS devices. Then, each omap3-board.dts that has been converted to DSS DT, can override those to enabled. That way the DT code should not create DSS devices by default, and the quirks system would probably work fine. I changed the DSS DT nodes to be disabled by default, and I think this works nicely. It's actually better this way in any case, as we can leave blocks like DSI out for boards that don't need it. Also, I now remove the quirks only for the boards that are converted to DT, not the whole dss-common.c file. So I think we can now add new boards to dss-common.c, if and when there are ones that cannot be converted to use DSS DT yet. OK 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] Add more device nodes for am43x gp evm.
Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Ping on this? -- To unsubscribe from this list: send the line unsubscribe 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/5] Add more device nodes for am43x-epos-evm
Benoit, On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote: The patch series adds support for enabling pwm backlight, i2c2, spi and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) [1]: https://patchwork.kernel.org/patch/3009541/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this temporary patch[2]. [2]: http://www.spinics.net/lists/arm-kernel/msg288215.html Darren Etheridge (1): pinctrl: am43xx: dt-bindings: add MUX_MODE8 Sourav Poddar (4): arm: dts: am4372: Add pwm-cellsproperty for ecap device. arm: dts: am43x-epos-evm: Add I2C data. arm: dts: am43x-epos-evm: Add SPI data. ARM: dts: am43x-epos-evm: Add pwm backlight support. arch/arm/boot/dts/am4372.dtsi|9 + arch/arm/boot/dts/am43x-epos-evm.dts | 67 ++ include/dt-bindings/pinctrl/am43xx.h |1 + 3 files changed, 77 insertions(+), 0 deletions(-) Ping on this? -- To unsubscribe from this list: send the line unsubscribe 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] Add more device nodes for am43x gp evm.
Hi Sourav, On 18/12/2013 18:43, Sourav Poddar wrote: Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Ping on this? The series looks good, but you should rebase it on top of for_3.14/dts that is based on the big cleanup branch Tony has done. I cannot apply it right now. Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.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
[GIT PULL] omap display regression fix against v3.13-rc4
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d: Linux 3.13-rc4 (2013-12-15 12:31:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/display-fix for you to fetch changes up to 130f769e81fc472beb2211320777e26050e3fa15: Revert ARM: OMAP2+: Remove legacy mux code for display.c (2013-12-17 16:28:34 -0800) I accidentally removed some mux code for omap4 that I thought was dead code as omap4 has been booting with device tree only since v3.10. Turns out I also removed some display related mux code, so let's revert that except for the dead code parts. Tomi Valkeinen (1): Revert ARM: OMAP2+: Remove legacy mux code for display.c arch/arm/mach-omap2/display.c | 38 ++ 1 file changed, 38 insertions(+) -- To unsubscribe from this list: send the line unsubscribe 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] Add more device nodes for am43x gp evm.
On Wednesday 18 December 2013 11:19 PM, Benoit Cousson wrote: Hi Sourav, On 18/12/2013 18:43, Sourav Poddar wrote: Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Ping on this? The series looks good, but you should rebase it on top of for_3.14/dts that is based on the big cleanup branch Tony has done. I cannot apply it right now. Ok. I will rebase it and send you the series, As you can see there is one dependency on afzal basic support patch, as mentioned in the cover letter. If you are ok with that patch, it has to go first. So, if you wish I can work with afzal and send you this series and afzal patch together. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Tomi Valkeinen tomi.valkei...@ti.com [131218 05:56]: On 2013-12-18 14:00, Russell King - ARM Linux wrote: So, here goes. LDP3430: OMAP DSS rev 2.0 omapdss DPI error: can't get VDDS_DSI regulator omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral I don't see evidence of it being re-probed, but I do see this during boot which implies that there's nothing there: XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I don't have an LDP board at hand, and I wasn't able to find out anything from the logs. I think I should change omapfb to print something if it's probed succesfully, as the deferred probing makes finding out if something is probed fine or not quite murky. Without deferred probing, it was simpler: no errors - the driver must be (most likely) ok. Although... In an earlier log, where there was no panel driver, the log has these errors: Error opening /dev/fb0: No such device There are none in the latest log, which makes me guess the omapfb has been probed, and fb0 is actually there. But the X is still dying for some reason... I'll look at this more. Maybe someone in our team can find a board to test. Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio output) using this pdata quirks patch: [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it AFAIK the pdata hack above should not be needed now, but I have not tried with Tomi's DSS DT patches yet. Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I could try at some point? Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar from your kernel cmdline? For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: Those particular LCDs are supposed to be updated manually using custom ioctl, so normal software using fb won't put anything on the display. For testing purposes, a SW based automatic update (~20 fps) can be enabled by kernel cmdline parameter omapfb.auto_update or via sysfs: echo 1 /sys/class/graphics/fb0/update_mode OMAP DSS rev 4.0 omapdss DSI error: can't get VDDS_DSI regulator panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral ... omapdss DSI error: failed to set complexio power state to 1 panel-dsi-cm panel-dsi-cm.0: failed to enable DSI omapfb omapfb: Failed to enable display 'lcd' omapfb omapfb: failed to initialize default display omapfb omapfb: failed to setup omapfb Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux code for display.c) was overly enthusiastic in removing legacy code which was already in use. Tony has a partial revert for that queued up. It can also be reverted fully for testing. After that, the panel wakes up. Yes sorry for accidentally removing some extra code there, I just sent a pull request for the fix. My 4430 SDP is face down in the rack because of the way the Ethernet connector plugs in.. 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] Add more device nodes for am43x gp evm.
On 18/12/2013 19:15, Sourav Poddar wrote: On Wednesday 18 December 2013 11:19 PM, Benoit Cousson wrote: Hi Sourav, On 18/12/2013 18:43, Sourav Poddar wrote: Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Ping on this? The series looks good, but you should rebase it on top of for_3.14/dts that is based on the big cleanup branch Tony has done. I cannot apply it right now. Ok. I will rebase it and send you the series, As you can see there is one dependency on afzal basic support patch, as mentioned in the cover letter. If you are ok with that patch, it has to go first. So, if you wish I can work with afzal and send you this series and afzal patch together. Yes, go ahead and repost the whole series with the depency. BTW, could you do that as well with your other series? Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.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] ARM: dts: Add support for sbc-3xxx with cm-t3730
* Igor Grinberg grinb...@compulab.co.il [131218 00:47]:
Acked-by: Igor Grinberg grinb...@compulab.co.il
This one looks great!
Really minor comments below (we can fix those later)
Updated patch below, then signing it off to you guys :)
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
[...]
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
vsim is not present in TPS65930...
can be just left empty or set to a fixed voltage regulator.
Oops right if the pins 4 - 8 are not connected, no aux regulator
is needed.
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
[...]
+i2c1 {
+ clock-frequency = 260;
There is also an EEPROM on this bus, although we still don't
have it registered in the dts, but it can be registered from
userspace and is also accessible using i2c-tools.
This should be 400KHz max for the EEPROM to work.
OK updated that too below.
I've kept your Ack as the changes were minor. If no other
comments, I will apply this into omap-for-v3.14/dt probably
on Thursday.
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Wed, 18 Dec 2013 13:13:21 -0800
Subject: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
This adds support for CompuLab SBC-T3530, also known as cm-t3730:
http://compulab.co.il/products/sbcs/sbc-t3530/
It seems that with the sbc-3xxx mainboard is also used on
SBC-T3517 and SBC-T3730 with just a different CPU module:
http://compulab.co.il/products/sbcs/sbc-t3517/
http://compulab.co.il/products/sbcs/sbc-t3730/
So let's add a common omap3-sb-t35.dtsi and then separate SoC
specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
omap3-sbc-t3517.dts.
I've tested this with SBC-T3730 as that's the only one I have.
At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
work.
Note that WLAN seems to be different for SBC-T3530. And SBC-T3517
may need some changes for the EMAC Ethernet if that's used
instead of the smsc911x.
Cc: devicet...@vger.kernel.org
Cc: Mike Rapoport m...@compulab.co.il
Acked-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fc37bca..b7af502 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -179,6 +179,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap2420-n810-wimax.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
+ omap3-cm-t3730.dtb \
+ omap3-sbc-t3730.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
b/arch/arm/boot/dts/omap3-cm-t3730.dts
new file mode 100644
index 000..486f4d6
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -0,0 +1,104 @@
+/*
+ * Support for CompuLab CM-T3730
+ */
+/dts-v1/;
+
+#include omap36xx.dtsi
+#include omap3-cm-t3x30.dtsi
+
+/ {
+ model = CompuLab CM-T3730;
+ compatible = compulab,omap3-cm-t3730, ti,omap36xx, ti,omap3;
+
+ wl12xx_vmmc2: wl12xx_vmmc2 {
+ compatible = regulator-fixed;
+ regulator-name = vw1271;
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio3 9 GPIO_ACTIVE_HIGH; /* gpio73 */
+ startup-delay-us = 2;
+ enable-active-high;
+ };
+
+ wl12xx_vaux2: wl12xx_vaux2 {
+ compatible = regulator-fixed;
+ regulator-name = vwl1271_vaux2;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ vin-supply = vaux2;
+ };
+};
+
+omap3_pmx_core {
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
+ 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_cmd.sdmmc1_cmd */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
+ 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
+ 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
+ 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ ;
+ };
+
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat0.sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat1.sdmmc2_dat1 */
+ 0x130
Re: [PATCH 1/1] drivers: net cpsw: Enable In Band mode in cpsw for 10 mbps
From: Mugunthan V N mugunthan...@ti.com Date: Fri, 13 Dec 2013 18:42:55 +0530 This patch adds support for enabling In Band mode in 10 mbps speed. RGMII supports 1 Gig and 100 mbps mode for Forced mode of operation. For 10mbps mode it should be configured to in band mode so that link status, duplexity and speed are determined from the RGMII input data stream Signed-off-by: Mugunthan V N mugunthan...@ti.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe 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/4] OMAPDSS: DT support for N900 panel
On Tue, Dec 17, 2013 at 07:29:34PM +0200, Tomi Valkeinen wrote: I added N900 display DT support on top of my v2 series, including pinmuxing. Can you check if it looks right and works? git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt I just tried it and it does not work. On a first look the pinmuxing looks fishy: 0x0d4 is muxed two times. Hmm, so it is. I'm not really familiar with SDI, I just muxed all the SDI pins, except datapair3. I previously thought that there's only the data and clock pairs for SDI, but the TRM revealed more sdi pins, so I included them. It is well possible that these can be removed: 0x0d0 (PIN_OUTPUT | MUX_MODE1) /* dss_data18.sdi_vsync */ 0x0d2 (PIN_OUTPUT | MUX_MODE1) /* dss_data19.sdi_hsync */ 0x0d4 (PIN_OUTPUT | MUX_MODE1) /* dss_data20.sdi_den */ 0x0d6 (PIN_OUTPUT | MUX_MODE1) /* dss_data21.sdi_stp */ Just removing the dss_data20.sdi_den pin was enough to get a working display. I don't know if the other pins are needed, because the display pins are already muxed correctly by the bootloader. -- Sebastian diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 39e5e50..33f29ac 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -163,7 +163,7 @@ 0x0d0 (PIN_OUTPUT | MUX_MODE1) /* dss_data18.sdi_vsync */ 0x0d2 (PIN_OUTPUT | MUX_MODE1) /* dss_data19.sdi_hsync */ - 0x0d4 (PIN_OUTPUT | MUX_MODE1) /* dss_data20.sdi_den */ + //0x0d4 (PIN_OUTPUT | MUX_MODE1) /* dss_data20.sdi_den */ 0x0d6 (PIN_OUTPUT | MUX_MODE1) /* dss_data21.sdi_stp */ 0x0d8 (PIN_OUTPUT | MUX_MODE1) /* dss_data22.sdi_clkp */ 0x0da (PIN_OUTPUT | MUX_MODE1) /* dss_data23.sdi_clkn */ signature.asc Description: Digital signature
Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote: From: Andreas Naumann anaum...@ultratronik.de This is a hard to reproduce problem which leads to non-functional USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore of OTG_INTERFSEL over suspend. Since the resume function is also called early in driver init, it uses a non-initialized value (which is 0 and a non-supported setting in DM37xx for INTERFSEL). Shortly after the correct value is set. Apparently this works most time, but not always. yeah, but the problem is not on the glue layer. The bug is omap_device and pm_runtime not agreeing on device's state. I suppose there was a fix for that recently in linux-omap@vger mailing list. You mean this: http://marc.info/?t=13844488263r=1w=2 ? This looks like a different issue during suspend, this problem is at startup. Both musb_core and omap2430.c expect hardware to be disabled on startup, and that works as expected. The problem is on first pm_runtime_get_sync(), which results in first runtime_resume() call, musb_core checks for first resume and doesn't load yet-unset context in that case, however glue does and breaks things. We have this problem since 3.2. Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel
On Wed, Dec 18, 2013 at 10:55:37PM +0100, Sebastian Reichel wrote:
On Tue, Dec 17, 2013 at 07:29:34PM +0200, Tomi Valkeinen wrote:
I added N900 display DT support on top of my v2 series, including
pinmuxing. Can you check if it looks right and works?
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
I just tried it and it does not work. On a first look the pinmuxing
looks fishy: 0x0d4 is muxed two times.
Hmm, so it is.
I'm not really familiar with SDI, I just muxed all the SDI pins, except
datapair3. I previously thought that there's only the data and clock
pairs for SDI, but the TRM revealed more sdi pins, so I included them.
It is well possible that these can be removed:
0x0d0 (PIN_OUTPUT | MUX_MODE1) /* dss_data18.sdi_vsync */
0x0d2 (PIN_OUTPUT | MUX_MODE1) /* dss_data19.sdi_hsync */
0x0d4 (PIN_OUTPUT | MUX_MODE1) /* dss_data20.sdi_den */
0x0d6 (PIN_OUTPUT | MUX_MODE1) /* dss_data21.sdi_stp */
Just removing the dss_data20.sdi_den pin was enough to get a working display.
I
don't know if the other pins are needed, because the display pins are already
muxed correctly by the bootloader.
I just had a look in the leaked n900 schematics. According to it the
following pins are connected to the display:
DSS_DATA20 (E28) GPIO 90 LCD_RST
DSS_DATA10 (AD28)SDI_DAT1N CDP 0
DSS_DATA11 (AD27)SDI_DAT1P CDP 1
DSS_DATA12 (AB28)SDI_DAT2N CDP 2
DSS_DATA13 (AB27)SDI_DAT2P CDP 3
DSS_DATA14 (AA28)SDI_DAT3N CDP 4
DSS_DATA15 (AA27)SDI_DAT3P CDP 5
DSS_DATA22 (AC27)SDI_CLKPCDP 6
DSS_DATA23 (AC28)SDI_CLKNCDP 7
I also noticed that dss_data19.sdi_hsync is used as gpio 89 for the
N900's proximity sensor. Thus I suggest the following SDI pin muxing:
dss_sdi_pins: pinmux_dss_sdi_pins {
pinctrl-single,pins =
0x0c0 (PIN_OUTPUT | MUX_MODE1) /*
dss_data10.sdi_dat1n */
0x0c2 (PIN_OUTPUT | MUX_MODE1) /*
dss_data11.sdi_dat1p */
0x0c4 (PIN_OUTPUT | MUX_MODE1) /*
dss_data12.sdi_dat2n */
0x0c6 (PIN_OUTPUT | MUX_MODE1) /*
dss_data13.sdi_dat2p */
0x0c8 (PIN_OUTPUT | MUX_MODE1) /*
dss_data14.sdi_dat3n */
0x0ca (PIN_OUTPUT | MUX_MODE1) /*
dss_data15.sdi_dat3p */
0x0d8 (PIN_OUTPUT | MUX_MODE1) /* dss_data22.sdi_clkp
*/
0x0da (PIN_OUTPUT | MUX_MODE1) /* dss_data23.sdi_clkn
*/
;
};
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH 0/3] Add more device nodes for am43x gp evm.
On Thursday 19 December 2013 12:21 AM, Benoit Cousson wrote: On 18/12/2013 19:15, Sourav Poddar wrote: On Wednesday 18 December 2013 11:19 PM, Benoit Cousson wrote: Hi Sourav, On 18/12/2013 18:43, Sourav Poddar wrote: Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Ping on this? The series looks good, but you should rebase it on top of for_3.14/dts that is based on the big cleanup branch Tony has done. I cannot apply it right now. Ok. I will rebase it and send you the series, As you can see there is one dependency on afzal basic support patch, as mentioned in the cover letter. If you are ok with that patch, it has to go first. So, if you wish I can work with afzal and send you this series and afzal patch together. Yes, go ahead and repost the whole series with the depency. BTW, could you do that as well with your other series? Yes, I will do that. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-18 20:23, Tony Lindgren wrote: Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio output) using this pdata quirks patch: [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it AFAIK the pdata hack above should not be needed now, but I have not tried with Tomi's DSS DT patches yet. Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I could try at some point? Hmm, I thought this was about legacy booting on v3.14-rc4. That still uses the board files for omap3. Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar from your kernel cmdline? Nothing like that should be required for normal operation. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel
On 2013-12-19 02:51, Sebastian Reichel wrote:
On Wed, Dec 18, 2013 at 10:55:37PM +0100, Sebastian Reichel wrote:
On Tue, Dec 17, 2013 at 07:29:34PM +0200, Tomi Valkeinen wrote:
I added N900 display DT support on top of my v2 series, including
pinmuxing. Can you check if it looks right and works?
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
I just tried it and it does not work. On a first look the pinmuxing
looks fishy: 0x0d4 is muxed two times.
Hmm, so it is.
I'm not really familiar with SDI, I just muxed all the SDI pins, except
datapair3. I previously thought that there's only the data and clock
pairs for SDI, but the TRM revealed more sdi pins, so I included them.
It is well possible that these can be removed:
0x0d0 (PIN_OUTPUT | MUX_MODE1) /* dss_data18.sdi_vsync */
0x0d2 (PIN_OUTPUT | MUX_MODE1) /* dss_data19.sdi_hsync */
0x0d4 (PIN_OUTPUT | MUX_MODE1) /* dss_data20.sdi_den */
0x0d6 (PIN_OUTPUT | MUX_MODE1) /* dss_data21.sdi_stp */
Just removing the dss_data20.sdi_den pin was enough to get a working
display. I
don't know if the other pins are needed, because the display pins are already
muxed correctly by the bootloader.
I just had a look in the leaked n900 schematics. According to it the
following pins are connected to the display:
DSS_DATA20 (E28) GPIO 90 LCD_RST
DSS_DATA10 (AD28)SDI_DAT1N CDP 0
DSS_DATA11 (AD27)SDI_DAT1P CDP 1
DSS_DATA12 (AB28)SDI_DAT2N CDP 2
DSS_DATA13 (AB27)SDI_DAT2P CDP 3
DSS_DATA14 (AA28)SDI_DAT3N CDP 4
DSS_DATA15 (AA27)SDI_DAT3P CDP 5
DSS_DATA22 (AC27)SDI_CLKPCDP 6
DSS_DATA23 (AC28)SDI_CLKNCDP 7
I also noticed that dss_data19.sdi_hsync is used as gpio 89 for the
N900's proximity sensor. Thus I suggest the following SDI pin muxing:
dss_sdi_pins: pinmux_dss_sdi_pins {
pinctrl-single,pins =
0x0c0 (PIN_OUTPUT | MUX_MODE1) /*
dss_data10.sdi_dat1n */
0x0c2 (PIN_OUTPUT | MUX_MODE1) /*
dss_data11.sdi_dat1p */
0x0c4 (PIN_OUTPUT | MUX_MODE1) /*
dss_data12.sdi_dat2n */
0x0c6 (PIN_OUTPUT | MUX_MODE1) /*
dss_data13.sdi_dat2p */
0x0c8 (PIN_OUTPUT | MUX_MODE1) /*
dss_data14.sdi_dat3n */
0x0ca (PIN_OUTPUT | MUX_MODE1) /*
dss_data15.sdi_dat3p */
0x0d8 (PIN_OUTPUT | MUX_MODE1) /* dss_data22.sdi_clkp
*/
0x0da (PIN_OUTPUT | MUX_MODE1) /* dss_data23.sdi_clkn
*/
;
};
Thanks, I'll do the modifications. The dat3 lines are not needed, but if
they're connected to the panel, I don't see any harm in muxing them.
Although, makes me wonder. If the panel supports only 2 datalanes, why
does it have connectors for 3? And if it supports 3, why would N900 use
only 2?
Are you able to check if the bootloader muxes dat3 to SDI mode?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
On 12/18/13 23:16, Tony Lindgren wrote: [...] I've kept your Ack as the changes were minor. If no other comments, I will apply this into omap-for-v3.14/dt probably on Thursday. Looks great! Thanks! -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
