Re: [RESEND PATCH V2 1/2] ARM: dts: AM33xx: Add RNG node
Hi Lokesh,
On 12/10/2013 15:26, Lokesh Vutla wrote:
Hi Benoit,
On Thursday 29 August 2013 06:22 PM, Lokesh Vutla wrote:
Add the AM33xx RNG module's device tree data.
Also add Documentation file describing the data
for the RNG module.
Seems you missed this patch. Please consider this for this merge window.
Indeed I missed it. Sorry :-(
Patch 2/2 is already taken by Paul.
Without this patch AM335x boot will crash as I mentioned in my cover letter.
Thanks and regards,
Lokesh
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V1:
- Drop status=disabled entry in dt node, Since
RNG is present on all AM33xx platforms.
.../devicetree/bindings/hwrng/omap_rng.txt | 22
arch/arm/boot/dts/am33xx.dtsi |7 +++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt
I do not see the acked-by for the binding part. You do need that for any
new bindings nowadays.
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000..6a62acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ RNG versions:
+ - ti,omap2-rng for OMAP2.
+ - ti,omap4-rng for OMAP4, OMAP5 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+ Only used for ti,omap4-rng.
+
+Example:
+/* AM335x */
+rng: rng@4831 {
+ compatible = ti,omap4-rng;
+ ti,hwmods = rng;
+ reg = 0x4831 0x2000;
+ interrupts = 111;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..26ebe30 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,12 @@
#size-cells = 1;
status = disabled;
};
+
+ rng: rng@4831 {
+ compatible = ti,omap4-rng;
+ ti,hwmods = rng;
+ reg = 0x4831 0x2000;
+ interrupts = 111;
+ };
};
};
It looks good to me, but it does not apply on my branch.
Please rebase it and repost with the proper acked-by.
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 1/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework
Hi Roger, On 14/10/2013 11:20, Roger Quadros wrote: Hi Benoit, On 10/10/2013 06:34 PM, Felipe Balbi wrote: On Mon, Oct 07, 2013 at 04:28:13PM +0300, Roger Quadros wrote: The generic PHY framewrok expects different properties than the old USB PHY framework. Supply those properties. Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was merged in greg/usb-next. [1] [1] - https://lkml.org/lkml/2013/9/27/581 Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com Could you please pick this one for 3.13? Thanks. I don't see it in your 3.13 take 2 pull request. It was not in it. I've just applied it. 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] usb: phy: omap: Add omap-control Support for AM437x
On 10/14/2013 6:49 PM, Roger Quadros wrote:
Hi George,
On 10/14/2013 03:51 PM, George Cherian wrote:
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian george.cher...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
drivers/usb/phy/phy-omap-control.c | 17 +
include/linux/usb/omap_control_usb.h | 6 ++
3 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 090e5e2..c495135 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -87,6 +87,8 @@ Required properties:
e.g. USB3 PHY and SATA PHY on OMAP5.
ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
DRA7 platform.
+ ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
for other types.
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 09c5ace..c453b81 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -84,6 +84,18 @@ void omap_control_usb_phy_power(struct device *dev, int on)
else
val |= OMAP_CTRL_USB2_PHY_PD;
break;
+
+ case OMAP_CTRL_TYPE_AM437USB2:
+ if (on) {
+ val = ~(AM437X_CTRL_USB2_PHY_PD |
+ AM437X_CTRL_USB2_OTG_PD);
+ val |= (AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
The ON and OFF operations are not symmetric because of this. Shouldn't the
OTG specific stuff go in otg specific ops?
AM437X_CTRL_USB2_OTGVDET_EN - this is basically the VBUS detect comparator.
AM437X_CTRL_USB2_OTGSESSEND_EN - this is Session End Comparator.
The TRM names these bits with OTG. Without these enabled the peripheral mode
does not
work properly with HW UTMI mode (UTMI mode in DWC).
These bits have no effect when AM437X_CTRL_USB2_OTG_PD and
AM437X_CTRL_USB2_PHY_PD are enabled
(powered down).
Anyways I will make it symmetric during OFF also .
+ } else {
+ val |= (AM437X_CTRL_USB2_PHY_PD |
+AM437X_CTRL_USB2_OTG_PD);
+ }
+ break;
default:
dev_err(dev, %s: type %d not recognized\n,
__func__, control_usb-type);
@@ -197,6 +209,7 @@ static const enum omap_control_usb_type otghs_data =
OMAP_CTRL_TYPE_OTGHS;
static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
static const enum omap_control_usb_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
static const enum omap_control_usb_type dra7usb2_data =
OMAP_CTRL_TYPE_DRA7USB2;
+static const enum omap_control_usb_type am437usb2_data =
OMAP_CTRL_TYPE_AM437USB2;
static const struct of_device_id omap_control_usb_id_table[] = {
{
@@ -215,6 +228,10 @@ static const struct of_device_id
omap_control_usb_id_table[] = {
.compatible = ti,control-phy-dra7usb2,
.data = dra7usb2_data,
},
+ {
+ .compatible = ti,control-phy-am437usb2,
+ .data = am437usb2_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 596b019..69ae383 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -24,6 +24,7 @@ enum omap_control_usb_type {
OMAP_CTRL_TYPE_USB2,/* USB2_PHY, power down in CONTROL_DEV_CONF */
OMAP_CTRL_TYPE_PIPE3, /* PIPE3 PHY, DPLL seperate Rx/Tx power */
OMAP_CTRL_TYPE_DRA7USB2, /* USB2 PHY, power and power_aux e.g. DRA7 */
+ OMAP_CTRL_TYPE_AM437USB2, /* USB2 PHY, power e.g. AM437x */
};
struct omap_control_usb {
@@ -64,6 +65,11 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
+#define AM437X_CTRL_USB2_PHY_PD BIT(0)
+#define AM437X_CTRL_USB2_OTG_PDBIT(1)
+#define AM437X_CTRL_USB2_OTGVDET_ENBIT(19)
+#define AM437X_CTRL_USB2_OTGSESSEND_EN BIT(20)
+
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
cheers,
-roger
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
[PATCH v4 0/2] DMM DT adaptation
The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the removal of address and irq data from the omap4 hwmods, the probe of DMM driver fails and omapdrm isn't able to utilize the DMM hardware. Add DMM bindings for omap4 and omap5. Changes in v4: - Clean up documentation further. Changes in v3: - Fix mistakes in documentation and remove aliases for dmm nodes. Changes in v2: - No changes, split out into a separate series containing only DT related parts. Archit Taneja (2): arm: dts: omap4+: Add DMM bindings drm: omap: Enable DT support for DMM Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++ arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++ 4 files changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] arm: dts: omap4+: Add DMM bindings
Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.
Add documentation for the DMM bindings.
Originally worked on by Andy Gross andy...@gmail.com
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
3 files changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..8bd6d0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of
the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like
page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible: Should contain ti,omap4-dmm for OMAP4 family
+ Should contain ti,omap5-dmm for OMAP5 and DRA7x family
+- reg: Contains DMM register address range (base address and length)
+- interrupts: Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods: Name of the hwmod associated to DMM, which is typically dmm
+
+Example:
+
+dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ ti,hwmods = dmm;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..b6bf288 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -487,6 +487,13 @@
ti,hwmods = kbd;
};
+ dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@4c00 {
compatible = ti,emif-4d;
reg = 0x4c00 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..e405458 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,6 +604,13 @@
ti,hwmods = wd_timer2;
};
+ dmm@4e00 {
+ compatible = ti,omap5-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@0x4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] drm: omap: Enable DT support for DMM
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross andy...@gmail.com
Cc: Andy Gross andy...@gmail.com
Cc: DRI Development dri-de...@lists.freedesktop.org
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..59f17de 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
};
#endif
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[] = {
+ { .compatible = ti,omap4-dmm, },
+ { .compatible = ti,omap5-dmm, },
+ {},
+};
+#else
+#define dmm_of_match NULL
+#endif
+
struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+ .of_match_table = dmm_of_match,
#ifdef CONFIG_PM
.pm = omap_dmm_pm_ops,
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: dts: omap: Add new bindings for OMAP
Hi Rajendra,
On 09/10/2013 18:45, Benoit Cousson wrote:
+ A couple of DT maintainers
On 09/10/2013 18:41, Rajendra Nayak wrote:
On Wednesday 09 October 2013 08:43 PM, Benoit Cousson wrote:
Hi Rajendra,
On 09/10/2013 12:11, Rajendra Nayak wrote:
On OMAP we have co-processor IPs, memory controllers,
GPIOs which control regulators and power switches to
PMIC, and SoC internal Bus IPs, some or most of which
should either not be reset or idled or both at init.
(In some cases there are erratas which prevent an IP
from being reset)
Have a way to pass this information from DT.
Did you get some acked-by from the DT maintainers?
Every new bindings must be carefully reviewed now.
Nope, I haven't. The patches are on the list for a couple
of months now.
Let's see if Mark and Rob are OK with that.
OK, I've just applied it after a small change in the subject:
ARM: dts: omap: Add reset/idle on init bindings for OMAP
Is that OK for you?
Thanks,
Benoit
Thanks,
Benoit
Regards,
Benoit
Update the am33xx/omap4 and omap5 dtsi files with the
new bindings for modules which either should not be
idled. reset or both. A later patch would cleanup the
same information that exists today as part of the hwmod
data files.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 ++-
arch/arm/boot/dts/am33xx.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/omap5.dtsi |2 ++
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 91b7049..808c154 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,7 +21,8 @@ Required properties:
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle
the module
during suspend.
-
+- ti,no-reset-on-init: When present, the module should not be reset
at init
+- ti,no-idle-on-init: When present, the module should not be idled
at init
Example:
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..ec33ea0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -607,6 +607,7 @@
reg = 0x44d0 0x4000/* M3 UMEM */
0x44d8 0x2000;/* M3 DMEM */
ti,hwmods = wkup_m3;
+ti,no-reset-on-init;
};
elm: elm@4808 {
@@ -637,6 +638,7 @@
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
+ti,no-idle-on-init;
reg = 0x5000 0x2000;
interrupts = 100;
gpmc,num-cs = 7;
diff --git a/arch/arm/boot/dts/omap4.dtsi
b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..e8fe797 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -214,6 +214,7 @@
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
ti,hwmods = gpmc;
+ti,no-idle-on-init;
};
uart1: serial@4806a000 {
@@ -492,6 +493,7 @@
reg = 0x4c00 0x100;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif1;
+ti,no-idle-on-init;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
@@ -503,6 +505,7 @@
reg = 0x4d00 0x100;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif2;
+ti,no-idle-on-init;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..a9d49df 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -607,6 +607,7 @@
emif1: emif@0x4c00 {
compatible= ti,emif-4d5;
ti,hwmods= emif1;
+ti,no-idle-on-init;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4c00 0x400;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
@@ -618,6 +619,7 @@
emif2: emif@0x4d00 {
compatible= ti,emif-4d5;
ti,hwmods= emif2;
+ti,no-idle-on-init;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4d00 0x400;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
--
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: [GIT PULL 3/6] omap hwmod changes for v3.13 merge window
Hi folks On Mon, 14 Oct 2013, Olof Johansson wrote: On Mon, Oct 14, 2013 at 9:25 PM, Kevin Hilman khil...@linaro.org wrote: On Oct 14, 2013 9:12 PM, Olof Johansson o...@lixom.net wrote: On Mon, Oct 14, 2013 at 03:44:44PM -0700, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/hwmod-signed for you to fetch changes up to 254f57a92987b6cde6004f58d6b847813dfb9e0e: ARM: OMAP5: hwmod: add missing ocp2scp hwmod data (2013-10-11 15:37:05 -0700) omap hwmod related changes via Paul Walmsley p...@pwsan.com: Some OMAP hwmod changes for 3.13. Significant changes here include: - support for moving some of the hwmod flags to DT data - support for the SSI, hardware spinlock, USB host/TLL, and RNG IP blocks for various OMAPs - a fix that again decouples hwmod data changes from unrelated DT data patchsets Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ Pulled into next/soc, Thanks, Kevin Hm, looks like my BBB hit this on v3.12-rc4-493-g1a9df23, which is pushed to to-build but not for-next yet. I'm guessing this might be what Kevin pinged me about on IRC today but I was out and unavailable most of the day. Hmmm... mine seems to have booted fine on that build... http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000666.html Well, it's a WARN_ON() not a panic, so my script probably shouldn't have aborted the boot (and your script should have reported it :-). Check your local log to see if you have something in there? The boot warnings can be seen here: (which is linked via the pull request above): http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt ... omap_hwmod: spinlock: doesn't have mpu register target base ... omap_hwmod: rng: doesn't have mpu register target base ... The spinlock warning on AM335x will be resolved when this patch is merged: https://lkml.org/lkml/2013/10/10/650 The rng warning will be resolved when this patch is merged: http://marc.info/?l=linux-arm-kernelm=137778078331134w=2 The WARN_ON() seems a bit heavy-handed, and I'd support replacing it with a pr_warn(); but on the other hand, it certainly seems to have attracted attention to a problem that prevents these devices from being usable :-) - Paul -- 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: omap4-panda-es: Do not reset gpio1
Hi Nishanth,
On 10/10/2013 18:44, Nishanth Menon wrote:
Do not reset GPIO1 at boot-up because GPIO 7 in GPIO1 block is used on
OMAP4460 PandaBoard-ES to select voltage register in TPS62361 which
supplies VDD_MPU.
Without this, OMAP4460 PandaBoard-ES boards fail to boot-up because
MPU voltage switches over to VSET0 voltage value (boot voltage) which
is not sufficient to operate the device at OPP100.
Signed-off-by: Nishanth Menon n...@ti.com
---
As explained here: http://marc.info/?l=u-bootm=133066647800872w=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-docm=138131355520116w=2
Applies on Benoit's for_13/dts branch:
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
I've just applied it after Rajendra's series.
Thanks,
Benoit
Tested on PandaBoard-ES without the u-boot uenv hack
arch/arm/boot/dts/omap4-panda-es.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..816d1c9 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -62,3 +62,7 @@
gpios = gpio1 8 GPIO_ACTIVE_HIGH;
};
};
+
+gpio1 {
+ti,no-reset-on-init;
+};
--
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: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
Hi Thomas, On Tuesday 01 October 2013 08:37 PM, Santosh Shilimkar wrote: On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote: On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: On 10/01/2013 06:13 AM, Sricharan R wrote: Hi, On Monday 30 September 2013 08:39 PM, Rob Herring wrote: On 09/30/2013 08:59 AM, 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's interrupt is mapped. The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. Seems like interrupt-map property is what you need here. http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Versatile Express also has an example. OK, but the idea was not to tie up the crossbar-interrupt numbers at the DTS level, but to assign it dynamically during runtime. This was one of the comments that came up with first crossbar support patches, which was assigning a interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? Yes. There are 240 peripheral interrupts connected out of which 160 can be used in this specific case. Yes, I understand the SOC connections. That does not answer my question. The 240 interrupts are likely to be limited to fewer by board design, pinmuxing, etc. yes limited by different board designs ... How do you handle the 161st interrupt request? Will never happen? Just rely on the random driver probe ordering? Well the board dts are expected to provide the peripheral support info to optimise it. If a board actually has more than 160 peripherals available then in that case the 161 interrupt will not be mapped. You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. Well all options are tried before coming up to the $subject solution. It was suggested by Thomas in the last review. https://lkml.org/lkml/2013/7/18/416 Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and that did not go as well. Finally was asked to handle this as a part of GIC driver with a separate domain. http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Well the router makes connections from peripheral to GIC. Thomas can better explain it but I think since its doing irq routing for GIC on a given hardware, I don't see any issue having some generic map/unmap function in GIC. The actual implementation is still outside of GIC. I read Thomas' reply as don't put this crap in his code. That was for the IRQCHIP based approach and as part of that review Thomas suggested why not irqdomain and suggested a prototype code as well. You can call it generic, but it is not. It is specific to the GIC and looks like an abuse of irqdomains to me. Look where the function declaration for register_routable_domain_ops is. I am not sure why you call it abuse of irqdomain since the map/unmap are exactly the interfaces where the logical to physical irq connections are made. Look at existing GIC code as well. I still let Thomas give his expert comment whether it is abusive because it it was, am sure he wouldn't have suggested that. Is this inline with what you were suggesting and is this approach fine ? 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
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
Re: [PATCH v2 2/5] ARM: dts: omap: Add new bindings for OMAP
On Tuesday 15 October 2013 12:57 PM, Benoit Cousson wrote:
Hi Rajendra,
On 09/10/2013 18:45, Benoit Cousson wrote:
+ A couple of DT maintainers
On 09/10/2013 18:41, Rajendra Nayak wrote:
On Wednesday 09 October 2013 08:43 PM, Benoit Cousson wrote:
Hi Rajendra,
On 09/10/2013 12:11, Rajendra Nayak wrote:
On OMAP we have co-processor IPs, memory controllers,
GPIOs which control regulators and power switches to
PMIC, and SoC internal Bus IPs, some or most of which
should either not be reset or idled or both at init.
(In some cases there are erratas which prevent an IP
from being reset)
Have a way to pass this information from DT.
Did you get some acked-by from the DT maintainers?
Every new bindings must be carefully reviewed now.
Nope, I haven't. The patches are on the list for a couple
of months now.
Let's see if Mark and Rob are OK with that.
OK, I've just applied it after a small change in the subject:
ARM: dts: omap: Add reset/idle on init bindings for OMAP
Is that OK for you?
Yes, sounds good. Thanks Benoit.
Thanks,
Benoit
Thanks,
Benoit
Regards,
Benoit
Update the am33xx/omap4 and omap5 dtsi files with the
new bindings for modules which either should not be
idled. reset or both. A later patch would cleanup the
same information that exists today as part of the hwmod
data files.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 ++-
arch/arm/boot/dts/am33xx.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/omap5.dtsi |2 ++
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 91b7049..808c154 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,7 +21,8 @@ Required properties:
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle
the module
during suspend.
-
+- ti,no-reset-on-init: When present, the module should not be reset
at init
+- ti,no-idle-on-init: When present, the module should not be idled
at init
Example:
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..ec33ea0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -607,6 +607,7 @@
reg = 0x44d0 0x4000/* M3 UMEM */
0x44d8 0x2000;/* M3 DMEM */
ti,hwmods = wkup_m3;
+ti,no-reset-on-init;
};
elm: elm@4808 {
@@ -637,6 +638,7 @@
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
+ti,no-idle-on-init;
reg = 0x5000 0x2000;
interrupts = 100;
gpmc,num-cs = 7;
diff --git a/arch/arm/boot/dts/omap4.dtsi
b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..e8fe797 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -214,6 +214,7 @@
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
ti,hwmods = gpmc;
+ti,no-idle-on-init;
};
uart1: serial@4806a000 {
@@ -492,6 +493,7 @@
reg = 0x4c00 0x100;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif1;
+ti,no-idle-on-init;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
@@ -503,6 +505,7 @@
reg = 0x4d00 0x100;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif2;
+ti,no-idle-on-init;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..a9d49df 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -607,6 +607,7 @@
emif1: emif@0x4c00 {
compatible= ti,emif-4d5;
ti,hwmods= emif1;
+ti,no-idle-on-init;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4c00 0x400;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
@@ -618,6 +619,7 @@
emif2: emif@0x4d00 {
compatible= ti,emif-4d5;
ti,hwmods= emif2;
+ti,no-idle-on-init;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4d00 0x400;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
[PATCH v2] usb: phy: omap: Add omap-control Support for AM437x
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian george.cher...@ti.com
---
Changes from v1:
Make ON and OFF operations symmetric.
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
drivers/usb/phy/phy-omap-control.c | 19 +++
include/linux/usb/omap_control_usb.h | 6 ++
3 files changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 090e5e2..c495135 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -87,6 +87,8 @@ Required properties:
e.g. USB3 PHY and SATA PHY on OMAP5.
ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
DRA7 platform.
+ ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
for other types.
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 09c5ace..e725318 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -84,6 +84,20 @@ void omap_control_usb_phy_power(struct device *dev, int on)
else
val |= OMAP_CTRL_USB2_PHY_PD;
break;
+
+ case OMAP_CTRL_TYPE_AM437USB2:
+ if (on) {
+ val = ~(AM437X_CTRL_USB2_PHY_PD |
+ AM437X_CTRL_USB2_OTG_PD);
+ val |= (AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
+ } else {
+ val = ~(AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
+ val |= (AM437X_CTRL_USB2_PHY_PD |
+AM437X_CTRL_USB2_OTG_PD);
+ }
+ break;
default:
dev_err(dev, %s: type %d not recognized\n,
__func__, control_usb-type);
@@ -197,6 +211,7 @@ static const enum omap_control_usb_type otghs_data =
OMAP_CTRL_TYPE_OTGHS;
static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
static const enum omap_control_usb_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
static const enum omap_control_usb_type dra7usb2_data =
OMAP_CTRL_TYPE_DRA7USB2;
+static const enum omap_control_usb_type am437usb2_data =
OMAP_CTRL_TYPE_AM437USB2;
static const struct of_device_id omap_control_usb_id_table[] = {
{
@@ -215,6 +230,10 @@ static const struct of_device_id
omap_control_usb_id_table[] = {
.compatible = ti,control-phy-dra7usb2,
.data = dra7usb2_data,
},
+ {
+ .compatible = ti,control-phy-am437usb2,
+ .data = am437usb2_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 596b019..69ae383 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -24,6 +24,7 @@ enum omap_control_usb_type {
OMAP_CTRL_TYPE_USB2,/* USB2_PHY, power down in CONTROL_DEV_CONF */
OMAP_CTRL_TYPE_PIPE3, /* PIPE3 PHY, DPLL seperate Rx/Tx power */
OMAP_CTRL_TYPE_DRA7USB2, /* USB2 PHY, power and power_aux e.g. DRA7 */
+ OMAP_CTRL_TYPE_AM437USB2, /* USB2 PHY, power e.g. AM437x */
};
struct omap_control_usb {
@@ -64,6 +65,11 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
+#define AM437X_CTRL_USB2_PHY_PDBIT(0)
+#define AM437X_CTRL_USB2_OTG_PDBIT(1)
+#define AM437X_CTRL_USB2_OTGVDET_ENBIT(19)
+#define AM437X_CTRL_USB2_OTGSESSEND_EN BIT(20)
+
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
--
1.8.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 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 11:01:16AM +0530, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(),
phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of
all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+if (dwc-usb2_generic_phy)
+phy_init(dwc-usb2_generic_phy);
+if (dwc-usb3_generic_phy)
+phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+if (dwc-usb2_generic_phy)
+phy_power_off(dwc-usb2_generic_phy);
+if (dwc-usb3_generic_phy)
+phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
}
+if (of_property_read_bool(node, phys) || pdata-has_phy) {
+dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+if (IS_ERR(dwc-usb2_generic_phy)) {
+dev_err(dev, no usb2 phy configured yet);
+return PTR_ERR(dwc-usb2_generic_phy);
+}
+
+dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+if (IS_ERR(dwc-usb3_generic_phy)) {
+dev_err(dev, no usb3 phy configured yet);
+return PTR_ERR(dwc-usb3_generic_phy);
+}
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+} else {
not required as we've used kzalloc for dwc.
+dwc-usb2_generic_phy = NULL;
+dwc-usb3_generic_phy = NULL;
+}
+
/* default to superspeed if no maximum_speed passed */
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 10:57:16AM +0300, Roger Quadros wrote:
On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(),
phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of
all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+if (dwc-usb2_phy)
+usb_phy_init(dwc-usb2_phy);
+if (dwc-usb3_phy)
+usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+/* Don't use USB PHY if generic PHY was found */
+dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 02:57 PM, Felipe Balbi wrote:
Hi,
On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ break;
+ }
Re: [PATCH v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Hi Hans, On Friday 11 October 2013 01:16 PM, Hans Verkuil wrote: On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the Acks. Is it possible to queue these for 3.13? Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ break;
+
Re: [PATCH v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Kamil, Can you take this driver as m2m maintainer or should I take it? Regards, Hans On 10/15/2013 03:47 PM, Archit Taneja wrote: Hi Hans, On Friday 11 October 2013 01:16 PM, Hans Verkuil wrote: On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the Acks. Is it possible to queue these for 3.13? Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case
Re: [GIT PULL 3/6] omap hwmod changes for v3.13 merge window
On Mon, Oct 14, 2013 at 9:30 PM, Olof Johansson o...@lixom.net wrote: On Mon, Oct 14, 2013 at 9:25 PM, Kevin Hilman khil...@linaro.org wrote: On Oct 14, 2013 9:12 PM, Olof Johansson o...@lixom.net wrote: On Mon, Oct 14, 2013 at 03:44:44PM -0700, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/hwmod-signed for you to fetch changes up to 254f57a92987b6cde6004f58d6b847813dfb9e0e: ARM: OMAP5: hwmod: add missing ocp2scp hwmod data (2013-10-11 15:37:05 -0700) omap hwmod related changes via Paul Walmsley p...@pwsan.com: Some OMAP hwmod changes for 3.13. Significant changes here include: - support for moving some of the hwmod flags to DT data - support for the SSI, hardware spinlock, USB host/TLL, and RNG IP blocks for various OMAPs - a fix that again decouples hwmod data changes from unrelated DT data patchsets Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ Pulled into next/soc, Thanks, Kevin Hm, looks like my BBB hit this on v3.12-rc4-493-g1a9df23, which is pushed to to-build but not for-next yet. I'm guessing this might be what Kevin pinged me about on IRC today but I was out and unavailable most of the day. Hmmm... mine seems to have booted fine on that build... http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000666.html Well, it's a WARN_ON() not a panic, so my script probably shouldn't have aborted the boot (and your script should have reported it :-). Yes indeed, it's been on my todo list to catch/report those. Check your local log to see if you have something in there? Yup, there are a few backtraces due to the warns. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 05:03:50PM +0300, Roger Quadros wrote:
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed
is super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email
it seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+
RE: [PATCH v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Hi Hans, Now, I am a bit busy with... USB. I have to admit I have a backlog of patches to look through and prepare a tree for Mauro. I wanted to do this on Thursday or Friday. Is it ok? BTW if you see any m2m patches in patchwork feel free to delegate them to me. Best wishes, -- Kamil Debski Linux Kernel Developer Samsung RD Institute Poland -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, October 15, 2013 3:52 PM To: Kamil Debski Cc: Archit Taneja; linux-me...@vger.kernel.org; linux- o...@vger.kernel.org; laurent.pinch...@ideasonboard.com Subject: Re: [PATCH v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver Kamil, Can you take this driver as m2m maintainer or should I take it? Regards, Hans On 10/15/2013 03:47 PM, Archit Taneja wrote: Hi Hans, On Friday 11 October 2013 01:16 PM, Hans Verkuil wrote: On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the Acks. Is it possible to queue these for 3.13? Archit -- 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 v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Hi Archit, Please find my comment below. From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, October 15, 2013 3:52 PM Kamil, Can you take this driver as m2m maintainer or should I take it? Regards, Hans On 10/15/2013 03:47 PM, Archit Taneja wrote: Hi Hans, On Friday 11 October 2013 01:16 PM, Hans Verkuil wrote: On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the Acks. Is it possible to queue these for 3.13? Yep, it is possible. But [v4,4/4] v4l: ti-vpe: Add de-interlacer support in VPE does not apply after applying [v5,3/4] v4l: ti-vpe: Add VPE mem to mem driver. Please send a v5 with all patches. Best wishes, Kamil -- 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 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
Thanks Andreas for the patch,
On Saturday 05 October 2013 04:47 PM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
@@ -2293,23 +2440,66 @@ static int omap_hsmmc_resume(struct device *dev)
static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
+ unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
dev_dbg(dev, disabled\n);
- return 0;
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ spin_lock_irqsave(host-irq_lock, flags);
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ ret = pinctrl_select_state(host-pinctrl, host-idle);
+ if (ret 0)
+ dev_warn(mmc_dev(host-mmc), Unable to select idle
pinmux\n);
+
+ enable_irq(mmc_slot(host).sdio_irq);
+ }
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* infinite loop, if irq not cleared in omap_hsmmc_enable_sdio_irq */
+ host-flags |= HSMMC_RUNTIME_SUSPENDED;
Can you provide more details about the infinite loop and how it will get
recovered.
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ return ret;
}
static int omap_hsmmc_runtime_resume(struct device *dev)
{
struct omap_hsmmc_host *host;
+ unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_restore(host);
dev_dbg(dev, enabled\n);
- return 0;
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* infinite loop, if irq not cleared in omap_hsmmc_enable_sdio_irq */
+ host-flags = ~HSMMC_RUNTIME_SUSPENDED;
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ disable_irq(mmc_slot(host).sdio_irq);
+
+ ret = pinctrl_select_state(host-pinctrl, host-active);
+ if (ret 0)
+ dev_warn(mmc_dev(host-mmc), Unable to select active
pinmux\n);
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED) {
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+ }
+ return ret;
}
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
diff --git a/include/linux/platform_data/mmc-omap.h
b/include/linux/platform_data/mmc-omap.h
index 2bf1b30..fd5fff5 100644
--- a/include/linux/platform_data/mmc-omap.h
+++ b/include/linux/platform_data/mmc-omap.h
@@ -115,6 +115,7 @@ struct omap_mmc_platform_data {
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
+ int gpio_cirq; /* gpio (card irq) */
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
@@ -145,6 +146,9 @@ struct omap_mmc_platform_data {
int card_detect_irq;
int (*card_detect)(struct device *dev, int slot);
+ /* SDIO IRQs */
+ int sdio_irq;
+
unsigned int ban_openended:1;
} slots[OMAP_MMC_MAX_SLOTS];
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP5: Add i2c aliases
Currently, i2c1 and i2c5 defer probe due to pinctrl dependencies.
This changes the i2c ID each bus is registered with in i2c-dev
interface.
As a result of this, many userspace tools break and there is no
consistent manner to fix the same if the i2c dev interface have no
consistent numbering. Provide alias to allow ordering the i2c devices
correctly.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e18ee7e..8970deb 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -21,6 +21,11 @@
interrupt-parent = gic;
aliases {
+ i2c0 = i2c1;
+ i2c1 = i2c2;
+ i2c2 = i2c3;
+ i2c3 = i2c4;
+ i2c4 = i2c5;
serial0 = uart1;
serial1 = uart2;
serial2 = uart3;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] arm: omap: gpmc: remove detection of ecc-capability based on SoC name
Legacy OMAP SoC like OMAP2xxx, OMAP3xxx do not have in-build ELM h/w engine,
so they cannot support h/w based BCH ECC error-detection. Thus,
gpmc_hwecc_bch_capable() check was added in following commit to find-out
which SoC have in-built ELM h/w to support hardware based ecc-correction.
commit 3852ccd66a9bcb2aa6f46bce5442b6d8d08e5b5d
Author: Afzal Mohammed af...@ti.com
AuthorDate: 2012-10-01
But with DT based kernel, presence of ELM h/w engine on SoC is parsed from DT
data part of .dtsi file, which is unique for each device. Hence hard-coded
check for each device can be dropped.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 662c7fd..2b03eba 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -43,28 +43,6 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
-static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
-{
- /* support only OMAP3 class */
- if (!cpu_is_omap34xx() !soc_is_am33xx()) {
- pr_err(BCH ecc is not supported on this CPU\n);
- return 0;
- }
-
- /*
-* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
-* and AM33xx derivates. Other chips may be added if confirmed to work.
-*/
- if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW)
- (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))
- (!soc_is_am33xx())) {
- pr_err(BCH 4-bit mode is not supported on this CPU\n);
- return 0;
- }
-
- return 1;
-}
-
int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
struct gpmc_timings *gpmc_t)
{
@@ -127,9 +105,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
- if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt))
- return -EINVAL;
-
err = platform_device_register(gpmc_nand_device);
if (err 0) {
dev_err(dev, Unable to register NAND device\n);
--
1.8.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 5/8] ARM: dts: Add basic support for TMDSEVM3730 (Mistral AM/DM37x EVM)
* Tony Lindgren t...@atomide.com [131010 15:29]:
I've tested the serial, MMC, smsc911x, wl12xx, and off-idle support
with the pinctrl patches, so it probably works better than the
board-*.c files ever did. Also the board-omap3evm.c file is broken
for the DSS, and has been for a while. Patches are welcome to fix
it in this .dts file, let's just drop the board-*.c file for this.
Oops, the NAND I did not test and the copied partition map is
different from the board file. Here's the updated partition map.
I've tested the NAND using ubifs on the last partition.
I'm folding in the following fix as I did not push it out yet.
Regards,
Tony
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -94,7 +94,7 @@
5 0 0x2c00 0x0100;
nand@0,0 {
- linux,mtd-name= micron,mt29c4g96maz;
+ linux,mtd-name= hynix,h8kds0un0mer-4em;
reg = 0 0 0;
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
@@ -118,24 +118,24 @@
#size-cells = 1;
partition@0 {
- label = SPL;
- reg = 0 0x10;
+ label = X-Loader;
+ reg = 0 0x8;
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = 0x8 0x1c;
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = 0x24 0x4;
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = 0x28 0x50;
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = 0x78 0x1f88;
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] arm/dts: added dt properties to adapt to the new phy framwork
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index edc801f..998f198 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -661,7 +661,8 @@
compatible = snps,dwc3;
reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
- usb-phy = usb2_phy, usb3_phy;
+ phys = usb2_phy, usb3_phy;
+ phy-names = usb2-phy, usb3-phy;
tx-fifo-resize;
};
};
@@ -677,6 +678,7 @@
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
ctrl-module = omap_control_usb2phy;
+ #phy-cells = 0;
};
usb3_phy: usb3phy@4a084400 {
@@ -686,6 +688,7 @@
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+ #phy-cells = 0;
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
This patch was deferred from Generic PHY framework series since dwc3 uses the
same driver and it has to be adapted to the Generic PHY Framework.
drivers/phy/phy-omap-usb2.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index bfc5c33..9b3e867 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -98,28 +98,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
}
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
- struct omap_usb *phy = phy_to_omapusb(x);
- int ret;
-
- if (suspend !phy-is_suspended) {
- omap_control_usb_phy_power(phy-control_dev, 0);
- pm_runtime_put_sync(phy-dev);
- phy-is_suspended = 1;
- } else if (!suspend phy-is_suspended) {
- ret = pm_runtime_get_sync(phy-dev);
- if (ret 0) {
- dev_err(phy-dev, get_sync failed with err %d\n, ret);
- return ret;
- }
- omap_control_usb_phy_power(phy-control_dev, 1);
- phy-is_suspended = 0;
- }
-
- return 0;
-}
-
static int omap_usb_power_off(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
@@ -173,7 +151,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.dev= phy-dev;
phy-phy.label = omap-usb2;
- phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
@@ -195,8 +172,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
phy-control_dev = control_pdev-dev;
-
- phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
otg-set_host = omap_usb_set_host;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt boot or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
In usb_get_phy_by_phandle, index 0 always refers to usb2 phy and index 1 always
refers to usb3 phy. Since we've lived so long with this, this patch will make
an assumption that if only one entry is populated in *usb-phy* property, it will
be usb2 phy and the next entry will be usb3 phy.
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 72 --
drivers/usb/dwc3/platform_data.h |2 ++
3 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 70fc430..8e385b4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) HAS_DMA
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..cb91d70 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -354,6 +354,7 @@ static int dwc3_probe(struct platform_device *pdev)
struct device_node *node = dev-of_node;
struct resource *res;
struct dwc3 *dwc;
+ int count;
int ret = -ENOMEM;
@@ -387,16 +388,49 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ count = of_count_phandle_with_args(node, usb-phy, NULL);
+ switch (count) {
+ case 2:
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy)) {
+ dev_err(dev, usb3 phy not found\n);
+ return PTR_ERR(dwc-usb3_phy);
+ }
+ case 1:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy)) {
+ dev_err(dev, usb2 phy not found\n);
+ return PTR_ERR(dwc-usb2_phy);
+ }
+ break;
+ default:
+ dev_err(dev, usb phy nodes not configured\n);
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ if (pdata-usb2_phy) {
+ dwc-usb2_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB2);
+ if (IS_ERR(dwc-usb2_phy)) {
+ dev_err(dev, usb2 phy not found\n);
+ return PTR_ERR(dwc-usb2_phy);
+ }
+ }
+
+ if (pdata-usb3_phy) {
+ dwc-usb3_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB3);
+ if (IS_ERR(dwc-usb3_phy)) {
+ dev_err(dev, usb3 phy not found\n);
+ return PTR_ERR(dwc-usb3_phy);
+ }
+ }
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +443,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
- if (IS_ERR(dwc-usb2_phy)) {
- ret = PTR_ERR(dwc-usb2_phy);
-
- /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb2 phy configured\n);
- return -EPROBE_DEFER;
- }
-
- if (IS_ERR(dwc-usb3_phy)) {
[PATCH v2 4/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-ti-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
.../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} | 206 +++-
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/phy/ti_pipe3.h | 52 +
6 files changed, 174 insertions(+), 107 deletions(-)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (57%)
create mode 100644 include/linux/phy/ti_pipe3.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..1158943 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,6 +27,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config TI_PIPE3
+ tristate TI PIPE3 PHY Driver
+ select GENERIC_PHY
+ select OMAP_CONTROL_USB
+ help
+ Enable this to support the PIPE3 PHY that is part of TI SOCs. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the OMAP Control PHY Driver to power
+ on/off the PHY.
+
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..42ccab4 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-ti-pipe3.c
similarity index 57%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-ti-pipe3.c
index 0c6ba29..31e8397 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -1,5 +1,5 @@
/*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * phy-ti-pipe3 - PIPE3 PHY driver for SATA, USB and PCIE.
*
* Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
* This program is free software; you can redistribute it and/or modify
@@ -19,7 +19,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/usb/omap_usb.h
+#include linux/phy/ti_pipe3.h
+#include linux/phy/phy.h
#include linux/of.h
#include linux/clk.h
#include linux/err.h
@@ -52,17 +53,17 @@
/*
* This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
*/
# define PLL_IDLE_TIME 100;
-struct usb_dpll_map {
+struct pipe3_dpll_map {
unsigned long rate;
- struct usb_dpll_params params;
+ struct pipe3_dpll_params params;
};
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */
@@ -71,7 +72,7 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */
};
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
{
int i;
@@ -83,110 +84,113 @@ static struct usb_dpll_params
*omap_usb3_get_dpll_params(unsigned long rate)
return NULL;
}
-static int omap_usb3_suspend(struct usb_phy *x, int suspend)
+static int ti_pipe3_power_off(struct phy *x)
{
- struct omap_usb *phy = phy_to_omapusb(x);
- int val;
+ struct ti_pipe3 *phy = phy_get_drvdata(x);
+ int val;
int timeout = PLL_IDLE_TIME;
- if (suspend !phy-is_suspended) {
- val = omap_usb_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
- val |= PLL_IDLE;
- omap_usb_writel(phy-pll_ctrl_base, PLL_CONFIGURATION2, val);
-
- do {
- val = omap_usb_readl(phy-pll_ctrl_base, PLL_STATUS);
- if (val PLL_TICOPWDN)
- break;
- udelay(1);
- } while (--timeout);
-
- omap_control_usb_phy_power(phy-control_dev, 0);
-
- phy-is_suspended = 1;
-
[PATCH v2 6/7] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/phy-omap-usb2.c |2 +-
include/linux/{usb = phy}/omap_usb.h |3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
rename include/linux/{usb = phy}/omap_usb.h (95%)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 9b3e867..d738dc3 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/io.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_usb.h
#include linux/usb/phy_companion.h
#include linux/clk.h
#include linux/err.h
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
struct omap_usb {
struct usb_phy phy;
struct phy_companion*comparator;
- void __iomem*pll_ctrl_base;
struct device *dev;
struct device *control_dev;
struct clk *wkupclk;
- struct clk *sys_clk;
struct clk *optclk;
- u8 is_suspended:1;
};
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 52
drivers/usb/dwc3/core.h|7
drivers/usb/dwc3/platform_data.h |2 +
5 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8e385b4..64eed6f 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) HAS_DMA
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index cb91d70..28bfa5b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -439,6 +450,26 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ count = of_property_match_string(node, phy-names, usb2-phy);
+ if (count = 0 || (pdata pdata-usb2_generic_phy)) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+ dwc-usb2_phy = NULL;
+ }
+
+ count = of_property_match_string(node, phy-names, usb3-phy);
+ if (count = 0 || (pdata pdata-usb3_generic_phy)) {
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
+ dwc-usb3_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -462,6 +493,11 @@ static int dwc3_probe(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 0);
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_on(dwc-usb3_generic_phy);
+
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
@@ -588,6 +624,11 @@ static int dwc3_remove(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 1);
usb_phy_set_suspend(dwc-usb3_phy, 1);
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
[PATCH v2 3/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/ti-phy.txt
Since now we have a separate folder for phy, move the PHY dt binding
documentation of TI to that folder.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt} |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt}
(86%)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
similarity index 86%
rename from Documentation/devicetree/bindings/usb/usb-phy.txt
rename to Documentation/devicetree/bindings/phy/ti-phy.txt
index c0245c8..355acf0 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -1,4 +1,4 @@
-USB PHY
+TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
OMAP USB2 PHY
@@ -21,10 +21,11 @@ usb2phy@4a0ad080 {
#phy-cells = 0;
};
-OMAP USB3 PHY
+TI PIPE3 PHY
Required properties:
- - compatible: Should be ti,omap-usb3
+ - compatible: Should be ti,phy-usb3, ti,phy-pcie or ti,phy-sata.
+ ti,omap-usb3 is deprecated.
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
@@ -38,7 +39,7 @@ Optional properties:
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
- compatible = ti,omap-usb3;
+ compatible = ti,phy-usb3;
reg = 0x4a084400 0x80,
0x4a084800 0x64,
0x4a084c00 0x40;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Make dwc3 use Generic PHY Framework
Felipe,
Looks like most of the patches are dependent on Generic PHY Framework except
the first one. Let me know if I have to take these patches with your ACK or
you'll take it yourself.
**
Modified dwc3 core to find PHYs only if the platform indicates that it has
to use a PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also
changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver
has to be used for SATA and PCIE too.
Changes from v1:
* The logic in which the driver detects the presence of PHYs has changed.
* patch ordering has changed
* udelay is replaced with usleep_range
* A patch to remove set_suspend callback which was deferred from Generic
PHY Framework series has been included.
Kishon Vijay Abraham I (7):
usb: dwc3: get usb_phy only if the platform indicates the presence
of PHY's
usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Documentation: dt bindings: move ..usb/usb-phy.txt to
..phy/ti-phy.txt
drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
arm/dts: added dt properties to adapt to the new phy framwork
.../bindings/{usb/usb-phy.txt = phy/ti-phy.txt} |9 +-
Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
arch/arm/boot/dts/omap5.dtsi |5 +-
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
drivers/phy/phy-omap-usb2.c| 27 +--
.../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} | 206 +++-
drivers/usb/dwc3/Kconfig |2 +
drivers/usb/dwc3/core.c| 124
drivers/usb/dwc3/core.h|7 +
drivers/usb/dwc3/platform_data.h |4 +
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/{usb = phy}/omap_usb.h |3 -
include/linux/{usb/omap_usb.h = phy/ti_pipe3.h} | 33 +---
15 files changed, 248 insertions(+), 201 deletions(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt}
(86%)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (57%)
copy include/linux/{usb = phy}/omap_usb.h (95%)
rename include/linux/{usb/omap_usb.h = phy/ti_pipe3.h} (53%)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: add minimal DT support for Nokia N950 N9 phones
Add minimal DT support for Nokia N950 N9 phones. The same functionality
that is provided by the current board file should work: serial console,
USB, OneNAND and MMC.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
---
v3: Added Tony's ACK properties for generic USB PHY framework.
Previous version: http://marc.info/?t=138005105700010r=1w=2
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-n9.dts | 18
arch/arm/boot/dts/omap3-n950-n9.dtsi | 174 +++
arch/arm/boot/dts/omap3-n950.dts | 18
4 files changed, 212 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-n9.dts
create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi
create mode 100644 arch/arm/boot/dts/omap3-n950.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9df7d2c..62d0f4d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-gta04.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-n9.dtb \
+ omap3-n950.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
new file mode 100644
index 000..39828ce
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n9.dts - Device Tree file for Nokia N9
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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 omap3-n950-n9.dtsi
+
+/ {
+ model = Nokia N9;
+ compatible = nokia,omap3-n9, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
new file mode 100644
index 000..94eb77d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -0,0 +1,174 @@
+/*
+ * omap3-n950-n9.dtsi - Device Tree file for Nokia N950 N9 (common stuff)
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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.
+ */
+
+#include omap36xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ vemmc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = VEMMC;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ gpio = gpio5 29 0; /* gpio line 157 */
+ startup-delay-us = 150;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 290;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+twl {
+ compatible = ti,twl5031;
+};
+
+twl_gpio {
+ ti,pullups = 0x01; /* BIT(0) */
+ ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = vemmc;
+ bus-width = 4;
+ ti,non-removable;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
+ mode = 3;
+ power = 50;
+};
+
+gpmc {
+ ranges = 0 0 0x0400 0x2000;
+
+ onenand@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x2000;
+
+ gpmc,sync-read;
+ gpmc,sync-write;
+ gpmc,burst-length = 16;
+ gpmc,burst-read;
+ gpmc,burst-wrap;
+
Re: [PATCH v3] ARM: dts: add minimal DT support for Nokia N950 N9 phones
* Aaro Koskinen aaro.koski...@iki.fi [131015 13:36]:
Add minimal DT support for Nokia N950 N9 phones. The same functionality
that is provided by the current board file should work: serial console,
USB, OneNAND and MMC.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
Oh this is not yet merged, I'll pick this one into the
omap-for-v3.13/board-removal as the board removal patch is
already there.
Regards,
Tony
---
v3: Added Tony's ACK properties for generic USB PHY framework.
Previous version: http://marc.info/?t=138005105700010r=1w=2
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-n9.dts | 18
arch/arm/boot/dts/omap3-n950-n9.dtsi | 174
+++
arch/arm/boot/dts/omap3-n950.dts | 18
4 files changed, 212 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-n9.dts
create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi
create mode 100644 arch/arm/boot/dts/omap3-n950.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9df7d2c..62d0f4d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-gta04.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-n9.dtb \
+ omap3-n950.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
new file mode 100644
index 000..39828ce
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n9.dts - Device Tree file for Nokia N9
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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 omap3-n950-n9.dtsi
+
+/ {
+ model = Nokia N9;
+ compatible = nokia,omap3-n9, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
new file mode 100644
index 000..94eb77d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -0,0 +1,174 @@
+/*
+ * omap3-n950-n9.dtsi - Device Tree file for Nokia N950 N9 (common stuff)
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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.
+ */
+
+#include omap36xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ vemmc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = VEMMC;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ gpio = gpio5 29 0; /* gpio line 157 */
+ startup-delay-us = 150;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 290;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+twl {
+ compatible = ti,twl5031;
+};
+
+twl_gpio {
+ ti,pullups = 0x01; /* BIT(0) */
+ ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = vemmc;
+ bus-width = 4;
+ ti,non-removable;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
+ mode = 3;
+ power = 50;
+};
+
+gpmc {
+ ranges = 0 0 0x0400 0x2000;
+
+ onenand@0,0 {
+ #address-cells = 1;
+
[PATCH 1/1] gpio/omap: use gpiolib API to mark a GPIO used as an IRQ
The OMAP GPIO driver keeps track about GPIO pins that are
used as IRQ lines for two reasons:
1) To prevent GPIO banks to be disabled while one of their
GPIO pins are only used as an interrupt line.
2) To not allow another caller to set the GPIO pin as output.
Now gpiolib has an API to mark GPIO pins as used as IRQ lines
so the GPIO core only allows to set as output GPIO pins not
tied to an IRQ. So there is no need to have custom code for 2).
The IRQ usage still has to be maintained locally for 1) though.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..f319c9f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -514,6 +514,14 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
}
+ retval = gpio_lock_as_irq(bank-chip, offset);
+ if (retval) {
+ dev_err(bank-dev, unable to lock offset %d for IRQ\n,
+ offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return retval;
+ }
+
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -797,6 +805,7 @@ static void gpio_irq_shutdown(struct irq_data *d)
unsigned offset = GPIO_INDEX(bank, gpio);
spin_lock_irqsave(bank-lock, flags);
+ gpio_unlock_as_irq(bank-chip, offset);
bank-irq_usage = ~(1 offset);
_disable_gpio_module(bank, offset);
_reset_gpio(bank, gpio);
@@ -957,22 +966,13 @@ static int gpio_output(struct gpio_chip *chip, unsigned
offset, int value)
{
struct gpio_bank *bank;
unsigned long flags;
- int retval = 0;
bank = container_of(chip, struct gpio_bank, chip);
spin_lock_irqsave(bank-lock, flags);
-
- if (LINE_USED(bank-irq_usage, offset)) {
- retval = -EINVAL;
- goto exit;
- }
-
bank-set_dataout(bank, offset, value);
_set_gpio_direction(bank, offset, 0);
-
-exit:
spin_unlock_irqrestore(bank-lock, flags);
- return retval;
+ return 0;
}
static int gpio_debounce(struct gpio_chip *chip, unsigned offset,
--
1.8.4.rc3
--
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 v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Hi, On Tuesday 15 October 2013 09:24 PM, Kamil Debski wrote: Hi Archit, Please find my comment below. From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, October 15, 2013 3:52 PM Kamil, Can you take this driver as m2m maintainer or should I take it? Regards, Hans On 10/15/2013 03:47 PM, Archit Taneja wrote: Hi Hans, On Friday 11 October 2013 01:16 PM, Hans Verkuil wrote: On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the Acks. Is it possible to queue these for 3.13? Yep, it is possible. But [v4,4/4] v4l: ti-vpe: Add de-interlacer support in VPE does not apply after applying [v5,3/4] v4l: ti-vpe: Add VPE mem to mem driver. Please send a v5 with all patches. Ah, sorry about that. There was a minor conflict with the updated patch. Will post out v5. Thanks, Archit -- 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 v5 0/4] v4l: VPE mem to mem driver
VPE(Video Processing Engine) is an IP found on DRA7xx, this series adds VPE as a mem to mem v4l2 driver, and VPDMA as a helper library. The first version of the patch series described VPE in detail, you can have a look at it here: http://www.spinics.net/lists/linux-media/msg66518.html Changes in v5: - updated how pix-colorspace is set. - adds comments on what our private control ID is used for. Archit Taneja (4): v4l: ti-vpe: Create a vpdma helper library v4l: ti-vpe: Add helpers for creating VPDMA descriptors v4l: ti-vpe: Add VPE mem to mem driver v4l: ti-vpe: Add de-interlacer support in VPE drivers/media/platform/Kconfig | 16 + drivers/media/platform/Makefile|2 + drivers/media/platform/ti-vpe/Makefile |5 + drivers/media/platform/ti-vpe/vpdma.c | 846 +++ drivers/media/platform/ti-vpe/vpdma.h | 203 +++ drivers/media/platform/ti-vpe/vpdma_priv.h | 641 + drivers/media/platform/ti-vpe/vpe.c| 2099 drivers/media/platform/ti-vpe/vpe_regs.h | 496 +++ include/uapi/linux/v4l2-controls.h |4 + 9 files changed, 4312 insertions(+) create mode 100644 drivers/media/platform/ti-vpe/Makefile create mode 100644 drivers/media/platform/ti-vpe/vpdma.c create mode 100644 drivers/media/platform/ti-vpe/vpdma.h create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h create mode 100644 drivers/media/platform/ti-vpe/vpe.c create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] v4l: ti-vpe: Add de-interlacer support in VPE
Add support for the de-interlacer block in VPE.
For de-interlacer to work, we need to enable 2 more sets of VPE input ports
which fetch data from the 'last' and 'last to last' fields of the interlaced
video. Apart from that, we need to enable the Motion vector output and input
ports, and also allocate DMA buffers for them.
We need to make sure that two most recent fields in the source queue are
available and in the 'READY' state. Once a mem2mem context gets access to the
VPE HW(in device_run), it extracts the addresses of the 3 buffers, and provides
it to the data descriptors for the 3 sets of input ports((LUMA1, CHROMA1),
(LUMA2, CHROMA2), and (LUMA3, CHROMA3)) respectively for the 3 consecutive
fields. The motion vector and output port descriptors are configured and the
list is submitted to VPDMA.
Once the transaction is done, the v4l2 buffer corresponding to the oldest
field(the 3rd one) is changed to the state 'DONE', and the buffers corresponding
to 1st and 2nd fields become the 2nd and 3rd field for the next de-interlace
operation. This way, for each deinterlace operation, we have the 3 most recent
fields. After each transaction, we also swap the motion vector buffers, the new
input motion vector buffer contains the resultant motion information of all the
previous frames, and the new output motion vector buffer will be used to hold
the updated motion vector to capture the motion changes in the next field. The
motion vector buffers are allocated using the DMA allocation API.
The de-interlacer is removed from bypass mode, it requires some extra default
configurations which are now added. The chrominance upsampler coefficients are
added for interlaced frames. Some VPDMA parameters like frame start event and
line mode are configured for the 2 extra sets of input ports.
Acked-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 392
1 file changed, 358 insertions(+), 34 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 3bd9ca6..4e58069 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -69,6 +69,8 @@
#define VPE_CHROMA 1
/* per m2m context info */
+#define VPE_MAX_SRC_BUFS 3 /* need 3 src fields to de-interlace */
+
#define VPE_DEF_BUFS_PER_JOB 1 /* default one buffer per batch job */
/*
@@ -111,6 +113,38 @@ static const struct vpe_us_coeffs us_coeffs[] = {
0x00C8, 0x0348, 0x0018, 0x3FD8, 0x3FB8, 0x0378, 0x00E8, 0x3FE8,
0x00C8, 0x0348, 0x0018, 0x3FD8, 0x3FB8, 0x0378, 0x00E8, 0x3FE8,
},
+ {
+ /* Coefficients for Top Field Interlaced input */
+ 0x0051, 0x03D5, 0x3FE3, 0x3FF7, 0x3FB5, 0x02E9, 0x018F, 0x3FD3,
+ /* Coefficients for Bottom Field Interlaced input */
+ 0x016B, 0x0247, 0x00B1, 0x3F9D, 0x3FCF, 0x03DB, 0x005D, 0x3FF9,
+ },
+};
+
+/*
+ * the following registers are for configuring some of the parameters of the
+ * motion and edge detection blocks inside DEI, these generally remain the
same,
+ * these could be passed later via userspace if some one needs to tweak these.
+ */
+struct vpe_dei_regs {
+ unsigned long mdt_spacial_freq_thr_reg; /* VPE_DEI_REG2 */
+ unsigned long edi_config_reg; /* VPE_DEI_REG3 */
+ unsigned long edi_lut_reg0; /* VPE_DEI_REG4 */
+ unsigned long edi_lut_reg1; /* VPE_DEI_REG5 */
+ unsigned long edi_lut_reg2; /* VPE_DEI_REG6 */
+ unsigned long edi_lut_reg3; /* VPE_DEI_REG7 */
+};
+
+/*
+ * default expert DEI register values, unlikely to be modified.
+ */
+static const struct vpe_dei_regs dei_regs = {
+ 0x020C0804u,
+ 0x0118100Fu,
+ 0x08040200u,
+ 0x1010100Cu,
+ 0x10101010u,
+ 0x10101010u,
};
/*
@@ -118,6 +152,7 @@ static const struct vpe_us_coeffs us_coeffs[] = {
*/
struct vpe_port_data {
enum vpdma_channel channel; /* VPDMA channel */
+ u8 vb_index; /* input frame f, f-1, f-2 index */
u8 vb_part;/* plane index for co-panar formats */
};
@@ -126,6 +161,12 @@ struct vpe_port_data {
*/
#define VPE_PORT_LUMA1_IN 0
#define VPE_PORT_CHROMA1_IN1
+#define VPE_PORT_LUMA2_IN 2
+#define VPE_PORT_CHROMA2_IN3
+#define VPE_PORT_LUMA3_IN 4
+#define VPE_PORT_CHROMA3_IN5
+#define VPE_PORT_MV_IN 6
+#define VPE_PORT_MV_OUT7
#define VPE_PORT_LUMA_OUT 8
#define VPE_PORT_CHROMA_OUT9
#define VPE_PORT_RGB_OUT 10
@@ -133,12 +174,40 @@ struct vpe_port_data {
static const struct vpe_port_data port_data[11] = {
[VPE_PORT_LUMA1_IN] = {
.channel= VPE_CHAN_LUMA1_IN,
+ .vb_index = 0,
[PATCH v5 1/4] v4l: ti-vpe: Create a vpdma helper library
The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data. VPDMA is
capable of buffering this data and then delivering the data as demanded to the
modules as programmed. The modules that source or sink data are referred to as
clients or ports. A channel is setup inside the VPDMA to connect a specific
memory buffer to a specific client. The VPDMA centralizes the DMA control
functions and buffering required to allow all the clients to minimize the
effect of long latency times.
Add the following to the VPDMA helper:
- A data struct which describe VPDMA channels. For now, these channels are the
ones used only by VPE, the list of channels will increase when VIP(Video
Input Port) also uses the VPDMA library. This channel information will be
used to populate fields required by data descriptors.
- Data structs which describe the different data types supported by VPDMA. This
data type information will be used to populate fields required by data
descriptors and used by the VPE driver to map a V4L2 format to the
corresponding VPDMA data type.
- Provide VPDMA register offset definitions, functions to read, write and modify
VPDMA registers.
- Functions to create and submit a VPDMA list. A list is a group of descriptors
that makes up a set of DMA transfers that need to be completed. Each
descriptor will either perform a DMA transaction to fetch input buffers and
write to output buffers(data descriptors), or configure the MMRs of sub blocks
of VPE(configuration descriptors), or provide control information to VPDMA
(control descriptors).
- Functions to allocate, map and unmap buffers needed for the descriptor list,
payloads containing MMR values and scaler coefficients. These use the DMA
mapping APIs to ensure exclusive access to VPDMA.
- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the
VPE interrupt line when a descriptor list is parsed completely and the DMA
transactions are completed. This requires masking the events in VPDMA
registers and configuring some top level VPE interrupt registers.
- Enable some VPDMA specific parameters: frame start event(when to start DMA for
a client) and line mode(whether each line fetched should be mirrored or not).
- Function to load firmware required by VPDMA. VPDMA requires a firmware for
it's internal list manager. We add the required request_firmware apis to fetch
this firmware from user space.
- Function to dump VPDMA registers.
- A function to initialize and create a VPDMA instance, this will be called by
the VPE driver with it's platform device pointer, this function will take care
of loading VPDMA firmware and returning a vpdma_data instance back to the VPE
driver. The VIP driver will also call the same init function to initialize
it's
own VPDMA instance.
Acked-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 578 +
drivers/media/platform/ti-vpe/vpdma.h | 155
drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++
3 files changed, 852 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
new file mode 100644
index 000..42db12c
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -0,0 +1,578 @@
+/*
+ * VPDMA helper library
+ *
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego, dagri...@biglakesoftware.com
+ * Dale Farnsworth, d...@farnsworth.org
+ * Archit Taneja, arc...@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.
+ */
+
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/err.h
+#include linux/firmware.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include vpdma.h
+#include vpdma_priv.h
+
+#define VPDMA_FIRMWARE vpdma-1b8.bin
+
+const struct vpdma_data_format vpdma_yuv_fmts[] = {
+ [VPDMA_DATA_FMT_Y444] = {
+ .data_type = DATA_TYPE_Y444,
+ .depth = 8,
+ },
+ [VPDMA_DATA_FMT_Y422] = {
+ .data_type = DATA_TYPE_Y422,
+ .depth = 8,
+ },
+ [VPDMA_DATA_FMT_Y420] = {
+ .data_type = DATA_TYPE_Y420,
+ .depth = 8,
+ },
+ [VPDMA_DATA_FMT_C444] = {
+ .data_type = DATA_TYPE_C444,
+ .depth = 8,
+ },
+ [VPDMA_DATA_FMT_C422] = {
+ .data_type =
[PATCH v5 2/4] v4l: ti-vpe: Add helpers for creating VPDMA descriptors
Create functions which the VPE driver can use to create a VPDMA descriptor and
add it to a VPDMA descriptor list. These functions take a pointer to an existing
list, and append the configuration/data/control descriptor header to the list.
In the case of configuration descriptors, the creation of a payload block may be
required(the payloads can hold VPE MMR values, or scaler coefficients). The
allocation of the payload buffer and it's content is left to the VPE driver.
However, the VPDMA library provides helper macros to create payload in the
correct format.
Add debug functions to dump the descriptors in a way such that it's easy to see
the values of different fields in the descriptors.
Acked-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 268 +++
drivers/media/platform/ti-vpe/vpdma.h | 48 +++
drivers/media/platform/ti-vpe/vpdma_priv.h | 522 +
3 files changed, 838 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index 42db12c..af0a5ff 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/slab.h
+#include linux/videodev2.h
#include vpdma.h
#include vpdma_priv.h
@@ -416,6 +417,273 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct
vpdma_desc_list *list)
return 0;
}
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+ int class;
+
+ class = cfd_get_class(cfd);
+
+ pr_debug(config descriptor of payload class: %s\n,
+ class == CFD_CLS_BLOCK ? simple block :
+ address data block);
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word0: dst_addr_offset = 0x%08x\n,
+ cfd-dest_addr_offset);
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word1: num_data_wrds = %d\n, cfd-block_len);
+
+ pr_debug(word2: payload_addr = 0x%08x\n, cfd-payload_addr);
+
+ pr_debug(word3: pkt_type = %d, direct = %d, class = %d, dest = %d,
+ payload_len = %d\n, cfd_get_pkt_type(cfd),
+ cfd_get_direct(cfd), class, cfd_get_dest(cfd),
+ cfd_get_payload_len(cfd));
+}
+
+/*
+ * append a configuration descriptor to the given descriptor list, where the
+ * payload is in the form of a simple data block specified in the descriptor
+ * header, this is used to upload scaler coefficients to the scaler module
+ */
+void vpdma_add_cfd_block(struct vpdma_desc_list *list, int client,
+ struct vpdma_buf *blk, u32 dest_offset)
+{
+ struct vpdma_cfd *cfd;
+ int len = blk-size;
+
+ WARN_ON(blk-dma_addr VPDMA_DESC_ALIGN);
+
+ cfd = list-next;
+ WARN_ON((void *)(cfd + 1) (list-buf.addr + list-buf.size));
+
+ cfd-dest_addr_offset = dest_offset;
+ cfd-block_len = len;
+ cfd-payload_addr = (u32) blk-dma_addr;
+ cfd-ctl_payload_len = cfd_pkt_payload_len(CFD_INDIRECT, CFD_CLS_BLOCK,
+ client, len 4);
+
+ list-next = cfd + 1;
+
+ dump_cfd(cfd);
+}
+
+/*
+ * append a configuration descriptor to the given descriptor list, where the
+ * payload is in the address data block format, this is used to a configure a
+ * discontiguous set of MMRs
+ */
+void vpdma_add_cfd_adb(struct vpdma_desc_list *list, int client,
+ struct vpdma_buf *adb)
+{
+ struct vpdma_cfd *cfd;
+ unsigned int len = adb-size;
+
+ WARN_ON(len VPDMA_ADB_SIZE_ALIGN);
+ WARN_ON(adb-dma_addr VPDMA_DESC_ALIGN);
+
+ cfd = list-next;
+ BUG_ON((void *)(cfd + 1) (list-buf.addr + list-buf.size));
+
+ cfd-w0 = 0;
+ cfd-w1 = 0;
+ cfd-payload_addr = (u32) adb-dma_addr;
+ cfd-ctl_payload_len = cfd_pkt_payload_len(CFD_INDIRECT, CFD_CLS_ADB,
+ client, len 4);
+
+ list-next = cfd + 1;
+
+ dump_cfd(cfd);
+};
+
+/*
+ * control descriptor format change based on what type of control descriptor it
+ * is, we only use 'sync on channel' control descriptors for now, so assume
it's
+ * that
+ */
+static void dump_ctd(struct vpdma_ctd *ctd)
+{
+ pr_debug(control descriptor\n);
+
+ pr_debug(word3: pkt_type = %d, source = %d, ctl_type = %d\n,
+ ctd_get_pkt_type(ctd), ctd_get_source(ctd), ctd_get_ctl(ctd));
+}
+
+/*
+ * append a 'sync on channel' type control descriptor to the given descriptor
+ * list, this descriptor stalls the VPDMA list till the time DMA is completed
+ * on the specified channel
+ */
+void vpdma_add_sync_on_channel_ctd(struct vpdma_desc_list *list,
+ enum vpdma_channel chan)
+{
+ struct vpdma_ctd *ctd;
+
+ ctd = list-next;
+ WARN_ON((void *)(ctd + 1) (list-buf.addr + list-buf.size));
+
+ ctd-w0 = 0;
+ ctd-w1 = 0;
+
