Re: [PATCH] mfd: palmas: Add support for optional wakeup
On Mon, 01 Sep 2014, Nishanth Menon wrote: On 09/01/2014 04:32 AM, Lee Jones wrote: On Fri, 29 Aug 2014, Nishanth Menon wrote: On 08/29/2014 05:56 AM, Lee Jones wrote: On Tue, 19 Aug 2014, Nishanth Menon wrote: With the recent pinctrl-single changes, omaps can treat wake-up events from deeper idle states as interrupts. Let's add support for the optional second interrupt for wake-up events. And then SoC can wakeup and handle the event using it's regular handler. Finally, to pass the wake-up interrupt in the dts file, interrupts-extended property needs to be passed. This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Signed-off-by: Nishanth Menon n...@ti.com --- Documentation/devicetree/bindings/mfd/palmas.txt | 20 DT Ack please. Please read Documentation/devicetree/bindings/submittingpatches.txt I assume you wanted me to note the following: The Documentation/ portion of the patch should be a separate patch. Many maintainers prefer that when the bindings for the device is new, and when additional properties are added, they prefer it part of same patch.. Anyways.. if the above is what you prefer, I can follow that. I tend to like it done properly please. In short, I assume you'd like three patches: a) fix up style of current documentation - palmas to palmas@40 b) Split documentation for interrupt-extended from the current patch into it's own patch. c) remainder of this patch as is.. Does that sound right? That does, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] video: fix composite video connector compatible string
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
composite-connector. That string is also used in the omap3-n900.dts
file. However, the connector driver uses composite-video-connector, so
this has never worked.
While changing the driver's compatible string to composite-connector
would be safer, as published DT bindings should not be changed, I'd
rather fix the bindings in this case for two reasons:
* composite-connector is a bit too generic name, as it doesn't even hint
at video.
* it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/devicetree/bindings/video/analog-tv-connector.txt | 4 ++--
arch/arm/boot/dts/omap3-n900.dts| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
index 0218fcdc1299..0c0970c210ab 100644
--- a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -2,7 +2,7 @@ Analog TV Connector
===
Required properties:
-- compatible: composite-connector or svideo-connector
+- compatible: composite-video-connector or svideo-connector
Optional properties:
- label: a symbolic name for the connector
@@ -14,7 +14,7 @@ Example
---
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1fe45d1f75ec..4361777a08d8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -93,7 +93,7 @@
};
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
--
1.9.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 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
+
exynos-dev = dev;
exynos-clk = clk;
clk_prepare_enable(exynos-clk);
+ if (!IS_ERR(exynos-sclk))
+ clk_prepare_enable(exynos-sclk);
If you replaced the returned err value with NULL you could avoid these
IS_ERR cases.
Right, point taken.
[snip]
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 11:39:08AM +0100, Vivek Gautam wrote:
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c
b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but
that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
Perhaps. I don't know what your future hardware will look like.
Is the usbdrd30_sclk input unique to Exynos7, or was it previously there
but just without an input?
If the latter you could just reduce this to:
dev_info(dev, no sclk specified);
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
NAND uses wait pin only to indicate device readiness after a block/page operation. It is not use to extend individual read/write cycle and so read/write wait pin monitoring must be disabled for NAND. This patch also gets rid of the below warning when NAND is accessed for the first time. omap_l3_noc 4400.ocp: L3 application error: target 13 mod:1 (unclearable) Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/am437x-gp-evm.dts | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index 402249e..ff4af7b 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -443,8 +443,6 @@ gpmc,rd-cycle-ns = 40; gpmc,wr-cycle-ns = 40; gpmc,wait-pin = 0; - gpmc,wait-on-read; - gpmc,wait-on-write; gpmc,bus-turnaround-ns = 0; gpmc,cycle2cycle-delay-ns = 0; gpmc,clk-activation-ns = 0; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND
Both QSPI and GPMC-NAND share the same Pin (A8) from the SoC for Chip Select
functionality. So both can't be enabled simultaneously.
Disable QSPI node to prevent the pin conflict as well as
be similar to 3.12 release.
CC: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index b489b27..ac3e485 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -435,7 +435,7 @@
};
gpmc {
- status = okay;
+ status = okay;/* Disable QSPI when enabling GPMC (NAND) */
pinctrl-names = default;
pinctrl-0 = nand_flash_x8;
ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
@@ -556,7 +556,7 @@
};
qspi {
- status = okay;
+ status = disabled;/* Disable GPMC (NAND) when enabling QSPI */
pinctrl-names = default;
pinctrl-0 = qspi1_default;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
For NAND read write wait pin monitoring must be kept disabled as the
wait pin is only used to indicate NAND device ready status and not to
extend each read/write cycle.
So don't print a warning if wait pin is specified while read/write
monitoring is not in the device tree.
Sanity check wait pin number irrespective if read/write monitoring is
set or not.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9f42d54..2f97228 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1207,8 +1207,7 @@ int gpmc_cs_program_settings(int cs, struct gpmc_settings
*p)
}
}
- if ((p-wait_on_read || p-wait_on_write)
- (p-wait_pin gpmc_nr_waitpins)) {
+ if (p-wait_pin gpmc_nr_waitpins) {
pr_err(%s: invalid wait-pin (%d)\n, __func__, p-wait_pin);
return -EINVAL;
}
@@ -1288,8 +1287,8 @@ void gpmc_read_settings_dt(struct device_node *np, struct
gpmc_settings *p)
p-wait_on_write = of_property_read_bool(np,
gpmc,wait-on-write);
if (!p-wait_on_read !p-wait_on_write)
- pr_warn(%s: read/write wait monitoring not enabled!\n,
- __func__);
+ pr_debug(%s: rd/wr wait monitoring not enabled!\n,
+__func__);
}
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17
Hi Tony, These are some of the issues I found while testing v3.17-rc3. - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use BCH16 instead of BCH8. - Wrong read/write wait pin monitoring setting used for NAND resulting in L3 application error debug message on console. - Pin conflict issue on am43x EPOS evm with QSPI and NAND. Patches are available at g...@github.com:rogerq/linux.git * [new branch] for-v3.17/gpmc-fixes cheers, -roger Roger Quadros (6): ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8 ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8 ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND arch/arm/boot/dts/am437x-gp-evm.dts | 4 +--- arch/arm/boot/dts/am43x-epos-evm.dts | 9 - arch/arm/mach-omap2/gpmc.c | 7 +++ 3 files changed, 8 insertions(+), 12 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
am43x-epos-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.
For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index ed7dd23..f6c9898 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -441,7 +441,7 @@
ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch16;
ti,elm-id = elm;
nand-bus-width = 8;
gpmc,device-width = 1;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
am437x-gp-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.
For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 646a6ea..402249e 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -424,7 +424,7 @@
ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
nand@0,0 {
reg = 0 0 4; /* device IO registers */
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch16;
ti,elm-id = elm;
nand-bus-width = 8;
gpmc,device-width = 1;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
NAND uses wait pin only to indicate device readiness after a block/page operation. It is not use to extend individual read/write cycle and so read/write wait pin monitoring must be disabled for NAND. Add gpmc wait pin information as the NAND uses wait pin 0 for device ready indication. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/am43x-epos-evm.dts | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index f6c9898..b489b27 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -459,8 +459,7 @@ gpmc,access-ns = 30; /* tCEA + 4*/ gpmc,rd-cycle-ns = 40; gpmc,wr-cycle-ns = 40; - gpmc,wait-on-read = true; - gpmc,wait-on-write = true; + gpmc,wait-pin = 0; gpmc,bus-turnaround-ns = 0; gpmc,cycle2cycle-delay-ns = 0; gpmc,clk-activation-ns = 0; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 04:09:08PM +0530, Vivek Gautam wrote:
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c
b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but
that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
maybe dev_dbg() is what you want ? :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi dfo...@gmail.com wrote: 2014-08-28 10:02 GMT+02:00 Vivek Gautam: This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) OF shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like that idea. The thing is that this will likely need to be patches for exynos8, 9, 10, 11... cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Tue, Sep 02, 2014 at 12:18:12PM +0100, Peter Griffin wrote:
Hi Felipe,
Sorry for the delay in replying to this mail, I've been trying to get
answers to the suspend/resume questions you had.
np
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3_HOST
this seems wrong as USB_DWC3_{HOST,GADGET,DUAL_ROLE} are booleans and
USB_DWC3_ST is a tristate. Better to stick with defaulting to USB_DWC3
instead like all the others.
Ok will fix.
tks
+static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32
value)
+{
+ writel_relaxed(value, base + offset);
why relaxed ?
The writel and readl implementations on ARM are quite expensive.
The writel, does a memory barrier, and also a outer_sync(), which
involves taking a spinlock, and draining the cache store buffers.
The readl also does a memory barrier.
These barriers / cache operations are unnecessary here as the
peripheral memory has been ioremap'ed as device memory, and it is only
one device we are writing to, so the writel/readl_relaxed variants are
good enough as the ARM arch guarentees they will arrive in program
order.
good point :-)
There is some more info about this here
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/117658
Note: It's only possible when we know the driver is not being used on
other architectures which may have different constraints.
However for this driver, we know this IP (st glue logic) has only been
used on ARM based SoC's.
alright :-)
+}
+
+/**
+ * st_dwc3_drd_init: program the port
+ * @dwc3_data: driver private structure
+ * Description: this function is to program the port as either host or
device
+ * according to the static configuration passed from devicetree.
+ * OTG and dual role are not yet supported!
+ */
+static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
+{
+ u32 val;
+ int err;
+
+ err = regmap_read(dwc3_data-regmap, dwc3_data-syscfg_reg_off, val);
+ if (err)
+ return err;
+
+ switch (dwc3_data-dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ val |= USB_SET_PORT_DEVICE;
+ dev_dbg(dwc3_data-dev, Configuring as Device\n);
+ break;
+
+ case USB_DR_MODE_HOST:
+ val = USB_HOST_DEFAULT_MASK;
are you missing a ~ here ? Also, shouldn't you mask off the bits before
this switch ?
Yes your right, good spot! In the next iteration I've defined macros
for the bits in this control register and explitcitly set/clear them
for both cases, also adding a comment regarding the
USB3_DELAY_VBUSVALID bit.
ok, cool.
By chance host mode still worked with this bug present as the reset
value of the register on this SoC is OK to have working host mode.
heh :-)
+ dev_dbg(dwc3_data-dev, Configuring as Host\n);
+ break;
+
+ default:
+ dev_err(dwc3_data-dev, Unsupported mode of operation %d\n,
+ dwc3_data-dr_mode);
+ return -EINVAL;
+ }
+
+ return regmap_write(dwc3_data-regmap, dwc3_data-syscfg_reg_off, val);
+}
+
+/**
+ * st_dwc3_init: init the controller via glue logic
+ * @dwc3_data: driver private structure
+ */
+static void st_dwc3_init(struct st_dwc3 *dwc3_data)
+{
+
this blank line isn't necessary.
Ok, removed in next iteration
snip
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, syscfg-reg);
+ if (!res) {
+ ret = -ENXIO;
+ goto undo_platform_dev_alloc;
+ }
+
+ dwc3_data-syscfg_reg_off = res-start;
+
+ dev_dbg(pdev-dev, glue-logic addr 0x%p, syscfg-reg offset 0x%x\n,
+ dwc3_data-glue_base, dwc3_data-syscfg_reg_off);
looks like this message would be more of a dev_vdbg().
Ok, changed to dev_vdbg in next iteration
snip
+
+#ifdef CONFIG_PM_SLEEP
+static int st_dwc3_suspend(struct device *dev)
+{
+ struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
+
+ reset_control_assert(dwc3_data-rstc_pwrdn);
+ reset_control_assert(dwc3_data-rstc_rst);
Two questions:
1) how would you handle the case when this device is a wakeup source ?
I've confirmed with ST the usb3 IP can't be a wakeup source on this SoC.
2) when resuming, wouldn't you have to reinitialize the entire core ?
I asked ST to test this, as a full working suspend / resume setup
involves some firmware for the standby controller which I don't
currently have access to (and it is only with the SBC running that all
power will be removed from this part of the SoC). They have confirmed
that the usb3 port works after a suspend / resume and devices are
correctly enumerated etc after a resume with the code as it was
submitted.
What I did notice though after re-reading it, is that we are not
re-configuring the ST glue logic registers on a resume. So the
controller could end up
Re: [PATCHv2] ARM: debug: uncompress debug support for omap2plus
* kpark3...@gmail.com kpark3...@gmail.com [140826 01:29]: From: Sahara keun-o.p...@windriver.com Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system. Hmm the plan is to switch over to using the standard DEBUG_LL_UART_8250 code and remove the runtime detection. That will simplify things quite a bit and probably means this patch won't be needed AFAIK. Care to take a look at doing that instead? See for example [PATCH v9 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S. Regards, Tony Signed-off-by: Sahara keun-o.p...@windriver.com Tested-by: Afzal Mohammed afzal.mohd...@gmail.com (on am335x beagle bone white) --- arch/arm/Kconfig.debug |3 +- arch/arm/include/debug/omap2plus.S | 96 ++-- 2 files changed, 27 insertions(+), 72 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index b11ad54..c0ad3e4 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1220,8 +1220,7 @@ config DEBUG_UART_8250_FLOW_CONTROL config DEBUG_UNCOMPRESS bool depends on ARCH_MULTIPLATFORM || ARCH_MSM || PLAT_SAMSUNG - default y if DEBUG_LL !DEBUG_OMAP2PLUS_UART \ - (!DEBUG_TEGRA_UART || !ZBOOT_ROM) + default y if DEBUG_LL (!DEBUG_TEGRA_UART || !ZBOOT_ROM) help This option influences the normal decompressor output for multiplatform kernels. Normally, multiplatform kernels disable diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..0b7ec89 100644 --- a/arch/arm/include/debug/omap2plus.S +++ b/arch/arm/include/debug/omap2plus.S @@ -58,115 +58,71 @@ #define UART_OFFSET(addr)((addr) 0x00ff) - .pushsection .data -omap_uart_phys: .word 0 -omap_uart_virt: .word 0 -omap_uart_lsr: .word 0 - .popsection - .macro addruart, rp, rv, tmp - /* Use omap_uart_phys/virt if already configured */ -10: adr \rp, 99f@ get effective addr of 99f - ldr \rv, [\rp] @ get absolute addr of 99f - sub \rv, \rv, \rp @ offset between the two - ldr \rp, [\rp, #4] @ abs addr of omap_uart_phys - sub \tmp, \rp, \rv @ make it effective - ldr \rp, [\tmp, #0] @ omap_uart_phys - ldr \rv, [\tmp, #4] @ omap_uart_virt - cmp \rp, #0 @ is port configured? - cmpne \rv, #0 - bne 100f@ already configured - /* Configure the UART offset from the phys/virt base */ -#ifdef CONFIG_DEBUG_OMAP2UART1 +#if defined(CONFIG_DEBUG_OMAP2UART1) mov \rp, #UART_OFFSET(OMAP2_UART1_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART2 +#elif defined(CONFIG_DEBUG_OMAP2UART2) mov \rp, #UART_OFFSET(OMAP2_UART2_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART3 +#elif defined(CONFIG_DEBUG_OMAP2UART3) mov \rp, #UART_OFFSET(OMAP2_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART3 +#elif defined(CONFIG_DEBUG_OMAP3UART3) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x6000 @ OMAP3_UART3_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART3 +#elif defined(CONFIG_DEBUG_OMAP4UART3) mov \rp, #UART_OFFSET(OMAP4_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART4 +#elif defined(CONFIG_DEBUG_OMAP3UART4) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x00028000 @ OMAP3_UART4_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART4 +#elif defined(CONFIG_DEBUG_OMAP4UART4) mov \rp, #UART_OFFSET(OMAP4_UART4_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART1 +#elif defined(CONFIG_DEBUG_TI81XXUART1) mov \rp, #UART_OFFSET(TI81XX_UART1_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART2 +#elif defined(CONFIG_DEBUG_TI81XXUART2) mov \rp, #UART_OFFSET(TI81XX_UART2_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART3 +#elif defined(CONFIG_DEBUG_TI81XXUART3) mov \rp, #UART_OFFSET(TI81XX_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_AM33XXUART1 +#elif
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Reichel s...@kernel.org [140901 20:06]: Hi, On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote: On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) One character wakes it up. After that you can send 16, 64 and you see them. Right away. No delay. If you send a lot data in one-go it takes approx 152 characters until the first one is displayed properly at 115200,8N1. That is approx 13ms. Could it take that long to get up and be ready? I noticed the same behaviour when I tested the runtime PM stuff on my N900 with the existing serial-omap driver and I also assumed, that the chip needs that long to get up. OK yeah I've confirmed that serial-omap also won't do anything with the pasted data until woken up. It takes some time to get things powered up again, there's nothing we can do beyond having the autoidle disabled by default. Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. Hmm I have not seen the RX hang with serial-omap when pasting data to the console to wake it up. One thing that is probably a dumb idea is that printk in omap_8250_mdr1_errataset(). Would it be possible that when I hit a printk in the resume path that I may deadlock and box will freeze? I guess yeah. You may want to use pstore as console to debug that. You need to use this patch to prevent pstore from hanging: https://lkml.org/lkml/2013/4/9/831 Then enable: CONFIG_PSTORE=y CONFIG_PSTORE_CONSOLE=y CONFIG_PSTORE_RAM=y CONFIG_FUNCTION_TRACER=y CONFIG_DEBUG_FS=y CONFIG_PSTORE_FTRACE=y Then at kernel cmdline, specify something like this: memmap=2M$0x8800 ramoops.mem_address=0x8800 ramoops.mem_size=0x20 ramoops.record_size=0x4 And leave out console=ttyS line and spin up a getty on the serial line. After booting, you should just need to do: # mount -t pstore - /sys/fs/pstore And then you see dmesg in /sys/fs/pstore. To debug hangs, set up the PMIC watchdog and do not set up omap watchdog, and you should see the last dmesg in /sys/fs/pstore after a warm reset. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
This patch adds the new dwc3-st.c glue driver found on STMicroelectronics stih407 consumer electronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index cf24bb5..55381955 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1398,6 +1398,7 @@ F:drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 377 +
3 files changed, 387 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 785510a..5238251 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..c4c1717
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,377 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/reset.h
+#include linux/usb/of.h
+
+#include core.h
+#include io.h
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_signal_name from usb3_top is selected
+ * 2’b10 : pipew_signal_name from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG 0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n) (n 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n 4)
+#define SEL_OVERRIDE_BVALID(n) (n 8)
+
+/* Static DRD configuration */
+#define USB3_CONTROL_MASK 0xf77
+
+#define USB3_DEVICE_NOT_HOST BIT(0)
+#define USB3_FORCE_VBUSVALID BIT(1)
+#define USB3_DELAY_VBUSVALID BIT(2)
+#define USB3_SEL_FORCE_OPMODE BIT(4)
+#define USB3_FORCE_OPMODE(n) (n 5)
+#define USB3_SEL_FORCE_DPPULLDOWN2 BIT(8)
+#define USB3_FORCE_DPPULLDOWN2 BIT(9)
+#define USB3_SEL_FORCE_DMPULLDOWN2 BIT(10)
+#define USB3_FORCE_DMPULLDOWN2 BIT(11)
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst: reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+
[PATCH v5 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..f9d7025
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,68 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be reg-glue and syscfg-reg
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be powerdown and
softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
+is otg, which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either host
+or device.
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN,
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host;
+ phys-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy2, phy_port2 MIPHY_TYPE_USB;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] Add ST dwc3 glue layer driver
This series adds support for the ST glue logic which wraps the DWC3 controller on STiH407 SoC family chipsets. Changes since v4 - Fix bug with setting bits in usb control register - Remove superflous '\n' - Change default Kconfig to make default same as other platforms - Update dt doc example so that both usb2 and usb3 phys are using generic drivers/phy instead of drivers/usb/phy - Reconfigure ST glue logic regs in resume callback Changes since v3 - Various formating nits Changes since v2 - Use dr_mode for host/device static configuration - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy - Remove DT checks and make driver depend on OF - Change some #define to use BIT macro - Make some comments clearer - Use kerneldoc for struct documentation - Remove udelay - Let DT create platform_devices, and remove legacy alloc - Change some logging levels to dev_dbg - Various whitespace and formatting cleanup - Use SIMPLE_DEV_PM_OPS() - Add const to of_device struct - Reorder header files alphabetically - Use devm_ioremap_resource instead of devm_request_and_ioremap - Remove of_match_ptr() Changes since v1 - Fix Kconfig mistake Peter Griffin (3): usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 MAINTAINERS | 1 + drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-st.c| 377 ++ 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt create mode 100644 drivers/usb/dwc3/dwc3-st.c -- 1.9.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 0/6] OMAP2+: GPMC: NAND fixes for 3.17
Hi Roger, On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote: Hi Tony, These are some of the issues I found while testing v3.17-rc3. - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use BCH16 instead of BCH8. Thanks for updating ECC scheme for AM43x EVM boards. Just for background history, BCH16 ECC scheme was not in mainline when AM43xx NAND DTS patches were accepted. So to avoid any inter-dependency of patches, BCH8 was used instead. commit f68e355c86cff91e5266cf937ea24fcba0641900 ARM: dts: am43xx: add support for parallel NAND flash CommitDate: 2 March 2014 commit 9748fff96484cfc8bb382ef1436823aefe065c9c mtd: nand: omap: add support for BCH16_ECC - NAND driver updates CommitDate: 21 May 2014 For the record, boot-loader (u-boot SPL) on AM43x-EPOS and AM437x-GP EVM boards should be flashed in BCH16 ECC scheme as NAND device present on this boards has - page-size=4KiB - OOB-size=224B So ROM code expects BCH16 ECC scheme to load first boot-loader(SPL). with regards, pekon Powered by BigRock.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/6] ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
am43x-epos-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.
For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index ed7dd23..f6c9898 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -441,7 +441,7 @@
ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch16;
ti,elm-id = elm;
nand-bus-width = 8;
gpmc,device-width = 1;
As I have tested BCH16 on AM43x-EPOS board earlier So,
Reviewed-by: Pekon Gupta pe...@pek-sem.com
with regards, pekon
Powered by BigRock.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 2/6] ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
am437x-gp-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.
For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 646a6ea..402249e 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -424,7 +424,7 @@
ranges = 0 0 0 0x0100; /* minimum GPMC partition = 16MB */
nand@0,0 {
reg = 0 0 4;/* device IO registers */
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch16;
ti,elm-id = elm;
nand-bus-width = 8;
gpmc,device-width = 1;
For already mentioned reason ..
Reviewed-by: Pekon Gupta pe...@pek-sem.com
with regards, pekon
Powered by BigRock.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 15/15] tty: serial: 8250: omap: add dma support
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. - one where the system is dead and the LED does not blink anymore. Also my button is dead. - disabling DMA makes the problem not go away. - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
Hi Roger,
On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.
I think this is incorrect assumption. NAND framework allows
wait-pin monitoring at end of each read/write cycle. Please
refer following code in drivers/mtd/nand/nand_base.c
@@ void nand_wait_ready(...)
- nand_wait_ready() calls controller-driver specific call-back
for chip-dev_ready().
- chip-dev_ready in-case of OMAP NAND drivers is set in
drivers/mtd/nand/omap2.c during probe.
if (pdata-dev_ready) {
nand_chip-dev_ready = omap_dev_ready;
nand_chip-chip_delay = 0;
}
Problem is we don't set pdata-dev_ready correctly as part
of platform-data dring GPMC initialization. This was what my
earlier patch for wait-pin monitoring about. But it was a
quick fix for NAND devices.
So, I suggest to fix wait-pin monitoring instead of de-scoping
it from DTS as wait-pin monitoring should boast the NAND
performance significantly.
(please see if you can find an old mail thread which had some
good feedbacks from Ezequiel and Javier about wait-pin monitoring).
[...]
This patch also gets rid of the below warning when NAND is
accessed for the first time.
omap_l3_noc 4400.ocp: L3 application error: target 13 mod:1 (unclearable)
Can you debug this further.
This warning probably comes when driver tries to access some
reserved addresses. Or violate read/write bits.
with regards, pekon
Powered by BigRock.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 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote: For NAND read write wait pin monitoring must be kept disabled as the wait pin is only used to indicate NAND device ready status and not to extend each read/write cycle. I think this description, does not fit in this patch. And is incorrect as explained in previous patch review. So don't print a warning if wait pin is specified while read/write monitoring is not in the device tree. Sanity check wait pin number irrespective if read/write monitoring is set or not. Signed-off-by: Roger Quadros rog...@ti.com --- But below mentioned checks and clean-up makes sense. So apart from first 3 lines of commit log .. Reviewed-by: Pekon Gupta pe...@pek-sem.com with regards, pekon Powered by BigRock.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 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]: On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. - disabling DMA makes the problem not go away. OK - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. I wonder if doing some TX on the uart restores it? So maybe try $ while [ 1 ]; do date; sleep 10 done To have it occasionally print something in the background. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On Tue, Sep 02, 2014 at 01:15:37PM -0700, Tony Lindgren wrote: * Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]: On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. - disabling DMA makes the problem not go away. OK - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. I wonder if doing some TX on the uart restores it? So maybe try $ while [ 1 ]; do date; sleep 10 done To have it occasionally print something in the background. If there is a way to detect the hangup you may try to recover by resetting the serial device using omap_hwmod_reset(). -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] video: fix composite video connector compatible string
Hi Tomi,
Thank you for the patch.
On Tuesday 02 September 2014 10:35:46 Tomi Valkeinen wrote:
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
composite-connector. That string is also used in the omap3-n900.dts
file. However, the connector driver uses composite-video-connector, so
this has never worked.
While changing the driver's compatible string to composite-connector
would be safer, as published DT bindings should not be changed, I'd
rather fix the bindings in this case for two reasons:
* composite-connector is a bit too generic name, as it doesn't even hint
at video.
* it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/devicetree/bindings/video/analog-tv-connector.txt | 4 ++--
arch/arm/boot/dts/omap3-n900.dts| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
b/Documentation/devicetree/bindings/video/analog-tv-connector.txt index
0218fcdc1299..0c0970c210ab 100644
--- a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -2,7 +2,7 @@ Analog TV Connector
===
Required properties:
-- compatible: composite-connector or svideo-connector
+- compatible: composite-video-connector or svideo-connector
Optional properties:
- label: a symbolic name for the connector
@@ -14,7 +14,7 @@ Example
---
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts index 1fe45d1f75ec..4361777a08d8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -93,7 +93,7 @@
};
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.17-rc3
Here are some basic OMAP test results for Linux v3.17-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc3/20140902165525/ Test summary Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Boot to userspace: FAIL ( 2/15): 2430sdp, 5430es2sbct54 skip ( 1/15): 5912osk Pass (12/15): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm PM: chip off via dynamic idle: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm vmlinux object size (delta in bytes from test_v3.17-rc2 (52addcf9d6669fa439387610bc65c92fa0980cef)): text data bsstotal kernel +120 +320 +152 omap1_defconfig +88 +640 +152 omap1_defconfig_1510innovator_only +88 +32 +32 +152 omap1_defconfig_5912osk_only -4992 -240-5016 multi_v7_defconfig -43760 +64-4312 omap2plus_defconfig -3896 +320-3864 omap2plus_defconfig_2430sdp_only -4448 -80-4456 omap2plus_defconfig_am33xx_only -4448 -80-4456 omap2plus_defconfig_am43xx_only -4376 +64 +64-4248 omap2plus_defconfig_cpupm -4320 +640-4256 omap2plus_defconfig_dra7xx_only -15337 -5520 -15889 omap2plus_defconfig_n800_multi_omap2xxx -11241 -5040 -11745 omap2plus_defconfig_n800_only_a +640 +960 +736 omap2plus_defconfig_no_pm -4448 +800-4368 omap2plus_defconfig_omap2_4_only -4384 -80-4392 omap2plus_defconfig_omap3_4_only -4384 +800-4304 omap2plus_defconfig_omap5_only +108 -16 +24 +116 rmk_omap3430_ldp_allnoconfig +172 -160 +156 rmk_omap3430_ldp_oldconfig +76 -12 +56 +120 rmk_omap4430_sdp_allnoconfig +140 +160 +156 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.17-rc2 (52addcf9d6669fa439387610bc65c92fa0980cef)) avail rsrvd high freed board kconfig 8k-8k . . 2420n800 omap2plus_defconfig_n800_only_a 8k-8k . . am335xbone omap2plus_defconfig_am33xx_only A Compulab SBC-T54 (OMAP5432) has been added to the testbed, graciously donated by Compulab and Igor Grinberg. It currently isn't booting to userspace in the current mainline kernel, but if the 'ldo8' regulator is modified to be always-on in the omap5-sbc-t54.dts file, it will. -- 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] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [140902 01:29]:
On 2014-08-19 08:24:05 [-0700], Tony Lindgren wrote:
This allows us to enable the PMIC configuration for n900.
Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off
oscillator during off-idle)
My beaglebone-ab does not like this. With this patch applied I end up
with:
[2.437316] Waiting for root device /dev/mmcblk0p2...
[4.428192] mmc0: card never left busy state
[4.432647] mmc0: error -110 whilst initialising SD card
I assume you mean beagleboard-ab, not beaglebone-ab :)
I noticed this after I disabled lock debugging and tracing (syscall tracing
was enabled). Enabling both again makes the error go away.
With debugging + tracing disabled (so the error pops up) and git bisect
I get this commit (daebabd57) reported.
OK. Sounds like we still have a race between the regulator code
and twl4030-power.c for accessing some twl registers.
A diff between a good/bad bootlog (with lock-debug + tracing switched
off):
| smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized
| smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized
| hsusb2_vbus: disabling
| VPLL2: disabling
| VUSB3V1: disabling
|+VDAC: disabling
|+VAUX3: disabling
This seems to be the reason. Seems you're on v3.17-rc3, but with
commit daebabd57 we are not even touching the group registers that
twl-regulator.c accesses for VDAC and VAUX3 as they are set to
TWL4030_RESCONFIG_UNDEF. So I'm a bit baffled what's going on.
reverting this commit on top of -rc3 makes mmc0 work again.
Again, I assume you're talking about reverting daebabd57,
not 43fef47f94a1. Anyways, here's a debug hack I used earlier to
dump out the twl configuration in late_initcall and via sysfs
so maybe try that and see what the values are with working
and non-working case?
Regards,
Tony
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -358,6 +358,146 @@ out:
return err;
}
+#ifdef CONFIG_DEBUG_FS
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+static void twl4030_dump_resource(unsigned index, struct seq_file *s)
+{
+ int addr;
+ int err;
+ u8 type;
+ u8 grp;
+ u8 remap;
+
+ addr = res_config_addrs[index];
+
+ err = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, grp,
+ addr + DEV_GRP_OFFSET);
+ if (err) {
+ pr_err(TWL4030 Resource group 0x%02x could not be read\n,
+ addr);
+ return;
+ }
+
+ err = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, type,
+ addr + TYPE_OFFSET);
+ if (err 0) {
+ pr_err(TWL4030 Resource type 0x%02x could not be read\n,
+ addr);
+ return;
+ }
+
+ err = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, remap,
+ addr + REMAP_OFFSET);
+ if (err 0) {
+ pr_err(TWL4030 Resource 0x%02x remap could not be read\n,
+ addr);
+ return;
+ }
+
+ if (s)
+ seq_printf(s, %i: addr: 0x%04x grp: 0x%04x type: 0x%04x remap:
0x%04x\n,
+ index, addr, grp, type, remap);
+ else
+ printk(%i: addr: 0x%04x grp: 0x%04x type: 0x%04x remap:
0x%04x\n,
+ index, addr, grp, type, remap);
+}
+
+static void twl4030_dump_resources(void)
+{
+ int i;
+
+ for (i = 1; i = RES_MAIN_REF; i++)
+ twl4030_dump_resource(i, NULL);
+}
+
+static struct dentry *dbg_root;
+
+static int dbg_show(struct seq_file *s, void *unused)
+{
+ unsigned long offset = (unsigned long)s-private;
+
+ twl4030_dump_resource(offset, s);
+
+ return 0;
+}
+
+static ssize_t dbg_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct seq_file *seqf;
+ unsigned long offset;
+ u8 val;
+ int res;
+
+ res = kstrtou8_from_user(user_buf, count, 0x10, val);
+if (res 0)
+return res;
+
+ seqf = file-private_data;
+ offset = (unsigned long)seqf-private;
+ offset = res_config_addrs[offset];
+
+ res = twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
+ val, offset + DEV_GRP_OFFSET);
+ if (res 0) {
+ pr_err(TWL4030 failed to program devgroup\n);
+ return res;
+ }
+
+ *ppos += count;
+
+ return count;
+}
+
+static int dbg_open(struct inode *inode, struct file *file)
+{
+return single_open(file, dbg_show, inode-i_private);
+}
+
+static const struct file_operations dbg_fops = {
+.open = dbg_open,
+.read = seq_read,
+.write = dbg_write,
+.llseek = seq_lseek,
+.release= single_release,
Re: [PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
On Fri, Aug 29, 2014 at 12:58 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 28, 2014 at 01:31:59PM +0530, Vivek Gautam wrote: The Exynos-DWC3 USB 3.0 DRD controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 785510a..e235894 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate Samsung Exynos Platform - depends on ARCH_EXYNOS || COMPILE_TEST + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST wait when building for ARCH_EXYNOS7 you don't get ARCH_EXYNOS ? Right, we do get it now in V2 patch series for Exynos7 [1], but it wasn't available in the first series [2]. Will drop this patch now. [1] http://www.spinics.net/lists/linux-samsung-soc/msg36378.html [2] http://www.spinics.net/lists/arm-kernel/msg357382.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi dfo...@gmail.com wrote: 2014-08-28 10:02 GMT+02:00 Vivek Gautam: This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) OF shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like that idea. The thing is that this will likely need to be patches for exynos8, 9, 10, 11... Yes, after we have the 2nd version of Exynos7 support patches, it makes more sense to keep dependency on ARCH_EXYNOS. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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
