[PATCH] ARM: OMAP2+: Remove legacy macros for zoom platforms
Commit 97411608fd5f (ARM: OMAP2+: Remove legacy support for zoom
platforms) removed the Kconfig symbols MACH_OMAP_ZOOM2 and
MACH_OMAP_ZOOM3. Remove the last usage of the related macros too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, but should have zero impact.
arch/arm/mach-omap2/io.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d408b15..af432b1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -179,15 +179,6 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.length = L4_EMU_34XX_SIZE,
.type = MT_DEVICE
},
-#if defined(CONFIG_DEBUG_LL)
\
- (defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3))
- {
- .virtual= ZOOM_UART_VIRT,
- .pfn= __phys_to_pfn(ZOOM_UART_BASE),
- .length = SZ_1M,
- .type = MT_DEVICE
- },
-#endif
};
#endif
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
On Wednesday 29 January 2014 08:17 PM, Heikki Krogerus wrote: Hi, On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote: On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote: On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: For the controller drivers the PHYs are just a resource like any other. The controller drivers can't have any responsibility of them. They should not care if PHY drivers are available for them or not, or even if the PHY framework is available or not. huh? If memory isn't available you don't continue probing, right ? If your IORESOURCE_MEM is missing, you also don't continue probing, if your IRQ line is missing, you bail too. Those are also nothing but resources to the driver, what you're asking here is to treat PHY as a _different_ resource; which might be fine, but we need to make sure we don't continue probing when a PHY is missing in a platform that certainly needs a PHY. Yes, true. In my head I was comparing the PHY only to resources like gpios, clocks, dma channels, etc. that are often optional to the drivers. But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. that's different from what I heard. I don't know where you got that impression, but it's not true. The Baytrail SoCs for example don't have internal USB PHYs, which means the manufacturers using it can select what they want. So we have boards where PHY driver(s) is needed and boards where it isn't. alright, that explains it ;-) So you have external USB2 and USB3 PHYs ? You have an external PIPE3 interface ? That's quite an achievement, kudos to your HW designers. Getting timing closure on PIPE3 is a difficult task. No, only the USB2 PHY is external. I'm giving you wrong information, I'm sorry about that. Need to concentrate on what I'm writing. snip This is really good to get. We have some projects where we are dealing with more embedded environments, like IVI, where the kernel should be stripped of everything useless. Since the PHYs are autonomous, we should be able to disable the PHY libraries/frameworks. hmmm, in that case it's a lot easier to treat. We can use ERR_PTR(-ENXIO) as an indication that the framework is disabled, or something like that. The difficult is really reliably supporting e.g. OMAP5 (which won't work without a PHY) and your BayTrail with autonomous PHYs. What can we use as an indication ? OMAP has it's own glue driver, so shouldn't it depend on the PHY layer? right, but the PHY is connected to the dwc3 core and not to the glue. I mean, I need to know that a particular platform depends on a PHY driver before I decide to return -EPROBE_DEFER or just assume the PHY isn't needed ;-) I don't think dwc3 (core) should care about that. The PHY layer needs to tell us that. If the PHY driver that the platform depends is not available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up returning -EPROBE_DEFER. I don't think the PHY layer can 'reliably' tell if PHY driver is available or not. Consider when the phy_provider_register fails, there is no way to know if PHY driver is available or not. There are a few cases where PHY layer returns -EPROBE_DEFER but none of them can tell for sure that PHY driver is either available and failed or not available at all. It would be best for us to leave that to the platforms if we want to be sure if the platform needs a PHY or not. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Cash Awaiting Pick Up..
This is to re-notify you that you have $500,000.00 waiting for pick-up at Money Gram, Contact Mrs Hillary Florence via email : heritd...@xtra.co.nz for claims. -- To unsubscribe from this list: send the line unsubscribe 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 v7 10/12] ARM: OMAP2+: Remove legacy_init_ehci_clk()
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..f1ecd86 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -31,20 +31,6 @@ struct pdata_init {
struct of_dev_auxdata omap_auxdata_lookup[];
static struct twl4030_gpio_platform_data twl_gpio_auxdata;
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias(main_clk, NULL, clkname, NULL);
- if (ret)
- pr_err(%s:Failed to add main_clk alias to %s :%d\n,
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -182,7 +168,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -190,7 +175,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk(auxclk1_ck);
}
#endif
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 12/12] usb: omap: dts: Update DT binding example usage
Remove non-compatible id from examples.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/ehci-omap.txt | 2 +-
Documentation/devicetree/bindings/usb/ohci-omap3.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt
b/Documentation/devicetree/bindings/usb/ehci-omap.txt
index 485a9a1..3dc231c 100644
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt
Example for OMAP4:
usbhsehci: ehci@4a064c00 {
- compatible = ti,ehci-omap, usb-ehci;
+ compatible = ti,ehci-omap;
reg = 0x4a064c00 0x400;
interrupts = 0 77 0x4;
};
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
index 14ab428..ce8c47cff 100644
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -9,7 +9,7 @@ Required properties:
Example for OMAP4:
usbhsohci: ohci@4a064800 {
- compatible = ti,ohci-omap3, usb-ohci;
+ compatible = ti,ohci-omap3;
reg = 0x4a064800 0x400;
interrupts = 0 76 0x4;
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 11/12] ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes
The OMAP EHCI and OHCI controllers are not compatible with drivers
other than ti,ehci-omap and ti,ohci-omap3 respectively, so get
rid of the incompatible ids.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
arch/arm/boot/dts/omap4.dtsi | 4 ++--
arch/arm/boot/dts/omap5.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..8e7de9e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -634,14 +634,14 @@
ranges;
usbhsohci: ohci@48064400 {
- compatible = ti,ohci-omap3, usb-ohci;
+ compatible = ti,ohci-omap3;
reg = 0x48064400 0x400;
interrupt-parent = intc;
interrupts = 76;
};
usbhsehci: ehci@48064800 {
- compatible = ti,ehci-omap, usb-ehci;
+ compatible = ti,ehci-omap;
reg = 0x48064800 0x400;
interrupt-parent = intc;
interrupts = 77;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 39a05ce..ff1b057 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,14 +705,14 @@
refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
- compatible = ti,ohci-omap3, usb-ohci;
+ compatible = ti,ohci-omap3;
reg = 0x4a064800 0x400;
interrupt-parent = gic;
interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
};
usbhsehci: ehci@4a064c00 {
- compatible = ti,ehci-omap, usb-ehci;
+ compatible = ti,ehci-omap;
reg = 0x4a064c00 0x400;
interrupt-parent = gic;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index d4dae48..f65aa65 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -783,14 +783,14 @@
refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
- compatible = ti,ohci-omap3, usb-ohci;
+ compatible = ti,ohci-omap3;
reg = 0x4a064800 0x400;
interrupt-parent = gic;
interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
};
usbhsehci: ehci@4a064c00 {
- compatible = ti,ehci-omap, usb-ehci;
+ compatible = ti,ehci-omap;
reg = 0x4a064c00 0x400;
interrupt-parent = gic;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 09/12] ARM: dts: omap5-uevm: Provide USB PHY clock
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
reset-gpios = gpio3 16 GPIO_ACTIVE_LOW; /* gpio3_80
HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = auxclk1;
- * clock-names = main_clk;
- */
+ clocks = auxclk1_ck;
+ clock-names = main_clk;
clock-frequency = 1920;
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 08/12] ARM: dts: omap4-panda: Provide USB PHY clock
The USB PHY gets its clock from AUXCLK3. Provide this information. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..50b72966 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -83,12 +83,8 @@ compatible = usb-nop-xceiv; reset-gpios = gpio2 30 GPIO_ACTIVE_LOW; /* gpio_62 */ vcc-supply = hsusb1_power; - /** -* FIXME: -* put the right clock phandle here when available -* clocks = auxclk3; -* clock-names = main_clk; -*/ + clocks = auxclk3_ck; + clock-names = main_clk; clock-frequency = 1920; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 06/12] ARM: dts: omap4: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 04/12] mfd: omap-usb-host: Update DT clock binding information
The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..4721b2d 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * usbhost_120m_fck - 120MHz Functional clock. + + For OMAP4+ + * refclk_60m_int - 60MHz internal reference clock for UTMI clock mux + * refclk_60m_ext_p1 - 60MHz external ref. clock for Port 1's UTMI clock mux. + * refclk_60m_ext_p2 - 60MHz external ref. clock for Port 2's UTMI clock mux + * utmi_p1_gfclk - Port 1 UTMI clock mux. + * utmi_p2_gfclk - Port 2 UTMI clock mux. + * usb_host_hs_utmi_p1_clk - Port 1 UTMI clock gate. + * usb_host_hs_utmi_p2_clk - Port 2 UTMI clock gate. + * usb_host_hs_utmi_p3_clk - Port 3 UTMI clock gate. + * usb_host_hs_hsic480m_p1_clk - Port 1 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p2_clk - Port 2 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p3_clk - Port 3 480MHz HSIC clock gate. + * usb_host_hs_hsic60m_p1_clk - Port 1 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p2_clk - Port 2 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p3_clk - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 07/12] ARM: dts: omap5: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..d4dae48 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -775,6 +775,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = l3init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 05/12] mfd: omap-usb-tll: Update DT clock binding information
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain usb_tll_hs
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * usb_tll_hs_usb_ch0_clk - USB TLL channel 0 clock
+ * usb_tll_hs_usb_ch1_clk - USB TLL channel 1 clock
+ * usb_tll_hs_usb_ch2_clk - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll@4a062000 {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 02/12] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 92 +++--
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0c3c9a0..60a3bed 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-ENODEV);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i omap-nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap-utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap-ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
- if (IS_ERR(omap-ehci_logic_fck)) {
- ret = PTR_ERR(omap-ehci_logic_fck);
- dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap-usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i omap-nports; i++) {
+ if (is_ehci_phy_mode(pdata-port_mode[i]) ||
+ is_ehci_tll_mode(pdata-port_mode[i]) ||
+ is_ehci_hsic_mode(pdata-port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap-ehci_logic_fck = clk_get(dev, usbhost_120m_fck);
+ if (IS_ERR(omap-ehci_logic_fck)) {
+ ret = PTR_ERR(omap-ehci_logic_fck);
+ dev_err(dev, usbhost_120m_fck failed:%d\n,
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap-utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-utmi_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-utmi_clk[i]));
+ if (IS_ERR(omap-utmi_clk[i])) {
+ ret = PTR_ERR(omap-utmi_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic480m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic480m_clk[i]));
+ if (IS_ERR(omap-hsic480m_clk[i])) {
+ ret = PTR_ERR(omap-hsic480m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic60m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic60m_clk[i]));
+ if (IS_ERR(omap-hsic60m_clk[i])) {
+ ret = PTR_ERR(omap-hsic60m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata-port_mode[0]))
[PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 00/12] USB Host support for OMAP5 uEVM
Hi Benoit, Tony Lee, This patchset brings up USB Host ports and Ethernet port on the OMAP5 uEVM board. Please queue these for -next. Tested on: - OMAP5 uEVM - Pandaboard ES Rev. B1 - Beagleboard-XM Rev C2 - Beagleboard Rev C4. Changelog: v7: - Rebased on 3.14-rc2 - Removed incompatible ids from DT files and examples v6: - Initialized clocks to -ENODEV and split patch 3. v5: - Expose all clocks in the DT binding document for mfd:omap-usb-host and mfd:omap-usb-tll v4: - Updated DT binding document for clock binding v3: - Rebased on top of 3.13-rc7 cheers, -roger -- Roger Quadros (12): mfd: omap-usb-host: Use resource managed clk_get() mfd: omap-usb-host: Get clocks based on hardware revision mfd: omap-usb-host: Use clock names as per function for reference clocks mfd: omap-usb-host: Update DT clock binding information mfd: omap-usb-tll: Update DT clock binding information ARM: dts: omap4: Update omap-usb-host node ARM: dts: omap5: Update omap-usb-host node ARM: dts: omap4-panda: Provide USB PHY clock ARM: dts: omap5-uevm: Provide USB PHY clock ARM: OMAP2+: Remove legacy_init_ehci_clk() ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes usb: omap: dts: Update DT binding example usage .../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++ .../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++ .../devicetree/bindings/usb/ehci-omap.txt | 2 +- .../devicetree/bindings/usb/ohci-omap3.txt | 2 +- arch/arm/boot/dts/omap3.dtsi | 4 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +- arch/arm/boot/dts/omap4.dtsi | 10 +- arch/arm/boot/dts/omap5-uevm.dts | 8 +- arch/arm/boot/dts/omap5.dtsi | 10 +- arch/arm/mach-omap2/pdata-quirks.c | 16 -- drivers/mfd/omap-usb-host.c| 171 ++--- 11 files changed, 136 insertions(+), 128 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 01/12] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get().
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/omap-usb-host.c | 81 +
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 90b630c..0c3c9a0 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap-ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
+ omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
if (IS_ERR(omap-ehci_logic_fck)) {
ret = PTR_ERR(omap-ehci_logic_fck);
dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
}
}
- omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
+ omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
dev_err(dev, utmi_p1_gfclk failed error:%d\n, ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
+ omap-utmi_p2_gfclk = devm_clk_get(dev, utmi_p2_gfclk);
if (IS_ERR(omap-utmi_p2_gfclk)) {
ret = PTR_ERR(omap-utmi_p2_gfclk);
dev_err(dev, utmi_p2_gfclk failed error:%d\n, ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i omap-nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap-utmi_clk[i] = clk_get(dev, clkname);
+ omap-utmi_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-utmi_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-utmi_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
- omap-hsic480m_clk[i] = clk_get(dev, clkname);
+ omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic480m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic480m_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
- omap-hsic60m_clk[i] = clk_get(dev, clkname);
+ omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic60m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic60m_clk[i]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, Failed to create DT children: %d\n, ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, omap_usbhs_alloc_children failed: %d\n,
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i omap-nports; i++) {
-
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
On Wed 2014-02-05 13:44:58, Jenny Tc wrote:
On Tue, Feb 04, 2014 at 12:36:30PM +0100, Pavel Machek wrote:
+struct psy_charger_context {
+ bool is_usb_cable_evt_reg;
+ int psyc_cnt;
+ int batt_status;
+ /*cache battery and charger properties */
Comment coding style. Please run you patches through checkpatch.
checkpatch doesn't throw any error/warning. /* ... */ not allowed for single
line
comments? (will fix missing space after /*)
I meant the space after /*. Maybe checkpatch does not report anything
here, but I guess there are other places where it will comment :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 1/2] mtd: nand: omap: fix ecclayout-oobfree-offset
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Fri, Dec 13, 2013 at 02:42:57PM +0530, Pekon Gupta wrote:
This patch updates starting offset for free bytes in OOB which can be used by
file-systems to store their metadata (like clean-marker in case of JFFS2).
This should be describing a regression fix, right? We don't just
arbitrarily change the OOB free layout; we need a reason. So please
describe it here.
(It seems like an off-by-one, or off-by-N error, where the oobfree
region was miscalculated.)
Possibly you can paste an example intended ecclayout as well as an
incorrect layout that was calculated before this fix.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
[...]
-/* populate remaining ECC layout data */
-ecclayout-oobfree-length = mtd-oobsize - (BADBLOCK_MARKER_LENGTH +
-ecclayout-eccbytes);
for (i = 1; i ecclayout-eccbytes; i++)
ecclayout-eccpos[i] = ecclayout-eccpos[0] + i;
/* check if NAND device's OOB is enough to store ECC signatures */
@@ -1990,6 +1977,10 @@ static int omap_nand_probe(struct platform_device
*pdev)
err = -EINVAL;
goto return_error;
}
+/* populate remaining ECC layout data */
+ecclayout-oobfree-offset = ecclayout-eccpos[ecclayout-eccbytes] + 1;
Hmm, this line seems a little odd. The ecclayout-eccpos[] array and the
value of ecclayout-eccbytes sould be related as follows:
let N = ecclayout-eccbytes
This means the eccpos[] array should have N entries, indexed 0 to N-1,
and eccpos[N] is out of bounds. But you are accessing eccpos[N] above
(i.e., eccpos[ecclayout-eccbytes]). Are you sure this is correct? It
seems like it should be:
ecclayout-oobfree-offset = ecclayout-eccpos[ecclayout-eccbytes - 1]
+ 1;
Thanks for this catch. Yes, you are correct. It's a typo.
This wasn't caught as I had tested everything on UBIFS which does not use
'oobfree'.
Also, as ecclayout-eccpos is defined as large static array, so this dint
caused problems either.
#define MTD_MAX_ECCPOS_ENTRIES_LARGE640
struct nand_ecclayout {
__u32 eccpos[MTD_MAX_ECCPOS_ENTRIES_LARGE];
But, I think mtd_tests.nand_oobtest would have caught this. I'll include this
change in next version.
stripping down the CC list to avoid getting moderated by u-boot mailman
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe 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 00/11] ARM: dts: sbc-t3x: add support for more boards
ping! On 01/12/14 15:22, Dmitry Lifshitz wrote: Add support for CompuLab SBC-T3530 and SBC-T3517 boards: https://compulab.co.il/products/sbcs/sbc-t3530/ https://compulab.co.il/products/sbcs/sbc-t3517/ along with respective CoMs - CM-T3530 and CM-T3517: https://compulab.co.il/products/computer-on-modules/cm-t3530/ https://compulab.co.il/products/computer-on-modules/cm-t3517/ The device tree files have the following structure: omap3-cm-t3x.dtsi | |-- omap3-cm-t3x30.dtsi | | | | | | - --- | || CoM || Board || Base board | | | - --- | |omap3-sb-t35.dtsi | | | | |-- omap3-cm-t3730.dts -- omap3-sbc-t3730.dts --| | | | | |-- omap3-cm-t3530.dts -- omap3-sbc-t3530.dts --| || | omap3-cm-t3517.dts -- omap3-sbc-t3517.dts --| where omap3-cm-t3730.dts, omap3-cm-t3530.dts, omap3-cm-t3517.dts contain CoMs specific data, while omap3-sbc-t3730.dts, omap3-sbc-t3530.dts, omap3-sbc-t3517.dts represent eval boards with respective core modules. This series is based on Tony's omap-for-v3.14/dt branch Dmitry Lifshitz (11): ARM: dts: sbc-t3x: refactor DT support ARM: dts: sbc-t3x: disable mmc3 ARM: dts: sb-t35: fix Ethernet power supply ARM: dts: cm-t3x: add gpio-led pinmux ARM: dts: cm-t3x30: add twl4030 gpio pullups ARM: dts: cm-t3x30: add HS USB Host support ARM: dts: sbc-t3730: add pinmux for usb hub reset ARM: dts: cm-t3x30: add USB OTG support ARM: dts: sbc-t3530: add support for sbc-t3530 ARM: dts: sbc-t3517: add support for sbc-t3517 ARM: OMAP2+: make reset pulse for sbc-t3x usb hubs arch/arm/boot/dts/Makefile|4 + arch/arm/boot/dts/omap3-cm-t3517.dts | 137 + arch/arm/boot/dts/omap3-cm-t3530.dts | 13 +++ arch/arm/boot/dts/omap3-cm-t3730.dts | 40 -- arch/arm/boot/dts/omap3-cm-t3x.dtsi | 112 +++ arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 74 +- arch/arm/boot/dts/omap3-sb-t35.dtsi | 30 +++- arch/arm/boot/dts/omap3-sbc-t3517.dts | 44 +++ arch/arm/boot/dts/omap3-sbc-t3530.dts | 37 + arch/arm/boot/dts/omap3-sbc-t3730.dts | 24 +++--- arch/arm/mach-omap2/pdata-quirks.c| 67 - 11 files changed, 506 insertions(+), 76 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-cm-t3517.dts create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts create mode 100644 arch/arm/boot/dts/omap3-cm-t3x.dtsi create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts -- 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
Re: [PATCH] ARM: dts: OMAP5: add pmu node
Hi Nathan,
On 11/02/2014 21:14, Nathan Lynch wrote:
On 01/29/2014 10:56 AM, Nathan Lynch wrote:
Expose the PMU on OMAP5.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
OMAP folks, any issues with this patch?
Yes :-)
Notes:
Briefly tested with perf on OMAP5 UEVM with next-20140124.
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a9663e..fbf4661436e2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -76,6 +76,12 @@
GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
};
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = 0 131 4,
+0 132 4;
Could you use the macros instead of hard coded value? You have the
example just before your modification in the patch itself.
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: OMAP: clock DT conversion issues with omap36xx
Hi Tero, Christoph, On 07/02/14 12:12, Christoph Fritz wrote: On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 29600 0 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B DPLL on OMAP3 SoCs. Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an extra /2 divider to that clock path. So the 96m clock first gets mutiplied by 2, even though the HW doesn't do that, and then divided by 2, even though the HW doesn't do that. Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping the x2 clock nodes totally, which is much better. However, it leaves the old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it does when omapdss sets the fclk), the unused x2 clocks do recalcs, breaking everything. This last bit is a bit guesswork, I didn't actually verify it, but the fact is that if I remove the x2 clocks totally, omapdss work fine. Sooo... What should be done is create new DPLL4 clock paths for OMAP3630, which do not have the x2 clocks at all. I tried to do that, but it wasn't trivial (at least to me who is
Re: [PATCH] ARM: dts: OMAP5: add pmu node
On 02/12/2014 07:00 AM, Benoit Cousson wrote:
On 01/29/2014 10:56 AM, Nathan Lynch wrote:
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a9663e..fbf4661436e2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -76,6 +76,12 @@
GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
};
+pmu {
+compatible = arm,cortex-a15-pmu;
+interrupts = 0 131 4,
+ 0 132 4;
Could you use the macros instead of hard coded value? You have the
example just before your modification in the patch itself.
Thanks Benoit. Sorry for missing that, will fix.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 ISP capabilities, resizer
Hello,
some more findings:
* the driver bug seen below was observed with kernel 3.7 and is already
fixed in more recent kernels, likely with commit 864a121274,
[media] v4l: Don't warn during link validation when encountering a V4L2
devnode
* there still is a a confusing warning:
omap3isp omap3isp: can't find source, failing now
which may be addressed by the patch here https://linuxtv.org/patch/15200/,
but has not been applied
* I have a test program, http://pmeerw.net/scaler.c, which exercises the
OMAP3 ISP resizer standalone with the pipeline given below; it crashes the
system quite reliably on 3.7 and recent kernels :(
the reason for the crash is that the ISP resizer can still be busy and
doesn't like to be turned off then; a little sleep before
omap3isp_sbl_disable() helps (or waiting for the ISP resize to become
idle, see the patch below)
I'm not sure what omap3isp_module_sync_idle() is supposed to do, it
immediately returns since we are in SINGLESHOT mode and
isp_pipeline_ready() is false
with below patch I am happily resizing...
// snip, RFC
From: Peter Meerwald p.meerw...@bct-electronic.com
Date: Wed, 12 Feb 2014 15:59:20 +0100
Subject: [PATCH] omap3isp: Wait for resizer to become idle before
disabling
---
drivers/media/platform/omap3isp/ispresizer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index d11fb26..fea98f7 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1145,6 +1145,7 @@ static int resizer_set_stream(struct v4l2_subdev *sd, int
enable)
struct isp_video *video_out = res-video_out;
struct isp_device *isp = to_isp_device(res);
struct device *dev = to_device(res);
+ unsigned long timeout = 0;
if (res-state == ISP_PIPELINE_STREAM_STOPPED) {
if (enable == ISP_PIPELINE_STREAM_STOPPED)
@@ -1176,6 +1177,15 @@ static int resizer_set_stream(struct v4l2_subdev *sd,
int enable)
if (omap3isp_module_sync_idle(sd-entity, res-wait,
res-stopping))
dev_dbg(dev, %s: module stop timeout.\n, sd-name);
+
+ while (omap3isp_resizer_busy(res)) {
+ if (timeout++ 1000) {
+ dev_alert(isp-dev, ISP resizer does not
become idle\n);
+ return -ETIMEDOUT;
+ }
+ udelay(100);
+ }
+
omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_RESIZER_READ |
OMAP3_ISP_SBL_RESIZER_WRITE);
omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_RESIZER);
// snip
regards, p.
--
Peter Meerwald
+43-664-218 (mobile)
-- Forwarded message --
Date: Tue, 11 Feb 2014 17:02:23 +0100 (CET)
From: Peter Meerwald pme...@pmeerw.net
To: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-me...@vger.kernel.org, linux-omap@vger.kernel.org
Subject: OMAP3 ISP capabilities (fwd)
Hello,
trying (3) below and hitting
[ 6241.536071] WARNING: at drivers/media/v4l2-core/v4l2-subdev.c:424
v4l2_subdev_link_validate_get_format+0x90/0xa8()
[ 6241.573150] Driver bug! Wrong media entity type 65536, entity OMAP3 ISP
resizer input
[ 6241.595153] [c0011cdc] (unwind_backtrace+0x0/0xe0) from [c002ed28]
(warn_slowpath_common+0x4c/0x64)
[ 6241.605651] [c002ed28] (warn_slowpath_common+0x4c/0x64) from [c002edc0]
(warn_slowpath_fmt+0x2c/0x3c)
[ 6241.615997] [c002edc0] (warn_slowpath_fmt+0x2c/0x3c) from [c027e2e4]
(v4l2_subdev_link_validate_get_format+0x90/0xa8)
[ 6241.632751] [c027e2e4] (v4l2_subdev_link_validate_get_format+0x90/0xa8)
from [c027e314] (v4l2_subdev_link_validate+0x18)
[ 6241.645324] [c027e314] (v4l2_subdev_link_validate+0x18/0xac) from
[c0272954] (media_entity_pipeline_start+0xc8/0x170)
[ 6241.657012] [c0272954] (media_entity_pipeline_start+0xc8/0x170) from
[c0285820] (isp_video_streamon+0xa4/0x314)
[ 6241.672027] [c0285820] (isp_video_streamon+0xa4/0x314) from [c02748ec]
(v4l_streamon+0x18/0x1c)
[ 6241.681884] [c02748ec] (v4l_streamon+0x18/0x1c) from [c02779c0]
(__video_do_ioctl+0x1c4/0x2e4)
[ 6241.691558] [c02779c0] (__video_do_ioctl+0x1c4/0x2e4) from [c0277d84]
(video_usercopy+0x2a4/0x3e0)
[ 6241.701507] [c0277d84] (video_usercopy+0x2a4/0x3e0) from [c02730e0]
(v4l2_ioctl+0x6c/0x110)
[ 6241.715240] [c02730e0] (v4l2_ioctl+0x6c/0x110) from [c00c36ec]
(do_vfs_ioctl+0x548/0x5b8)
[ 6241.724792] [c00c36ec] (do_vfs_ioctl+0x548/0x5b8) from [c00c3794]
(sys_ioctl+0x38/0x54)
[ 6241.733795] [c00c3794] (sys_ioctl+0x38/0x54) from [c000d420]
(ret_fast_syscall+0x0/0x30)
[ 6241.743438] ---[ end trace 3ce601d6bddf2d7e ]---
pipeline is
media-ctl -r
media-ctl -l 'OMAP3 ISP resizer input:0-OMAP3 ISP resizer:0[1]'
media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
media-ctl -V 'OMAP3
Re: OMAP3 ISP capabilities
Hi Peter, On Tuesday 11 February 2014 15:54:00 Peter Meerwald wrote: Hello Laurent, some quick question about the OMAP3 ISP pipeline capabilities: (1) can the OMAP3 ISP CCDC output concurrently to memory AND the resizer in YUV mode? I think the answer is no due to hardware limitation Based on the TRM I would say that the hardware is capable of doing so, but this isn't implemented in the driver. (2) in RAW mode, I think it should be possible to connect pad 1 of the OMAP3 ISP CCDC to CCDC output and pad 2 to the ISP preview and subsequently to the resizer? so two stream can be read concurrently from video2 and video6? That's my understanding as well, but once again this isn't supported by the driver. (3) it should be possible to use the ISP resizer input / output (memory-to-memory) independently; it there any example code doing this? I haven't written any sample code as such for memory-to-memory operation. I usually use the following media-ctl and yavta commands to test memory-to- memory resizing : media-ctl -r media-ctl -l 'OMAP3 ISP resizer input:0-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -V 'OMAP3 ISP resizer:0[YUYV 2048x1536]' media-ctl -V 'OMAP3 ISP resizer:1[YUYV 1024x768]' yavta -f YUYV -s 2048x1536 -n 4 --capture=100 \ `media-ctl -e OMAP3 ISP resizer input` resizer-input.log 21 yavta -f YUYV -s 1024x768 -n 4 --capture=100 \ `./media-ctl -e OMAP3 ISP resizer output` resizer-output.log 21 You can also have a look at the omap3-isp-live application available at http://git.ideasonboard.org/omap3-isp-live.git It contains a library that offers viewfinder, snapshot and scaling functions on top of the ISP and two sample applications that use the library. The resizer memory-to-memory is used by the live application to scale captured snapshots when displaying them on screen. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP capabilities
Hello Laurent, (3) it should be possible to use the ISP resizer input / output (memory-to-memory) independently; it there any example code doing this? I haven't written any sample code as such for memory-to-memory operation. I usually use the following media-ctl and yavta commands to test memory-to- memory resizing : yavta -f YUYV -s 2048x1536 -n 4 --capture=100 \ `media-ctl -e OMAP3 ISP resizer input` resizer-input.log 21 yavta -f YUYV -s 1024x768 -n 4 --capture=100 \ `./media-ctl -e OMAP3 ISP resizer output` resizer-output.log 21 thanks for the suggestion; I didn't understand yavta/v4l enough to see how it can feed data to the ISP resizer input p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe 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: clock DT conversion issues with omap36xx
Hi Tomi, On Wed, Feb 12, 2014 at 2:18 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Tero, Christoph, On 07/02/14 12:12, Christoph Fritz wrote: On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 2 9600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 296000 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B DPLL on OMAP3 SoCs. Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an extra /2 divider to that clock path. So the 96m clock first gets mutiplied by 2, even though the HW doesn't do that, and then divided by 2, even though the HW doesn't do that. Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping the x2 clock nodes totally, which is much better. However, it leaves the old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it does when omapdss sets the fclk), the unused x2 clocks do recalcs, breaking everything. This last bit is a bit guesswork, I didn't actually verify it, but the fact is that if I remove the x2 clocks totally, omapdss work fine. Sooo... What should be done is create new DPLL4 clock paths for OMAP3630, which
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
On Wednesday, February 12, 2014 8:00 PM, Pavel Machek wrote:
On Wed 2014-02-05 13:44:58, Jenny Tc wrote:
On Tue, Feb 04, 2014 at 12:36:30PM +0100, Pavel Machek wrote:
+struct psy_charger_context {
+ bool is_usb_cable_evt_reg;
+ int psyc_cnt;
+ int batt_status;
+ /*cache battery and charger properties */
Comment coding style. Please run you patches through checkpatch.
checkpatch doesn't throw any error/warning. /* ... */ not allowed for
single line
comments? (will fix missing space after /*)
I meant the space after /*. Maybe checkpatch does not report anything
here, but I guess there are other places where it will comment :-).
Yes, right.
+ /*cache battery and charger properties */
^
'one space' is necessary between '/*' and 'cache'.
This can be fixed as below.
+ /* cache battery and charger properties */
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 0/5] add parallel NAND support for TI's new OMAPx and AMxx platforms
Hi Benoit, Tony, From: Gupta, Pekon This patch-set adds and updates parallel NAND support on following TI platforms - AM335x (am335x-evm) - DRA7xx (dra7-evm - AM43xx (am43X-epos-evm) In addition, following OMAP2+/GPMC patch is also added in this series as it add checks DRA7xx and AM43xxx platforms for non-DT kernels. ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms Please let me know, if this patch-set is in acceptable state, Or should I rebase it against any specific branch at your side ? with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
